MySQL大表简单SQL查询性能异常问题排查与优化咨询

问题分析与优化建议 #

1. 为何添加GROUP BY后性能大幅下降？

从EXPLAIN结果可见，带GROUP BY的查询选用了project_uid对应的索引（FK_c0bc0d43ba64ca68b4fc7b7a095），但该索引仅包含project_uid字段，不包含过滤条件last_activity_at。这导致MySQL需要完成以下高开销操作：

• 全量扫描600多万行的project_uid索引
• 对每一行执行回表操作，读取last_activity_at值进行过滤
• 对过滤后的结果做分组聚合计算

多步骤叠加的IO和计算开销，直接导致耗时远超去掉GROUP BY的查询。

2. 为何简单WHERE查询耗时30秒？

去掉GROUP BY的查询走了全表扫描（type: ALL），未使用last_activity_at的索引，核心原因有两个：

• 优化器基于统计信息判断，该时间范围的数据占比接近50%，认为全表扫描比索引扫描更高效，但实际因表数据量大、存储IO性能不足（如RDS实例规格偏低）或表碎片化严重，导致全表扫描耗时久。
• 表的统计信息过时，优化器做出了错误的执行计划选择。

优化方案 #

最直接有效的优化是创建覆盖联合索引，让查询无需回表，直接通过索引完成过滤、分组和统计：

CREATE INDEX idx_last_activity_project_uid ON tableA (last_activity_at, project_uid, uid);

该索引的优势：

1. 通过last_activity_at快速定位符合时间范围的行，避免全表/全索引扫描
2. 索引内置project_uid，可直接用于GROUP BY分组，无需额外排序或回表
3. 包含uid字段，COUNT(uid)可直接从索引取值，无需读取原表数据

额外优化建议：

• 执行ANALYZE TABLE tableA;更新表统计信息，帮助优化器生成更准确的执行计划
• 检查RDS实例规格，若为低IO性能实例（如t2/t3系列），可升级至IO优化型实例（如r5/m5系列）提升读写速度

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