我有一個針對Maridb 運行的查詢,當我們以ASC 順序查詢時,優化器檢查較少數量的記錄(r_rows)並在大約500 毫秒內完成查詢,但是當將順序切換為DESC 時,則相同的查詢需要更多時間才能完成,r_rows 約為227 萬。
這是為什麼呢?為什麼 ASC/DESC 順序會影響查詢效能?
這是 SQL 查詢
#SELECT x_nuvo_eam_scheduled_m9e_e8s0.`sys_id` FROM ( x_nuvo_eam_scheduled_m9e_e8s x_nuvo_eam_scheduled_m9e_e8s0 LEFT JOIN x_nuvo_eam_scheduled_m10s x_nuvo_eam_scheduled_maintena1 ON x_nuvo_eam_scheduled_m9e_e8s0.`scheduled_maintenance` = x_nuvo_eam_scheduled_maintena1.`sys_id` ) WHERE x_nuvo_eam_scheduled_m9e_e8s0.`status` = 'Pending' AND x_nuvo_eam_scheduled_m9e_e8s0.`scheduled_date` >= '2022-02-15 06:00:00' AND x_nuvo_eam_scheduled_maintena1.`asset` IS NULL ORDER BY x_nuvo_eam_scheduled_m9e_e8s0.`sys_created_on` ASC limit 0, 100
下面2個MariaDB分析輸出顯示執行計畫
#ASC 有序查詢完成約 503 毫秒
+---------+------------------------------------------------------------------------------------------------------------------------ | 1 result(s): +---------+------------------------------------------------------------------------------------------------------------------------ | ANALYZE | { | | "query_block": { | | "select_id": 1, | | "r_loops": 1, | | "r_total_time_ms": 503.93, | | "table": { | | "table_name": "Table_A", | | "access_type": "index", | | "possible_keys": ["idx1"], | | "key": "sys_created_on", | | "key_length": "6", | | "used_key_parts": ["sys_created_on"], | | "r_loops": 1, | | "rows": 2695302, | | "r_rows": 234328, | | "r_total_time_ms": 476.64, | | "filtered": 50, | | "r_filtered": 0.1903, | | "attached_condition": "Table_A.`status` = 'Pending' and Table_A.scheduled_date >= '2022-02-15 06:00:00'" | | }, +---------+------------------------------------------------------------------------------------------------------------------------
DESC ASC 有序查詢完成 ~9118 毫秒
r_rows significantly Larger as comparing to ASC. +---------+----------------------------------------------------------------------------------------------------------------------- | 1 result(s): +---------+----------------------------------------------------------------------------------------------------------------------- | ANALYZE | { | | "query_block": { | | "select_id": 1, | | "r_loops": 1, | | "r_total_time_ms":9118.4, | | "table": { | | "table_name": "Table_A", | | "access_type": "index", | | "possible_keys": ["idx1"], | | "key": "sys_created_on", | | "key_length": "6", | | "used_key_parts": ["sys_created_on"], | | "r_loops": 1, | | "rows": 2695302, | | "r_rows": 2.27e6, | | "r_total_time_ms": 4380.1, | | "filtered": 50, | | "r_filtered": 70.102, | | "attached_condition": "Table_A.`status` = 'Pending' and Table_A.scheduled_date >= '2022-02-15 06:00:00'" | | | }, +---------+-----------------------------------------------------------------------------------------------------------------------
P粉8484421852024-02-04 18:24:16
索引優化建議
表索引 x_nuvo_eam_scheduled_m9e_e8s(狀態、scheduled_date、scheduled_maintenance、sys_created_on) x_nuvo_eam_scheduled_m10s ( sys_id )
然後,修改為沒有 (parens) 和 ticks
,但也使用了預定 vs 維護的更乾淨的別名。第一個表格具有適當的索引來優化 WHERE 和 JOIN 標準將會有所幫助。但建立完成覆蓋索引也將有助於查詢,因為所有元素都可以來自索引,而不是返回每個資料表的原始資料頁。
SELECT sched.sys_id FROM x_nuvo_eam_scheduled_m9e_e8s sched LEFT JOIN x_nuvo_eam_scheduled_m10s maint ON sched.scheduled_maintenance = maint.sys_id WHERE sched.status = 'Pending' AND sched.scheduled_date >= '2022-02-15 06:00:00' AND maint.asset IS NULL ORDER BY sched.sys_created_on ASC limit 0, 100