MySQL查询未使用primary key致性能变慢，求助排查优化

这种因为主键未被合理利用导致查询变慢的情况，在多表关联场景里真的挺常见的，我来帮你一步步分析和解决：

先梳理下涉及的表结构 #

先把你提到的表结构补全并整理清楚（默认production_role_episodes的episode_index是关联episode_info.episode_index）：

• staff_main
  • staff_ID (INT, PRIMARY KEY)
  • name (STRING)
• production_role
  • row_index (INT, PRIMARY KEY, AUTO_INCREMENT)
  • staff_ID (INT, INDEXED)
  • production_ID (INT, INDEXED)
  • role_ID (INT)
• production_role_episodes
  • row_index (INT, PRIMARY KEY, AUTO_INCREMENT)
  • match_index (INT, FOREIGN KEY → production_role.row_index)
  • episode_index (INT, FOREIGN KEY → episode_info.episode_index)

核心问题分析：主键为啥没被用到？ #

你说的“未使用其中一个primary key”，大概率是指production_role.row_index或者staff_main.staff_ID，常见原因有这几个：

1. 关联/过滤条件没触发主键路径：比如查询优先用了production_ID或staff_ID的二级索引，优化器觉得走二级索引更高效，但实际回表开销更大；
2. 字段类型不匹配：比如关联staff_main.staff_ID和production_role.staff_ID时，一个是INT一个是VARCHAR，触发隐式转换导致主键索引失效；
3. 查询写法限制：比如用函数包裹主键字段（CAST(row_index AS CHAR)）、OR条件拆分，导致主键索引无法被利用。

针对性优化方案 #

1. 先看查询计划，定位问题

先跑EXPLAIN分析你的查询语句，明确哪个主键没被用到，以及优化器选了什么索引：

EXPLAIN
-- 替换成你的实际查询语句
SELECT sm.name, pr.production_ID, pre.episode_index
FROM staff_main sm
JOIN production_role pr ON sm.staff_ID = pr.staff_ID
JOIN production_role_episodes pre ON pr.row_index = pre.match_index
WHERE pr.production_ID = 123;

重点看key列（显示用到的索引）、type列（最优是eq_ref/const）、Extra列（有没有Using filesort/Using temporary这类瓶颈）。

2. 添加覆盖型复合索引（最推荐）

如果查询只用到production_role的production_ID、staff_ID、row_index这几个字段，创建复合索引让优化器不用回表，同时能直接关联production_role_episodes：

CREATE INDEX idx_prod_role_prod_staff_row ON production_role (production_ID, staff_ID, row_index);

这个索引是覆盖索引，优化器可以直接从索引里拿到所有需要的数据，既避免回表，又能顺畅用row_index关联子表。

3. 修正关联字段类型（如果是类型不匹配问题）

如果staff_main.staff_ID和production_role.staff_ID类型不一致，比如一个是INT一个是VARCHAR，赶紧把类型统一成INT，消除隐式转换，主键索引就能正常被利用了。

4. 谨慎强制使用主键（万不得已才用）

如果优化器确实选错了索引，你可以用FORCE INDEX强制走主键，但别随便用，得确认主键路径真的更快：

SELECT sm.name, pr.production_ID, pre.episode_index
FROM staff_main sm
JOIN production_role pr FORCE INDEX (PRIMARY) ON sm.staff_ID = pr.staff_ID
JOIN production_role_episodes pre ON pr.row_index = pre.match_index
WHERE pr.production_ID = 123;

内容的提问来源于stack exchange，提问作者Leonide