Maridb에 대해 실행 중인 쿼리가 있는데 ASC 순서로 쿼리하면 옵티마이저는 더 적은 수의 레코드(r_rows)를 확인하여 약 500ms 안에 쿼리를 완료하지만 순서를 DESC로 전환하면 동일하게 쿼리에 더 많은 시간이 걸립니다. 완료해야 하며 r_rows는 약 227만 개입니다.
이게 왜요? ASC/DESC 순서가 쿼리 성능에 영향을 미치는 이유는 무엇입니까?
SQL 쿼리입니다
으아악다음 2개의 MariaDB 분석 출력은 실행 계획을 보여줍니다
ASC 주문 쿼리는 ~503ms 안에 완료됩니다
으아악DESC ASC 주문 쿼리 완료 ~9118ms
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
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
을 사용하지 않도록 수정했지만 예정된 대 . WHERE 및 JOIN 기준을 최적화하려면 적절한 인덱스가 있는 첫 번째 테이블을 갖는 것이 도움이 됩니다. 그러나 전체 포함 인덱스를 생성하면 각 테이블의 원래 데이터 페이지로 돌아가는 대신 모든 요소가 인덱스에서 나올 수 있으므로 쿼리에도 도움이 됩니다.