MySQL未自动选用pp表user索引及强制索引连锁问题咨询

这是个非常典型的MySQL查询优化器决策逻辑问题，我来帮你一步步理清背后的原因：

1. 为什么MySQL没自动选用pp表possible_keys中的user索引？ #

MySQL查询优化器选择索引的核心依据是成本估算，它会对比不同执行路径的IO、CPU成本，选它认为“最便宜”的方案。没选user索引通常有这几种可能：

• 统计信息过时：如果pp表的数据量、分布最近有大变化（比如批量插入/删除），但没跑ANALYZE TABLE pp;更新统计信息，优化器拿到的是旧的行数、索引选择性数据，可能误判走user索引的成本更高。
• 索引选择性不足：如果user列的重复值很多（比如大部分行的user值都一样），优化器会认为走user索引还要做回表查询（从索引拿到主键再查全表数据），总成本反而比全表扫描更高，所以放弃这个索引。
• 关联查询的执行计划依赖：因为这是多表关联查询，优化器会综合考虑join的顺序（驱动表/被驱动表选择）。如果它原本打算把pp作为被驱动表，可能觉得用其他索引或者全扫更适配整体的join策略，而不是单独看pp表的最优索引。

2. 强制pp表使用user索引后，为什么pp2表的user索引不再被使用？ #

当你用FORCE INDEX(user)强制pp表的索引后，相当于打破了优化器原本的执行计划平衡，引发了连锁反应：

• join顺序改变：原本优化器可能选择pp2作为驱动表，现在pp被强制走user索引后返回的结果集行数、顺序变了，优化器会重新评估join顺序，可能把pp改成驱动表。这时候pp2作为被驱动表，优化器会重新计算它的访问成本，可能觉得走全表扫描或者其他索引更适配新的驱动结果集。
• 成本估算偏差：强制pp的索引后，优化器对pp返回的行数估算可能和实际有差异，进而影响对pp2表关联时的行数预期。比如原本以为pp返回100行，实际返回1000行，优化器可能觉得给pp2用user索引的回表成本太高，转而选其他方式。
• 索引适配性变化：不同的join算法（嵌套循环、哈希连接、合并连接）对索引的要求不同。强制pp走user索引后，优化器可能切换了join算法，导致pp2的user索引不再适配新的算法需求。

3. 为什么强制两个表用user索引后，p表自动选用主键索引？ #

当pp和pp2都通过user索引过滤出了精准的小结果集后，和p表关联时，优化器会发现：用p表的主键索引来匹配关联键，单次查找的成本极低（主键索引是聚簇索引，直接能拿到整行数据，不需要回表），而且因为关联的结果集已经很小，总的查找成本远低于其他索引或全表扫描，所以自动选择了主键索引。

实用建议 #

• 先跑ANALYZE TABLE pp pp2;更新统计信息，再看优化器是否能自动选对索引，这是最常见的解决办法。
• 用EXPLAIN FORMAT=JSON查看详细的成本估算日志，能看到优化器放弃某个索引的具体原因（比如rows、cost的数值对比）。
• 检查user索引的选择性：可以用SELECT COUNT(DISTINCT user)/COUNT(*) FROM pp;计算，比值越高（接近1）选择性越好，优化器更愿意选它。

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