SQL 최적화: SQL 성능을 향상시키는 매우 간단한 기사입니다!

SQL 쿼리에서 쿼리 효율성을 높이기 위해 쿼리문을 최적화하기 위한 몇 가지 조치를 취하는 경우가 많습니다. 필요한 경우 아래에 요약된 방법 중 일부를 참조할 수 있습니다. 어느 운영자의 최적화 경험에서 비교적 흥미로운 SQL을 접한 적이 있는데, 내용은 다음과 같습니다.

1 초기 SQL의 실행은 다음과 같습니다.

SQL> SELECT
  2    NVL(T.RELA_OFFER_SPEC_ID, SUBOS.SUB_OFFER_SPEC_ID) "offerSpecId"
  3    FROM OFFER_SPEC_RELA T
  4    LEFT JOIN OFFER_SPEC_GRP_RELA SUBOS
  5    ON T.RELA_GRP_ID     = SUBOS.OFFER_SPEC_GRP_ID
  6    AND subos.start_dt  <= SYSDATE
  7    AND subos.end_dt    >= SYSDATE
  8    WHERE T.RELA_TYPE_CD = 2
  9    AND t.start_dt      <= SYSDATE
 10    AND t.end_dt        >= SYSDATE
 11    AND (T.OFFER_SPEC_ID = 109910000618
 12    OR EXISTS
 13      (SELECT A.OFFER_SPEC_GRP_ID
 14      FROM OFFER_SPEC_GRP_RELA A
 15      WHERE A.SUB_OFFER_SPEC_ID = 109910000618
 16      AND T.OFFER_SPEC_GRP_ID   = A.OFFER_SPEC_GRP_ID
 17      ))
 18    AND rownum<500;

no rows selected
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1350156609

Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter(ROWNUM<500)
   2 - filter("T"."OFFER_SPEC_ID"=109910000618 OR  EXISTS (SELECT 0 FROM
              "SPEC"."OFFER_SPEC_GRP_RELA" "A" WHERE "A"."OFFER_SPEC_GRP_ID"=:B1 AND
              "A"."SUB_OFFER_SPEC_ID"=109910000618))
   3 - access("T"."RELA_GRP_ID"="SUBOS"."OFFER_SPEC_GRP_ID"(+))
   4 - filter("T"."RELA_TYPE_CD"=2 AND "T"."END_DT">=SYSDATE@! AND
              "T"."START_DT"<=SYSDATE@!)
   5 - filter("SUBOS"."END_DT"(+)>=SYSDATE@! AND "SUBOS"."START_DT"(+)<=SYSDATE@!)
   6 - access("A"."SUB_OFFER_SPEC_ID"=109910000618 AND "A"."OFFER_SPEC_GRP_ID"=:B1)
 
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      12444  consistent gets
          0  physical reads
          0  redo size
        339  bytes sent via SQL*Net to client
        509  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed
 
                  PLAN                     GET     DISK    WRITE              ROWS      ROWS USER_IO(MS)  ELA(MS)  CPU(MS) CLUSTER(MS)    PLSQL
END_TI I    HASH VALUE EXEC           PRE EXEC PRE EXEC PER EXEC ROW_P    PRE EXEC PRE FETCH    PER EXEC PRE EXEC PRE EXEC    PER EXEC PER EXEC

2 첫 번째 분석
이때 주의해야 할 점은 다음과 같습니다
1) 이 SQL은 하루에 수천 번 실행되며, 각 실행마다 평균적으로 10행 미만의 데이터가 반환되지만, 평균 논리적 읽기는 1.2W에 달합니다. 성능 문제.
2) 실행 계획 경로에는 ID 4와 5의 전체 테이블 스캔이 두 개 있습니다. 이를 보면 적절한 인덱스가 없어 전체 테이블 스캔이 발생하고 실행 효율성이 낮을 수 있다고 생각할 수 있습니다.
3) FILTER는 ID 2의 실행 계획 경로에 나타나며, 3, 6은 하위 경로입니다. FILTER에 두 개 이상의 하위 경로가 있는 경우 실행 원리는 중첩 루프, id와 유사합니다. ID 번호가 가장 작은 하위 경로가 많은 행을 반환하면 ID 번호가 더 작은 하위 경로가 여러 번 실행되어 성능이 저하될 수 있습니다. 이러한 상황은 일반적으로 "OR EXISTS"가 존재할 때 발생하며 상황에 따라 피할 수 있습니다.

관련 링크:

성능 최적화를 위한 PHP-FPM, php-fpm 성능 최적화

[SQL] MySQL 성능 최적화_MySQL

MySQL 최적화 비디오 튜토리얼

위 내용은 SQL 최적화: SQL 성능을 향상시키는 매우 간단한 기사입니다!의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!