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 秒。
