>  Q&A  >  본문

MariaDB에서 DESC 명령 쿼리가 느린 이유

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粉127901279P粉127901279258일 전425

모든 응답(1)나는 대답할 것이다

  • P粉848442185

    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 기준을 최적화하려면 적절한 인덱스가 있는 첫 번째 테이블을 갖는 것이 도움이 됩니다. 그러나 전체 포함 인덱스를 생성하면 각 테이블의 원래 데이터 페이지로 돌아가는 대신 모든 요소가 인덱스에서 나올 수 있으므로 쿼리에도 도움이 됩니다.

    으아악

    회신하다
    0
  • 취소회신하다