MySQL外键字段无索引会导致关联查询极慢且易锁表，因InnoDB不自动为普通外键列建索引，缺失时父表删除需子表全表扫描；应手动添加单列或复合索引，并避免滥用ON DELETE CASCADE及在高并发表中使用外键。
查外键字段但没索引的原理是什么
MySQL 的外键约束本身不自动创建索引，但要求被引用列（父表）和引用列（子表）必须有索引（否则建外键会报错 ERROR 1822 (HY000)）。不过，**子表上的外键字段常被遗漏索引**——尤其是后期加外键、或从其他系统导入表结构时。这类字段在 JOIN、DELETE CASCADE、UPDATE 等操作中极易成为全表扫描瓶颈。
核心判断逻辑是：找出所有外键列，再排除掉那些已作为任何索引首列（或唯一前缀）存在的列。
用 INFORMATION_SCHEMA 一次性筛出无索引外键列
执行以下查询即可列出所有「定义了外键但该字段未被任何索引覆盖」的列：
SELECT
CONCAT(kcu.TABLE_SCHEMA, '.', kcu.TABLE_NAME) AS `table`,
kcu.COLUMN_NAME AS `fk_column`,
kcu.REFERENCED_TABLE_NAME AS `ref_table`,
kcu.REFERENCED_COLUMN_NAME AS `ref_column`
FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE kcu
WHERE kcu.REFERENCED_TABLE_SCHEMA IS NOT NULL
AND NOT EXISTS (
SELECT 1
FROM INFORMATION_SCHEMA.STATISTICS s
WHERE s.TABLE_SCHEMA = kcu.TABLE_SCHEMA
AND s.TABLE_NAME = kcu.TABLE_NAME
AND s.COLUMN_NAME = kcu.COLUMN_NAME
AND s.SEQ_IN_INDEX = 1 -- 只要该列是某个索引的第一列，就认为可高效用于外键查找
)
ORDER BY `table`, `fk_column`;说明：
-
KEY_COLUMN_USAGE是获取外键定义的唯一可靠来源（SHOW CREATE TABLE不易解析，且不包含跨库信息） -
STATISTICS中SEQ_IN_INDEX = 1表示该列是索引的最左前缀——这是 MySQL 利用索引做外键检查/JOIN 的前提 - 如果某外键列出现在复合索引的第 2+ 位（如
INDEX(a,b)中的b），它无法支撑外键约束的快速查找，会被本查询捕获
为什么不能只看 SHOW INDEX 或 EXPLAIN
这两个方法容易漏判或误判：
-
SHOW INDEX FROM tbl只显示索引结构，不关联外键定义，需人工比对，易出错 -
EXPLAIN SELECT ... JOIN看执行计划，但仅反映当前查询路径；外键字段可能在 DELETE 或 ON UPDATE CASCADE 场景下才触发索引需求，而这些操作不会出现在普通EXPLAIN中 - 某些 ORM（如 Django、Laravel）生成的迁移脚本会建外键但不建索引，此时
SHOW CREATE TABLE看不出问题
加索引时要注意字段顺序和类型匹配
给外键列补索引不是简单执行 ALTER TABLE t ADD INDEX (col) 就完事：
- 若该列已存在于一个复合索引末尾（如已有
INDEX(a, b, fk_col)），但查询常用WHERE fk_col = ?，这个索引无效——必须新建单列索引或调整顺序为INDEX(fk_col, a, b) - 外键列与父表被引用列的类型必须严格一致（含符号、长度、字符集），否则即使建了索引，MySQL 也可能拒绝使用（例如
INT对SMALLINT UNSIGNED） - 对大表加索引建议用
ALGORITHM=INPLACE, LOCK=NONE（MySQL 5.6+），避免锁表；但需确认存储引擎支持（InnoDB 支持，MyISAM 不支持）
真正麻烦的是那些历史遗留表——外键列名不规范、存在多列组合外键、或索引命名混乱。这种情况下，光靠 SQL 查不够，得结合业务查询模式判断是否真需要索引，而不是机械补全。
