我有一個針對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'" |
| | },
+---------+----------------------------------------------------------------------------------------------------------------------- 
索引優化建議
表索引 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