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 は 1 日に何千回も実行され、平均して各実行で返されるデータは 10 行未満ですが、平均論理読み取りは 1.2W に達します。パフォーマンス上の問題を引き起こします。
2) 実行プラン パスに ID 4 と 5 の 2 つのフル テーブル スキャンが表示されます。これを見ると、適切なインデックスがない可能性があり、その結果、フル テーブル スキャンが発生し、実行効率が低下する可能性があります。
3) FILTER は ID 2 で実行プランのパスに表示され、3 と 6 はそのサブパスです。FILTER に 2 つ以上のサブパスがある場合、その実行原理は入れ子になったループと同様になります。最小の ID 番号を持つサブパスは大量の行を返すため、より小さい ID 番号を持つサブパスが複数回実行され、パフォーマンスが低下する可能性があります。この状況は通常、「OR EXISTS」が存在する場合に発生し、状況に応じて回避できます。

関連リンク:

パフォーマンス最適化のための PHP-FPM、php-fpm パフォーマンス最適化

[SQL] MySQL パフォーマンス最適化_MySQL

MySQL 最適化ビデオチュートリアル

以上がSQL 最適化: SQL パフォーマンスを向上させるための非常にシンプルな記事です。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。