外键检查必须先确认父表记录存在：mysql执行insert/update/delete涉及外键时，innodb强制对父表对应主键行加lock_s共享锁以校验参照完整性，该锁不可禁用，其性能影响主要取决于子表外键列是否建立有效索引。
外键检查必须先确认父表记录存在
MySQL执行涉及外键的写操作（如INSERT INTO child、UPDATE child SET parent_id = ?、DELETE FROM parent）时，InnoDB必须验证参照完整性——也就是确保子表要写的parent_id在父表中真实存在。这个验证不是“查一下就完事”，而是**加锁后查**：它会先对父表对应主键行加LOCK_S（共享锁），再继续后续操作。
这不是优化器行为，是InnoDB引擎层强制逻辑。哪怕你只插一条子记录，它也要锁定父表那条被引用的行，防止其他事务同时删掉或改掉它。
为什么锁的是“行”却常被误认为“卡住整个父表”
现象上父表变慢甚至阻塞，往往不是因为锁了太多行，而是因为parent_id列在子表上没索引：
- 子表外键列缺失有效索引 → InnoDB无法快速定位哪些子行依赖该父记录 → 只能全表扫描子表
- 扫描过程中，每碰到一个匹配的子行，就对父表那条记录重复加一次
LOCK_S（虽然S锁可重入，但锁管理开销剧增） - 更糟的是：若此时有事务正尝试
DELETE FROM parent WHERE id = X，它需要LOCK_X，但被一堆未释放的LOCK_S挡着，就会卡在“waiting for lock”
所以你看到的“父表卡住”，本质是父表某行被高频、重复、不可控地加S锁，叠加子表全表扫描带来的CPU与IO压力。
SHOW ENGINE INNODB STATUS里看不到父表S锁？正常
performance_schema.data_locks和INNODB STATUS默认不显式列出外键检查触发的LOCK_S——它被归类为“隐式一致性校验锁”，不作为独立锁记录上报。你只会看到：
- 子表某行持
X锁，状态是lock_mode X locks index `PRIMARY` - 父表那行没锁记录，但事务堆栈里有
FOREIGN KEY CHECK字样 - 死锁日志中出现
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:指向子表，而*** (2) HOLDS THE LOCK(S):却只提父表某行
这时候别怀疑工具，要直接查INFORMATION_SCHEMA.KEY_COLUMN_USAGE确认外键列索引状态，比盯着锁视图更高效。
字符集/排序规则不一致会让父表S锁变成无效空转
如果子表外键列（比如user_id）和父表主键列的CHARACTER SET或COLLATION不完全一致，InnoDB在做外键比对时会发生隐式转换，导致索引失效。结果就是：
- 本该走索引快速定位父表一行，变成全表扫描父表
- 每次比对都触发一次父表全扫 + 行级S锁尝试（实际锁不住，因为值不等）
- 大量无意义的锁请求堆积，拖慢整个父表DML
用SHOW CREATE TABLE parent和SHOW CREATE TABLE child逐字段比对COLLATE值，不一致就必须ALTER TABLE ... CONVERT TO CHARACTER SET ... COLLATE ...修正。
外键隐式加S锁本身不可禁用，但它的破坏力几乎全取决于子表外键列有没有真正生效的索引——漏掉这个点，所有后续调优都是隔靴搔痒。
