accesssql效率_SQL优化：很简单的⼀篇提⾼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 d_dt >= SYSDATE
8 WHERE T.RELA_TYPE_CD = 2
9 AND t.start_dt <= SYSDATE
10 d_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
access转mysql教程视频
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)ID 为 2 的执⾏计划路径出现了 FILTER，且 3，和 6 为其⼦路径，如果FILTER有两个及两个以上的⼦路径，那么他的执⾏原理将类似于嵌套循环，id 号最⼩的⼦路径如果返回⾏数较多，可能会导致多次执⾏id号更⼩的⼦路径，导致性能低下。⼀般存在 “OR EXISTS” 的时候会出现此情况，可以根据情况避免。
相关链接：
PHP-FPM实现性能优化，php-fpm性能优化
【SQL】MySQL性能优化_MySQL
MySQL优化视频教程

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。