两个相同MySQL InnoDB表的性能差异问题排查

我来帮你拆解这个问题——你遇到的10%-20%性能差异，确实和执行计划里的索引使用逻辑直接相关。先把这两个执行计划的核心区别讲透，再一步步排查修复：

先搞懂两个执行计划的本质差异 #

• Using index; Using where：这是覆盖索引扫描，意味着查询需要的所有字段都能从目标索引里直接获取，完全不需要回表查询主键索引的数据页。MySQL会直接通过索引过滤符合WHERE条件的记录，全程不碰表的实际数据，效率拉满。
• Using index condition; Using where：这是索引条件下推（ICP），MySQL会把部分WHERE条件下推到存储引擎层过滤数据，但最终还是需要回表获取索引中没有的字段。虽然ICP比完全不推的情况好，但相比覆盖索引多了回表的IO开销，这就是性能差距的核心来源。

为什么复制后的表会出现这个差异？ #

哪怕是完整复制表，也可能出现索引逻辑的细微偏差，常见原因有：

• 索引创建顺序不同：InnoDB的二级索引依赖聚簇索引（主键），如果复制后聚簇索引的物理存储页结构发生变化，会影响优化器的索引选择策略。
• 统计信息不一致：MySQL优化器靠表的统计数据判断执行计划，复制后的表可能没更新统计信息，导致优化器误判，没选中覆盖索引。
• 表属性不一致：比如两张表的字符集、排序规则有差异，会影响索引的比较逻辑，进而改变优化器的选择。

修复步骤，一步步来 #

1. 强制更新统计信息 #

先让MySQL重新收集两张表的统计数据，给优化器准确的判断依据：

ANALYZE TABLE database1.table_name;
ANALYZE TABLE database2.table_name;

执行完后再跑一遍查询，观察执行计划是否变化。

2. 精准对齐表结构与索引 #

仔细对比两张表的所有索引（主键、二级索引）和表属性，确保完全一致：

-- 查看完整表结构与索引定义
SHOW CREATE TABLE database1.table_name;
SHOW CREATE TABLE database2.table_name;

重点核对：

• 所有二级索引的字段顺序、类型是否完全相同
• 主键的定义（类型、是否自增）是否一致
• 表的ENGINE、CHARSET、COLLATE属性是否完全匹配
  如果有差异，立刻修正复制后的表结构，重新创建索引。

3. 手动指定覆盖索引（临时验证方案） #

如果更新统计信息后优化器仍没选对，可以用FORCE INDEX强制使用覆盖索引，先验证性能是否恢复：

SELECT 你的查询字段 FROM database2.table_name FORCE INDEX(你的覆盖索引名) WHERE 你的查询条件;

如果性能和database1的表一致，说明是优化器选择问题，此时优先保证统计信息准确，不建议随便修改全局优化器参数。

4. 整理聚簇索引物理结构 #

虽然你说没有碎片，但可以对比两张表的聚簇索引紧凑度：

SELECT 
  TABLE_SCHEMA, TABLE_NAME, 
  DATA_FREE, 
  INDEX_LENGTH 
FROM INFORMATION_SCHEMA.TABLES 
WHERE TABLE_SCHEMA IN ('database1', 'database2') 
  AND TABLE_NAME = 'table_name';

如果database2的表DATA_FREE明显偏大，或INDEX_LENGTH异常，可重建表整理聚簇索引：

ALTER TABLE database2.table_name ENGINE=InnoDB;

这个操作会重新整理表的物理存储，让聚簇索引更紧凑，帮助优化器做出正确选择。

总结 #

你的推测完全正确——性能差异就是因为一个用了无回表的覆盖索引，另一个用了需要回表的ICP。按照上面的步骤排查，优先对齐统计信息和表结构，基本就能解决问题。

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