如下mysql语句，为什么加上ORDER BY t.CREATED_Date DESC后速度变得特别慢？

Question

不加ORDER BY t.CREATED_Date DESC查询需要2秒
加上后，查询需要15秒
如果单独查询一个rd_pro_inventory_temp表的话，加不加都是几毫米而已，这是为什么呀？

 SELECT
            t.LAST_UPD_BY,
            t.LAST_UPD_DATE,
            CASE 
                WHEN t.ADD9 = 0 THEN det.item_code 
                ELSE NULL 
            END AS LOC_CODE,
            CASE 
                WHEN t.ADD9 = 1 THEN det.item_code 
                ELSE NULL 
            END AS PRODUCT_CODE
        FROM 
            rd_pro_inventory_temp t
        LEFT JOIN (
            SELECT 
                tem_desc,
                factory_code,
                GROUP_CONCAT(item_code) AS item_code
            FROM 
                rd_pro_inventory_temp_det
            GROUP BY 
                tem_desc, 
                factory_code
        ) det ON det.tem_desc = t.TEM_DESC 
            AND det.factory_code = t.FACTORY_CODE
        WHERE 
            1 = 1 
            AND t.active_flag = '1' 
            AND t.FACTORY_CODE = '6640'
        ORDER BY 
            t.CREATED_Date DESC

Answer 1

不带ORDER BY与带有ORDER BY查询性能对比
问题描述：
不包含ORDER BY t.CREATED_Date DESC的查询耗时大约2秒。
添加ORDER BY t.CREATED_Date DESC后查询耗时增加到约15秒。
单独查询rd_pro_inventory_temp表时，无论是否包含ORDER BY子句，查询响应时间都很短。

原因推测：
索引利用与排序成本：
加入ORDER BY t.CREATED_Date DESC后，若该字段上不存在合适的索引，MySQL将不得不对整个结果集进行物理排序（即文件排序），这一过程相比无排序时更为耗时。

JOIN操作的影响：
查询包含了对rd_pro_inventory_temp表与其他通过子查询得到的结果集之间的LEFT JOIN。这种连接操作可能导致结果集急剧膨胀，进而使得后续的排序操作变得更加复杂和耗资源。

索引利用率区别：
在只查询rd_pro_inventory_temp表时不涉及JOIN操作，即使CREATED_Date字段未被索引，较小的数据量也有可能使排序快速完成。然而，一旦涉及到JOIN和大规模结果集，无索引排序的成本便凸显出来。

优化建议：
索引优化：确认rd_pro_inventory_temp表中的CREATED_Date字段已创建适当的索引，以便于排序操作。

JOIN与子查询分析：检查JOIN子查询的结果集大小，优化子查询逻辑，如可能的话，减少或优化GROUP_CONCAT函数的使用以减小数据处理负载。

查询执行计划审查：通过EXPLAIN工具分析查询执行计划，确认是否有效地利用了索引，以及排序阶段的具体执行情况，据此作出有针对性的优化调整。

Answer 2

仅仅就你这个语句，所有查询都在t表的话，开个子查询说不定有好效果，因为结果缩了再join不一定慢

你这个order by了 没索引扫全表；

在就是如果是程序用，用内存排也不是不行啊