含SUM与GROUP BY的MySQL查询性能优化求助

核心问题定位 #

带SUM()聚合和GROUP BY的查询性能骤降，说明聚合阶段处理效率极低，大概率是聚合前的数据量过大，或是聚合操作未利用到合适的索引。

具体优化措施 #

1. 提前过滤数据，压缩聚合基数 #

• 把WHERE子句中的占位符（'' = ''或TT.Currency_Id =''）替换为真实业务过滤条件，尽可能在聚合前筛选出最小范围的数据；若必须保留占位符，确保查询能触发索引扫描而非全表扫描。
• 将过滤条件下推到子查询，先对单表做精准筛选再关联，避免先关联大表再处理海量数据。

2. 针对聚合操作优化索引 #

• 创建覆盖索引，包含GROUP BY字段、SUM用到的字段，以及WHERE子句的过滤字段。例如分组字段为TenderId、聚合字段为Amount、过滤字段为Currency_Id时，可创建：

  CREATE INDEX idx_tx_currency_tender_amount ON TenderTransaction(Currency_Id, TenderId, Amount);
  

• 利用索引的有序性，让数据库无需额外排序即可完成聚合，消除Using filesort的性能开销。

3. 重构查询逻辑，分步聚合 #

• 先对大表做预聚合，再关联小表。比如先对95000行的交易表按分组字段聚合出SUM结果，再关联仅100条记录的Tender表：

  SELECT t.TenderId, t.TenderName, agg.TotalAmount
  FROM Tender t
  JOIN (
      SELECT TenderId, SUM(Amount) AS TotalAmount
      FROM TenderTransaction
      WHERE Currency_Id = '真实业务值' -- 替换占位符
      GROUP BY TenderId
  ) agg ON t.TenderId = agg.TenderId
  -- 追加其他过滤条件
  

  这种方式将聚合操作限制在单表内，避免多表关联后再处理大量数据。

4. 排查执行计划的关键瓶颈 #

• 检查执行计划中是否存在全表扫描（ALL类型），若有，确认对应表的索引是否被正确调用，必要时强制指定索引（仅在确认索引有效时使用）。
• 重点关注Using temporary和Using filesort提示，这两类操作是聚合慢的常见诱因，通过优化索引消除它们。

5. 更新表统计信息 #

• 执行ANALYZE TABLE更新各表的统计信息，让优化器生成更优的执行计划：

  ANALYZE TABLE Tender, TenderTransaction, [其他关联表名];
  

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