外键约束不自动创建索引，子表外键列必须手动创建索引（单列或复合索引最左前缀）才能成功添加外键，否则报错；该索引仅服务约束检查，不提升SELECT查询性能。
外键约束本身不自动创建索引，但必须手动建索引才能生效
MySQL 的 InnoDB 存储引擎要求：定义 FOREIGN KEY 时，**被引用的列（父表的主键或唯一键）不需要额外索引，但引用列（子表中的外键列）必须有索引**。否则创建外键会失败，报错类似：ERROR 1822 (HY000): Failed to add the foreign key constraint. Missing index for constraint...。
这个索引不是外键“自带”的，而是你显式创建的——哪怕只建一个单列索引，InnoDB 就认可它
- 外键列上已有复合索引（如
INDEX (a, b, c)），且外键列是该索引最左前缀（如外键是a或a,b），则无需重复建索引 - 若外键是
c，而现有索引是(a, b, c)，则该索引不可用于外键约束检查，仍需单独建INDEX (c) -
ALTER TABLE ... ADD FOREIGN KEY不会自动帮你建索引；必须先CREATE INDEX，再加外键
外键列索引直接影响 INSERT/UPDATE/DELETE 性能
每次向子表插入或更新外键列值，InnoDB 都要查父表确认参照完整性（即值是否存在）；每次删父表记录，也要查子表是否有依赖行（除非用 ON DELETE CASCADE）。这些检查全靠子表外键列上的索引支撑。
没有索引时，这些操作会触发全表扫描，尤其子表数据量大时，INSERT 可能从毫秒级变成秒级，DELETE 父记录甚至卡住几秒以上。
- 索引缺失导致的典型慢操作：对父表执行
DELETE FROM parent WHERE id = ?，子表无索引时会扫描整个子表 - 高并发写入场景下，缺失外键索引还会加剧锁竞争——InnoDB 在做外键检查时会对子表相关行加共享锁（S 锁），无索引则可能升级为表级锁或长事务锁等待
- 即使业务逻辑保证不会违反外键（比如应用层强校验），只要定义了外键约束，InnoDB 就一定会执行检查，索引就必不可少
外键索引与查询性能无关，仅服务约束检查
给外键列建的索引，**只被外键约束机制使用，不会自动提升你的 SELECT 查询速度**。如果业务里常按该列查询（如 SELECT * FROM child WHERE parent_id = ?），这个索引恰好能复用；但如果查询条件是 WHERE status = ? AND parent_id = ?，单列 parent_id 索引效果有限，应考虑联合索引。
别误以为“加了外键就等于加了查询加速索引”——那是巧合，不是设计保障。
- 外键索引无法覆盖
SELECT中的非索引字段，回表开销照旧 - 如果已有其他更优索引（如
INDEX (parent_id, created_at)），再单独建INDEX (parent_id)属于冗余，增加写开销和存储 - 用
SHOW CREATE TABLE child检查实际建了哪些索引，别依赖外键语法“暗示”索引存在
禁用外键不等于去掉索引，也不解决根本性能问题
有人遇到外键拖慢写入，第一反应是 SET FOREIGN_KEY_CHECKS = 0 或删掉外键。但这只是绕过检查，**原有索引还在，写放大和存储成本不变；而且数据一致性完全交给应用层，风险陡增**。
真正影响性能的是索引结构和查询模式，不是外键开关。盲目关外键，反而让后续排查数据异常更困难。
-
FOREIGN_KEY_CHECKS = 0只跳过约束检查，不释放索引，INSERT/UPDATE 仍要维护该索引 - 删除外键（
ALTER TABLE ... DROP FOREIGN KEY）也不会自动删对应索引，得手动DROP INDEX - 如果确定不需要参照完整性（例如日志表、ETL 中间表），那就别定义外键；而不是先加再关
外键索引的必要性藏在错误信息里，它的性能影响却暴露在慢日志中——这两头都容易被忽略，尤其是上线后才暴露出父表 DELETE 卡顿，再去查子表有没有索引，往往已经晚了。
