会，外键字段没索引极易导致死锁：InnoDB执行主表DELETE/UPDATE时，若子表外键列无索引，将全表扫描并加S锁，与插入意向锁等冲突形成ABBA死锁闭环。
外键字段没索引会导致死锁吗
会，而且非常容易。InnoDB 在执行涉及外键的 DML（如 DELETE、UPDATE 主表记录）时，会自动在子表对应外键列上加 SELECT ... LOCK IN SHARE MODE 类型的隐式锁——但前提是这个外键列**没有索引**。此时 InnoDB 只能走全表扫描，锁住所有行（或大量间隙），极大增加与其他事务的锁冲突概率。
- 外键约束本身不强制要求索引，但缺失索引会让锁范围从“单行/单间隙”扩大为“全表级扫描锁”
- 常见组合：主表
DELETE FROM users WHERE id = 123+ 子表orders(user_id)无索引 → 子表全表加 S 锁 - 若此时另一事务正执行
INSERT INTO orders VALUES (..., 456)，就会因插入意向锁（Insert Intention Lock）与全表 S 锁冲突而卡住 - 两个事务交叉等待，就构成典型死锁闭环
怎么确认是外键引发的隐性锁
不能只看 SQL 文本，得查死锁日志里的锁资源定位信息。重点盯住 HOLDS THE LOCK(S) 和 WAITING FOR THIS LOCK 中的 index 名和 space id。
- 如果日志中出现类似
index `GEN_CLUST_INDEX`或index `PRIMARY`以外的、你没手动建过的索引名，大概率是 InnoDB 自动生成的外键隐式索引（但这种极少） - 更常见的是：锁落在子表上，但锁的
index显示为GEN_CLUST_INDEX（聚簇索引伪索引），且page no范围很大 → 暗示全表扫描 - 执行
SHOW CREATE TABLE child_table\G，检查外键列是否在任何KEY或INDEX中；若没有，就是根因 - 用
SELECT * FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'child_table' AND COLUMN_NAME = 'fk_col';查外键定义，再比对SHOW INDEX FROM child_table;
给外键字段加索引的实操要点
不是随便 CREATE INDEX 就完事。索引必须覆盖外键列，且顺序、类型、NULL 属性要严格匹配约束定义。
- 外键列必须是索引的最左前缀；单列外键直接建单列索引即可：
CREATE INDEX idx_fk_user_id ON orders(user_id); - 如果是联合外键（如
(user_id, status)），索引必须按相同顺序包含这两列：CREATE INDEX idx_fk_user_status ON orders(user_id, status); - 注意 NULL 属性：若外键列允许
NULL，索引仍有效；但若业务逻辑里大量WHERE user_id IS NULL，该索引对这部分查询无效，需另建 - 避免冗余：已有复合索引
(user_id, created_at)，再单独建(user_id)是浪费；但若查询常以user_id单独过滤，前者可能不如后者高效 - 加索引前先
EXPLAIN验证原外键操作是否真走全表扫描：EXPLAIN SELECT * FROM orders WHERE user_id = 123;
为什么加了索引还死锁
索引只是基础条件，不是银弹。加完索引后仍死锁，往往是因为事务中多个外键操作顺序不一致，或混合了其他锁行为。
- 两个事务都操作主表 A 和子表 B、C，但事务 1 先删 A 再删 B，事务 2 先删 A 再删 C → 外键检查锁顺序不同，形成环路
- 事务里混用了
FOR UPDATE和外键隐式锁，比如SELECT ... FOR UPDATE锁了子表某行，紧接着又触发主表删除 → 锁叠加 - RR 隔离级别下，外键列上有范围查询（如
WHERE user_id BETWEEN 100 AND 200），即使有索引也会加 Gap Lock，与插入意向锁冲突 - ORM 自动生成 SQL 顺序不可控：MyBatis 的
<foreach>删除列表顺序随机，导致不同请求加锁顺序不一致
外键死锁最难缠的地方在于它不显式出现在你的 SQL 里——你只写了 DELETE FROM users，却不知道背后 InnoDB 正在子表上扫全表加锁。排查时必须跳出 SQL 文本，直奔锁资源页号和索引名，否则永远在猜。
