优化零售类SQL查询性能：原查询耗时久需重构

背景信息 #

我正在处理三个数据表：retail_str_sales_detail、retail_store_prod、retail_store。原本的主查询可以正常运行，但执行耗时过长，所以我尝试重构出更高效的版本，目前改写的查询片段如下：

SELECT 
    SET2.PROD_NM,
    SET2.TherapeuticClass,
    set2.TOTAL,
    SET2.QTY as QUANTITY, 
    set2.MFG as MFG,
    set2.monthname as MONTHNAME,
    set2.year as YEAR, 
    ROUND(((set2.TOTAL/SET3.TOTAL)*100),2) as SHARE 
FROM (
    select 
        set1.PROD_NM AS PROD_NM, 
        set1.MFG AS MFG, 
        set1.monthname AS monthname, 
        set1.year ...

针对性优化建议 #

从你给出的查询片段来看，多层子查询嵌套大概率是性能瓶颈的核心原因，这里给你几个可落地的优化方向：

• 替换嵌套子查询为JOIN操作：如果SET3是用来计算全局/分组总计值的，建议提前通过聚合查询算出结果，再与SET2做JOIN，避免数据库重复计算多层嵌套的中间结果集。
• 添加精准的复合索引：针对查询中用到的JOIN关联字段、分组字段（比如year+monthname）、过滤条件字段创建复合索引。比如如果子查询里有按年月分组统计的逻辑，给对应表的year和monthname字段建联合索引，能大幅减少数据库扫描的数据量。
• 精简返回字段：确保所有子查询只保留后续逻辑需要用到的字段，不要用SELECT *拉取冗余数据，减少内存占用和IO开销。
• 提前完成聚合计算：如果TOTAL是聚合值，尽量在最底层从retail_str_sales_detail取数时就完成聚合，不要等到多层嵌套后再计算，缩小中间结果集的规模。
• 用EXPLAIN排查瓶颈：在查询前加上EXPLAIN关键字，查看执行计划——如果出现Using filesort、Using temporary或者type: ALL（全表扫描）的情况，这些就是需要优先优化的点。

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