外键约束本身不自动创建索引，但必须手动建索引才能生效
MySQL 的 InnoDB 存储引擎要求：定义
FOREIGN KEY时，**被引用的列（父表的主键或唯一键）不需要额外索引，但引用列（子表中的外键列）必须有索引**。否则创建外键会失败，报错类似：
ERROR 1822 (HY000): Failed to add the foreign key constraint. Missing index for constraint...。
☞☞☞☞点击夸克AI手把手教你，操作像呼吸一样简单！☜☜☜☜☜
这个索引不是外键“自带”的，而是你显式创建的——哪怕只建一个单列索引，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卡顿，再去查子表有没有索引，往往已经晚了。
