生产环境快速执行的MySQL查询在本地副本中极慢，索引基数差异是否有影响？

这种情况我碰到过好多次——生产库跑飞快的查询，到了本地测试库就卡成狗，排查到最后往往就是索引统计信息的锅。

先给你掰明白什么是Cardinality：它是MySQL对索引中唯一值数量的估算值，不是精确数。查询优化器全靠这个数值来判断「用哪个索引效率更高」——比如一个索引基数越高，说明它的过滤性越好（能快速缩小结果集范围），优化器就更倾向于选择它；反之，如果基数估算得特别低，优化器会觉得这个索引没用，甚至直接放弃走索引，改成全表扫描，那速度自然就崩了。

为什么你的本地库和生产库基数不一样？

• 生产库是一直在运行的，MySQL会自动（或者定期）更新索引的统计信息，基数是基于真实数据计算的，准确度很高；
• 而你把生产库导出导入到本地后，默认情况下MySQL不会自动重新收集全量统计信息，本地的基数可能只是导入时的粗略估算，和真实数据偏差极大。比如生产库某个索引基数是10万，本地可能只估算成几百，优化器一看这索引这么「没用」，当然不会选它。

怎么解决？ #

1. 强制更新统计信息：对涉及到的表执行ANALYZE TABLE your_table_name;，这个命令会让MySQL重新扫描表和索引，计算出准确的基数。执行完之后再跑查询，大概率速度就和生产库一致了。
2. 对比执行计划：用EXPLAIN分别在生产和本地跑你的查询，看看type字段和key字段——生产库可能显示range或者ref，用了正确的索引；本地可能显示ALL（全表扫描），或者用了其他低效的索引，这直接就能验证是不是基数导致优化器选错了索引。
3. 另外，虽然你俩的MySQL版本只差几个小版本，但统计信息的收集策略可能有细微差别，不过核心问题还是本地的统计信息过时/不准确。

举个实际例子：我之前碰到过一个订单表的查询，生产库用idx_order_time索引跑90ms，本地因为基数估算错误，优化器走了全表扫描，跑了120秒，执行ANALYZE TABLE之后，本地查询瞬间降到80ms，比生产还快（本地机器配置更好）。

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