MySQL核心概念是支撑SQL操作的底层逻辑，涵盖数据库/表/记录层级关系、主键/外键/索引的数据安全机制、事务ACID特性、字符集与排序规则等关键要素。
MySQL 核心概念不是一堆术语堆砌，而是你每天写 SQL、建表、查数据时真正依赖的“底层逻辑”。搞不清它们，轻则 INSERT 失败报错，重则线上数据不一致、查询慢到怀疑人生。
数据库 vs 表 vs 记录：别再把“库”当文件夹
新手最常混淆的是层级关系：MySQL 是软件（DBMS），它里面可以创建多个 database（比如 shop_db、user_db），每个库下建多张 table（如 users、orders），每张表里存若干 row（记录）。
这不是“文件夹→子文件夹→文件”，而是有强约束的结构化容器。
- 执行
USE shop_db;后，所有后续SELECT才默认在该库下找表；漏这句，SELECT * FROM users;会直接报错Table 'users' doesn't exist -
CREATE TABLE必须指定字段类型和约束，比如id INT PRIMARY KEY AUTO_INCREMENT—— 少写AUTO_INCREMENT，插入时就得手动填 ID，极易出错 - 一张表不能有两个主键，但可以有联合主键（如
(order_id, sku_id)），这点在订单明细表中很常见
主键、外键、索引：不是可选项，是数据安全的三道锁
它们不是为了“看起来规范”，而是防止你手抖删错、查得慢、连不上关联数据。
-
PRIMARY KEY强制非空 + 唯一，且自动创建聚集索引（InnoDB 下直接影响物理存储顺序）；误删主键会导致UPDATE无法准确定位行，可能批量改错 -
FOREIGN KEY不仅是建个约束，它会在关联表INSERT/UPDATE/DELETE时自动校验（比如往order_items插一个不存在的order_id，直接拒绝）；但注意：MyISAM 引擎不支持外键，用错引擎等于关掉这道锁 -
INDEX不是越多越好。给WHERE条件里从不出现的字段加索引，只会拖慢INSERT，还占磁盘；常用但没索引的字段（如status、created_at）才是优化重点
事务与 ACID：为什么你的 UPDATE 看似成功却没生效？
默认情况下，MySQL 的 autocommit=ON，每条 INSERT/UPDATE/DELETE 都自动提交。但一旦你显式写了 BEGIN 或 START TRANSACTION，就必须自己 COMMIT 或 ROLLBACK。
- 忘记
COMMIT，另一个连接就查不到刚改的数据（隔离性起作用），你以为改了，其实还在事务里悬着 - InnoDB 支持行级锁，但如果你
UPDATE时用了非索引字段做条件（如WHERE name = '张三'而name没索引），会升级为表锁，阻塞其他写操作 - 生产环境千万别用
TRUNCATE TABLE代替DELETE清数据——它不走事务，不可回滚，且会重置自增 ID
字符集与排序规则：中文乱码、大小写敏感、查不到数据的隐形凶手
从安装那一刻起，character_set_server 和 collation_server 就决定了你后续所有库、表、字段的默认行为。
- 建库时不显式指定，很可能用上
latin1，存中文直接变问号或报错；务必用CREATE DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; -
utf8mb4才真正支持 4 字节 emoji（如 ?），而旧版utf8实际只支持 3 字节，名字叫 utf8 却不是真 utf8 -
_ci（case-insensitive）结尾的校对集会让WHERE name = 'ZHANGSAN'匹配到'zhangsan'；如果业务要求严格区分大小写（如密码盐值），得用_cs或_bin
真正卡住新手的，往往不是语法不会写，而是不知道某条 CREATE TABLE 语句背后触发了多少隐式行为——引擎选错、字符集遗漏、主键没设、索引缺失……这些细节不提前对齐，后面调半天慢查询，不如建表时多敲 20 秒。
