如下mysql语句，为什么加上ORDER BY t.CREATED_Date DESC后速度变得特别慢？-灵析社区
ApplePro不加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
D_Y_大师不带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工具分析查询执行计划，确认是否有效地利用了索引，以及排序阶段的具体执行情况，据此作出有针对性的优化调整。