Maison > Article > base de données > Optimisation SQL : Un article très simple pour améliorer les performances SQL !
Afin d'améliorer l'efficacité des requêtes SQL, nous prenons souvent certaines mesures pour optimiser les instructions de requête. Certaines des méthodes résumées ci-dessous peuvent être consultées si nécessaire. Dans l'expérience d'optimisation d'un certain opérateur, j'ai rencontré une fois un SQL intéressant, qui est le suivant :
1 L'exécution du SQL initial est la suivante
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 Première analyse
À ce stade, les points suivants devraient être notés
1 ) Le SQL est exécuté des milliers de fois chaque jour et, en moyenne, chaque exécution renvoie moins de 10 lignes de données, mais la lecture logique moyenne atteint 1,2 W, ce qui peut entraîner des problèmes de performances.
2) Il y a deux analyses de table complètes dans le chemin du plan d'exécution avec les ID 4 et 5. En voyant cela, nous pouvons penser qu'il n'y a peut-être pas d'index approprié, ce qui entraîne une analyse de table complète et une faible efficacité d'exécution.
3) FILTER apparaît dans le chemin du plan d'exécution avec l'ID 2, et 3, et 6 sont ses sous-chemins. Si FILTER a deux sous-chemins ou plus, alors son principe d'exécution sera similaire à une boucle imbriquée, si. le sous-chemin avec le plus petit numéro d'identification renvoie un grand nombre de lignes, cela peut entraîner l'exécution multiple du sous-chemin avec le plus petit numéro d'identification, ce qui entraîne de faibles performances. Cette situation se produit généralement lorsque « OU EXISTE » existe et peut être évitée selon la situation.
Liens connexes :
PHP-FPM réalise l'optimisation des performances, l'optimisation des performances php-fpm
[SQL] Performances MySQL Optimization_MySQL
Tutoriel vidéo d'optimisation MySQL
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!