外键约束不会直接升级锁，但缺失有效索引会导致行锁退化为等效表锁；innodb仅在外键列未被任何现有索引覆盖时自动建索引，若联合索引(a,b)中b为外键，则b单独查询将全表扫描，必须为其创建单列索引。
外键约束不会“升级”锁，但会让行锁退化成等效表锁——根本原因是外键列缺失有效索引。
查外键列有没有真正生效的索引
别只看 SHOW CREATE TABLE 里有没有 INDEX 关键字。InnoDB 只在“外键列未被任何现有索引覆盖”时才自动建索引；如果已有联合索引 (a, b)，再把 b 设为外键，InnoDB 就不额外建索引，b 单独查询就会全表扫描。
- 运行这个查询确认索引状态：
SELECT kcu.COLUMN_NAME, kcu.REFERENCED_TABLE_NAME, IF(t.index_name IS NULL,'MISSING','OK') AS index_status FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE kcu LEFT JOIN ( SELECT TABLE_NAME, COLUMN_NAME, INDEX_NAME FROM INFORMATION_SCHEMA.STATISTICS WHERE SEQ_IN_INDEX = 1 ) t ON kcu.TABLE_NAME = t.TABLE_NAME AND kcu.COLUMN_NAME = t.COLUMN_NAME WHERE kcu.REFERENCED_TABLE_SCHEMA = 'your_db' AND kcu.TABLE_NAME = 'child_table';
-
index_status是MISSING？立刻补单列索引：ALTER TABLE child_table ADD INDEX idx_fk_user_id (user_id); - 字符型外键还要核对
CHARACTER SET和COLLATION是否与父表完全一致，否则索引失效
用 performance_schema.data_locks 看不到外键锁？正常
外键检查触发的锁是隐式的，在 performance_schema.data_locks 里不会显示为独立锁记录。它附着在父表操作事务之后，表现为子表某行被加了 X 锁，但日志里不提“外键”二字。
- 想确认是不是外键惹的祸，优先看
SHOW ENGINE INNODB STATUS\G中的LATEST FOREIGN KEY ERROR段：有记录 → 外键检查已触发；没记录 → 排除外键环节 - 死锁日志里看到两个事务分别持有
parent_table和child_table的X锁并互相等待 → 典型 ABBA，外键让这种模式更容易形成 - 别依赖
HOLDS THE LOCK(S)字段，它只显示最近事务，静默持有者会被漏掉
级联操作是隐式锁放大器，必须拆解
ON DELETE CASCADE 或 ON UPDATE CASCADE 不是原子优化操作，而是逐行执行、逐行加锁。数据量一大，锁住的行数就多，等效于锁表。
- 把级联删/改替换成显式两步：
SELECT id FROM child_table WHERE parent_id = ?→ 收集 ID 列表 →DELETE FROM child_table WHERE id IN (...) - 所有事务统一按「先父后子」顺序操作，避免与级联内部锁序冲突
- 如果业务上只是防孤儿数据，用
ON DELETE RESTRICT+ 应用层校验更可控；真要级联，确保父表和子表操作在同一个事务内完成
最容易被忽略的是：即使父表主键有索引，子表外键列也必须单独建索引——InnoDB 不复用父表索引，也不共享联合索引中的非前缀列。没索引的外键，不是慢一点，是直接把行锁拖垮成锁表行为。
