SQL优化-大表的回表，等价条件改写，半连接改写，改变表关联顺序

最新推荐文章于 2026-08-15 09:48:09 发布
转载 最新推荐文章于 2026-08-15 09:48:09 发布 · 500 阅读 · 0
本文通过一个具体的SQL案例，展示了如何通过改变表的关联顺序、转换连接类型等手段来优化SQL查询性能，最终将查询时间从数分钟缩短到0.5秒。


总结：这个sql的优化思路是：首先确认 问题出在 mmt表的索引所描再回表上，立马想到的是消除mmt的索引扫描，索引加了 hint(full(mmt))sql5s可运行出来；但是觉得这个sql 还有优化空间，于是改写sql，将半连接改成left join，目的是利用sql中的等价条件，想让mmt表过滤的数据多一些，由于只对主表汇总，索不考虑为null的问题
，改完之后觉得过滤数据应该没问题了，但是运行不出来，于是考虑关联顺序问题，既然mmt驱动表的时候很慢就将它换成被驱动表，于是加了 hint（/*+  use_nl(OOL) leading(OOL)*/ ）sql 0.5s出

select * from table(dbms_xplan.display);
explain plan for

 --change before   run long long time
 
 SELECT 
   NVL(ABS(SUM(MMT.TRANSACTION_QUANTITY)), 0)
  FROM MTL_MATERIAL_TRANSACTIONS MMT, OE_ORDER_LINES_ALL OOL
 WHERE MMT.TRANSACTION_TYPE_ID = 33
   AND MMT.TRANSACTION_ACTION_ID = 1
   AND MMT.TRANSACTION_SOURCE_TYPE_ID = 2
   AND MMT.TRX_SOURCE_LINE_ID = OOL.LINE_ID
   AND MMT.INVENTORY_ITEM_ID = OOL.INVENTORY_ITEM_ID
   AND MMT.ORGANIZATION_ID = OOL.SHIP_FROM_ORG_ID
   AND OOL.SOLD_TO_ORG_ID = 2057

   AND EXISTS
 (SELECT 1
          FROM CUX_OE_SALEFORECAST_ALL S
         WHERE OOL.ORIG_SYS_DOCUMENT_REF = S.PLANNING_NUMBER
           AND OOL.ORG_ID = S.ORG_ID
           AND ABS(MMT.TRANSACTION_QUANTITY) = ABS(S.PRIMARY_QUANTITY)
           AND TRUNC(NVL(S.RESERVATION_DATE_TO, S.PLANNING_DATE))
            BETWEEN  to_date('11/01/2017 00:00:00','MM/DD/YYYY  hh24:mi:ss')
             AND to_date('11/10/2017 00:00:00','MM/DD/YYYY  hh24:mi:ss')
           AND TRUNC(MMT.TRANSACTION_DATE) =
               NVL(S.RESERVATION_DATE_TO, S.PLANNING_DATE));
              
               Plan hash value: 226097174 --INVENTORY_ITEM_ID, ORGANIZATION_ID, TRANSACTION_DATE
              
                ---TRANSACTION_ACTION_ID, TRANSACTION_TYPE_ID, TRANSACTION_SOURCE_TYPE_ID, TRANSACTION_DATE
 
-------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                               | Name                          | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                        |                               |     1 |   126 |   635   (2)| 00:00:01 |
|   1 |  SORT AGGREGATE                         |                               |     1 |   126 |            |          |
|   2 |   NESTED LOOPS                          |                               |     1 |   126 |   635   (2)| 00:00:01 |
|   3 |    NESTED LOOPS                         |                               |     9 |   126 |   635   (2)| 00:00:01 |
|   4 |     NESTED LOOPS                        |                               |     9 |   675 |   622   (2)| 00:00:01 |
|   5 |      SORT UNIQUE                        |                               |     2 |    72 |     9   (0)| 00:00:01 |
|*  6 |       TABLE ACCESS STORAGE FULL         | CUX_OE_SALEFORECAST_ALL       |     2 |    72 |     9   (0)| 00:00:01 |
|*  7 |      TABLE ACCESS BY INDEX ROWID BATCHED| MTL_MATERIAL_TRANSACTIONS     |     5 |   195 |   611   (2)| 00:00:01 |
|*  8 |       INDEX RANGE SCAN                  | MTL_MATERIAL_TRANSACTIONS_N15 |   579 |       |   428   (3)| 00:00:01 |
|*  9 |     INDEX UNIQUE SCAN                   | OE_ORDER_LINES_U1             |     1 |       |     1   (0)| 00:00:01 |
|* 10 |    TABLE ACCESS BY INDEX ROWID          | OE_ORDER_LINES_ALL            |     1 |    51 |     2   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   6 - storage(TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))>=TO_DATE(' 2017-11-01 00:00:00',
              'syyyy-mm-dd hh24:mi:ss') AND TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))<=TO_DATE(' 2017-11-10
              00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
       filter(TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))>=TO_DATE(' 2017-11-01 00:00:00',
              'syyyy-mm-dd hh24:mi:ss') AND TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))<=TO_DATE(' 2017-11-10
              00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
   7 - filter("TRX_SOURCE_LINE_ID" IS NOT NULL AND ABS("TRANSACTION_QUANTITY")=ABS("S"."PRIMARY_QUANTITY"))
   8 - access("TRANSACTION_ACTION_ID"=1 AND "TRANSACTION_TYPE_ID"=33 AND "TRANSACTION_SOURCE_TYPE_ID"=2)
       filter(TRUNC(INTERNAL_FUNCTION("TRANSACTION_DATE"))=NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))
   9 - access("TRX_SOURCE_LINE_ID"="OOL"."LINE_ID")
  10 - filter("OOL"."SOLD_TO_ORG_ID"=2057 AND "INVENTORY_ITEM_ID"="OOL"."INVENTORY_ITEM_ID" AND
              "ORGANIZATION_ID"="OOL"."SHIP_FROM_ORG_ID" AND "OOL"."ORIG_SYS_DOCUMENT_REF"="S"."PLANNING_NUMBER" AND
              "OOL"."ORG_ID"="S"."ORG_ID")

 
-- add hint -5s
SELECT  /*+ full(MMT)*/
   NVL(ABS(SUM(MMT.TRANSACTION_QUANTITY)), 0)
  FROM MTL_MATERIAL_TRANSACTIONS MMT, OE_ORDER_LINES_ALL OOL
 WHERE MMT.TRANSACTION_TYPE_ID = 33
   AND MMT.TRANSACTION_ACTION_ID = 1
   AND MMT.TRANSACTION_SOURCE_TYPE_ID = 2
   AND MMT.TRX_SOURCE_LINE_ID = OOL.LINE_ID
   AND MMT.INVENTORY_ITEM_ID = OOL.INVENTORY_ITEM_ID
   AND MMT.ORGANIZATION_ID = OOL.SHIP_FROM_ORG_ID
   AND OOL.SOLD_TO_ORG_ID = 2057

   AND EXISTS
 (SELECT 1
          FROM CUX_OE_SALEFORECAST_ALL S
         WHERE OOL.ORIG_SYS_DOCUMENT_REF = S.PLANNING_NUMBER
           AND OOL.ORG_ID = S.ORG_ID
           AND ABS(MMT.TRANSACTION_QUANTITY) = ABS(S.PRIMARY_QUANTITY)
           AND TRUNC(NVL(S.RESERVATION_DATE_TO, S.PLANNING_DATE))
            BETWEEN  to_date('11/01/2017 00:00:00','MM/DD/YYYY  hh24:mi:ss')
             AND to_date('11/10/2017 00:00:00','MM/DD/YYYY  hh24:mi:ss')
           AND TRUNC(MMT.TRANSACTION_DATE) =
               NVL(S.RESERVATION_DATE_TO, S.PLANNING_DATE));
              
               Plan hash value: 2114840721
 
------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                           |     1 |   126 |   611K  (2)| 00:00:24 |
|   1 |  SORT AGGREGATE                |                           |     1 |   126 |            |          |
|   2 |   NESTED LOOPS                 |                           |     1 |   126 |   611K  (2)| 00:00:24 |
|   3 |    NESTED LOOPS                |                           |     9 |   126 |   611K  (2)| 00:00:24 |
|*  4 |     HASH JOIN                  |                           |     9 |   675 |   611K  (2)| 00:00:24 |
|   5 |      SORT UNIQUE               |                           |     2 |    72 |     9   (0)| 00:00:01 |
|*  6 |       TABLE ACCESS STORAGE FULL| CUX_OE_SALEFORECAST_ALL   |     2 |    72 |     9   (0)| 00:00:01 |
|*  7 |      TABLE ACCESS STORAGE FULL | MTL_MATERIAL_TRANSACTIONS | 47905 |  1824K|   611K  (2)| 00:00:24 |
|*  8 |     INDEX UNIQUE SCAN          | OE_ORDER_LINES_U1         |     1 |       |     1   (0)| 00:00:01 |
|*  9 |    TABLE ACCESS BY INDEX ROWID | OE_ORDER_LINES_ALL        |     1 |    51 |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   4 - access(ABS("TRANSACTION_QUANTITY")=ABS("S"."PRIMARY_QUANTITY") AND
              TRUNC(INTERNAL_FUNCTION("TRANSACTION_DATE"))=NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))
   6 - storage(TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))>=TO_DATE(' 2017-11-01
              00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))<=
              TO_DATE(' 2017-11-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
       filter(TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))>=TO_DATE(' 2017-11-01
              00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))<=
              TO_DATE(' 2017-11-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
   7 - storage("TRANSACTION_TYPE_ID"=33 AND "TRANSACTION_SOURCE_TYPE_ID"=2 AND "TRX_SOURCE_LINE_ID"
              IS NOT NULL AND "TRANSACTION_ACTION_ID"=1)
       filter("TRANSACTION_TYPE_ID"=33 AND "TRANSACTION_SOURCE_TYPE_ID"=2 AND "TRX_SOURCE_LINE_ID"
              IS NOT NULL AND "TRANSACTION_ACTION_ID"=1)
   8 - access("TRX_SOURCE_LINE_ID"="OOL"."LINE_ID")
   9 - filter("OOL"."SOLD_TO_ORG_ID"=2057 AND "INVENTORY_ITEM_ID"="OOL"."INVENTORY_ITEM_ID" AND
              "ORGANIZATION_ID"="OOL"."SHIP_FROM_ORG_ID" AND "OOL"."ORIG_SYS_DOCUMENT_REF"="S"."PLANNING_NUMBER"
              AND "OOL"."ORG_ID"="S"."ORG_ID")

 


--after change sql  0.5s
select * from table(dbms_xplan.display);
explain plan for
SELECT  /*+  use_nl(OOL) leading(OOL) */
   NVL(ABS(SUM(MMT.TRANSACTION_QUANTITY)), 0)
  FROM MTL_MATERIAL_TRANSACTIONS MMT, OE_ORDER_LINES_ALL OOL
   left join   CUX_OE_SALEFORECAST_ALL s on  OOL.ORIG_SYS_DOCUMENT_REF = S.PLANNING_NUMBER
   AND OOL.ORG_ID = S.ORG_ID
 WHERE MMT.TRANSACTION_TYPE_ID = 33
   AND MMT.TRANSACTION_ACTION_ID = 1
   AND MMT.TRANSACTION_SOURCE_TYPE_ID = 2
   AND MMT.TRX_SOURCE_LINE_ID = OOL.LINE_ID
   AND MMT.INVENTORY_ITEM_ID = OOL.INVENTORY_ITEM_ID
   AND MMT.ORGANIZATION_ID = OOL.SHIP_FROM_ORG_ID
   AND OOL.SOLD_TO_ORG_ID = 2057
   AND ABS(MMT.TRANSACTION_QUANTITY) = ABS(S.PRIMARY_QUANTITY)
           AND TRUNC(NVL(S.RESERVATION_DATE_TO, S.PLANNING_DATE))
            BETWEEN  to_date('11/01/2017 00:00:00','MM/DD/YYYY  hh24:mi:ss')
             AND to_date('11/10/2017 00:00:00','MM/DD/YYYY  hh24:mi:ss')
           AND TRUNC(MMT.TRANSACTION_DATE) =
               NVL(S.RESERVATION_DATE_TO, S.PLANNING_DATE);
              
Plan hash value: 183599765
 
--------------------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name                         | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                              |     1 |   126 |   229K  (1)| 00:00:09 |
|   1 |  SORT AGGREGATE               |                              |     1 |   126 |            |          |
|   2 |   NESTED LOOPS                |                              |     1 |   126 |   229K  (1)| 00:00:09 |
|   3 |    NESTED LOOPS               |                              |     1 |   126 |   229K  (1)| 00:00:09 |
|*  4 |     HASH JOIN                 |                              |     1 |    87 |   229K  (1)| 00:00:09 |
|*  5 |      TABLE ACCESS STORAGE FULL| OE_ORDER_LINES_ALL           |   132 |  6732 |   229K  (1)| 00:00:09 |
|*  6 |      TABLE ACCESS STORAGE FULL| CUX_OE_SALEFORECAST_ALL      |     2 |    72 |     9   (0)| 00:00:01 |
|*  7 |     INDEX RANGE SCAN          | MTL_MATERIAL_TRANSACTIONS_N1 |     1 |       |     3   (0)| 00:00:01 |
|*  8 |    TABLE ACCESS BY INDEX ROWID| MTL_MATERIAL_TRANSACTIONS    |     1 |    39 |     4   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   4 - access("OOL"."ORIG_SYS_DOCUMENT_REF"="S"."PLANNING_NUMBER" AND "OOL"."ORG_ID"="S"."ORG_ID")
   5 - storage("OOL"."SOLD_TO_ORG_ID"=2057)
       filter("OOL"."SOLD_TO_ORG_ID"=2057)
   6 - storage(TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))>=TO_DATE(' 2017-11-01
              00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))<=TO
              _DATE(' 2017-11-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
       filter(TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))>=TO_DATE(' 2017-11-01
              00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))<=TO
              _DATE(' 2017-11-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
   7 - access("INVENTORY_ITEM_ID"="OOL"."INVENTORY_ITEM_ID" AND
              "ORGANIZATION_ID"="OOL"."SHIP_FROM_ORG_ID")
       filter(TRUNC(INTERNAL_FUNCTION("TRANSACTION_DATE"))=NVL("S"."RESERVATION_DATE_TO","S"."PLANNING
              _DATE"))
   8 - filter("TRX_SOURCE_LINE_ID"="OOL"."LINE_ID" AND "TRANSACTION_TYPE_ID"=33 AND
              "TRANSACTION_SOURCE_TYPE_ID"=2 AND "TRX_SOURCE_LINE_ID" IS NOT NULL AND "TRANSACTION_ACTION_ID"=1 AND
              ABS("TRANSACTION_QUANTITY")=ABS("S"."PRIMARY_QUANTITY"));
              
              
           


再修改之后表的关联顺序发生了变化，使用了另外一个索引 N1，下面测试一下两个两个索引哪个相对性能好些；
   
          --/*+  use_nl(OOL) leading(OOL)index(MMT,MTL_MATERIAL_TRANSACTIONS_N15)*/ 
    
              
              
              Plan hash value: 3610194404
 
---------------------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name                          | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                               |     1 |   126 |   230K  (1)| 00:00:10 |
|   1 |  SORT AGGREGATE               |                               |     1 |   126 |            |          |
|   2 |   NESTED LOOPS                |                               |     1 |   126 |   230K  (1)| 00:00:10 |
|   3 |    NESTED LOOPS               |                               |   579 |   126 |   230K  (1)| 00:00:10 |
|*  4 |     HASH JOIN                 |                               |     1 |    87 |   229K  (1)| 00:00:09 |
|*  5 |      TABLE ACCESS STORAGE FULL| OE_ORDER_LINES_ALL            |   132 |  6732 |   229K  (1)| 00:00:09 |
|*  6 |      TABLE ACCESS STORAGE FULL| CUX_OE_SALEFORECAST_ALL       |     2 |    72 |     9   (0)| 00:00:01 |
|*  7 |     INDEX RANGE SCAN          | MTL_MATERIAL_TRANSACTIONS_N15 |   579 |       |   428   (3)| 00:00:01 |
|*  8 |    TABLE ACCESS BY INDEX ROWID| MTL_MATERIAL_TRANSACTIONS     |     1 |    39 |   611   (2)| 00:00:01 |
---------------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   4 - access("OOL"."ORIG_SYS_DOCUMENT_REF"="S"."PLANNING_NUMBER" AND "OOL"."ORG_ID"="S"."ORG_ID")
   5 - storage("OOL"."SOLD_TO_ORG_ID"=2057)
       filter("OOL"."SOLD_TO_ORG_ID"=2057)
   6 - storage(TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))>=TO_DATE(' 2017-11-01
              00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))<=TO_
              DATE(' 2017-11-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
       filter(TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))>=TO_DATE(' 2017-11-01
              00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND TRUNC(NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_DATE"))<=TO_
              DATE(' 2017-11-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
   7 - access("TRANSACTION_ACTION_ID"=1 AND "TRANSACTION_TYPE_ID"=33 AND
              "TRANSACTION_SOURCE_TYPE_ID"=2)
       filter(TRUNC(INTERNAL_FUNCTION("TRANSACTION_DATE"))=NVL("S"."RESERVATION_DATE_TO","S"."PLANNING_
              DATE"))
   8 - filter("TRX_SOURCE_LINE_ID"="OOL"."LINE_ID" AND "INVENTORY_ITEM_ID"="OOL"."INVENTORY_ITEM_ID"
              AND "ORGANIZATION_ID"="OOL"."SHIP_FROM_ORG_ID" AND "TRX_SOURCE_LINE_ID" IS NOT NULL AND
              ABS("TRANSACTION_QUANTITY")=ABS("S"."PRIMARY_QUANTITY"))

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28380626/viewspace-2148356/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28380626/viewspace-2148356/

cpg7012
关注
SQL JOIN性能优化实战：驱动表选择、索引策略与执行计划深度解读
天下无双
06-14 473
JOIN是关系型数据库最基础也最易误用的操作，其本质是多表间基于关联条件的数据匹配过程。理解INNER JOIN、LEFT JOIN等类型的执行原理，关键在于把握优化器如何根据数据分布选择驱动表、何时下推WHERE条件、以及索引如何影响嵌套循环或哈希连接的效率。技术价值体现在显著提升QPS、避免全表扫描与笛卡尔积爆炸；典型应用场景包括电商订单关联用户信息、金融对账补全维度、SaaS多租户数据隔离等。本文聚焦MySQL执行计划中的key_len、rows与Extra字段诊断，结合ON/WHERE语义差异、覆盖
SQL EXISTS 原理与实战：从存在性判断到执行计划优化
weixin_30372371的博客
07-04 389
EXISTS 是 SQL 中实现存在性判断的核心操作符，其底层对应关系代数中的存在量词 ∃，语义上只关注‘是否存在满足条件的行’，而非返回具体数据。它通过短路执行、半连接（Semi-Join）和索引跳跃扫描等机制，显著规避 JOIN 的中间结果集膨胀、IN 的 NULL 逻辑陷阱以及 LEFT JOIN IS NULL 的内存开销。在千万级数据场景下，合理使用 EXISTS 可将查询耗时从秒级降至毫秒级，尤其适用于高频存在的业务判断，如‘有订单的用户’‘未发货的订单’等。本文聚焦 EXISTS 的工程本质—
Oracle所有执行计划关键词 + 所有hint
m0_47243617的博客
11-14 2758
执行计划里面的关键词大全和hint。
MySQL（Sql优化面试题30道+深度面试考点+索引）
の博客
06-16 4958
调优
Oracle Exadata的TABLE ACCESS STORAGE FULL执行计划
ckawt40802的专栏
09-10 4128
这个TABLE ACCESS STORAGE FULL的执行计划只有在ORACLE EXADATA上才回出现。 Oracle在Exadata上增加了一个硬件Exad...
Claude 3.5 Sonnet 的动态语义稀疏化机制解析
06-29 493
大语言模型推理优化正从参数压缩、量化剪枝等底层改造，转向运行时语义层面的智能精简。动态语义稀疏化（DSS）作为一种新兴的推理层优化范式，不修改模型权重，也不暴露新API，而是基于token级语义熵实时降维表征，在保持输出完整性的同时显著提升token效率与响应确定性。其技术价值在于降低语义冗余、增强信噪比、减少流式碎片，并天然适配RAG、对话系统、自动化报告等对响应质量与成本敏感的生产场景。Claude 3.5 Sonnet 已将DSS默认集成于/v1/messages服务中，成为影响API响应结构、计费逻
Oracle执行计划中集中常见的访问路径
4cott的博客
03-10 660
阅读《SQL优化核心思想》第4章 访问路径(ACCESS PATH) 笔记 访问路径值得是通过哪种扫描方式获取数据。常见的访问路径有 一、TABLE ACCESS FULL 表示全表扫描，一般是多块读，HINT:FULL(表名/别名) Oracle里最小的存储单位是块（Block），物理上连续的块组成了区(extent)，区又组成了段(segment)，因为区里面的数据块在物理上是连...
[20151212优化sql语句要注意关键字DISTINCT
12-14 303
[20151212]优化sql语句要注意关键字DISTINCT.txt --做sql语句优化要特别注意带DISTINCT语句，有一些情况往往是开发写错或者写少了连接条件，或者没有用exists等关键字。 --举最近优化生产...
How to find query block and object alias
西索的领域
05-09 525
Example #1From the file, sqlhc_*_[SQL_ID]_3_execution_plans.html#1 From Execution Plans section, find what you are looking for. (In this example, assume line id 18.)|* 18 | 12 | TABLE ACCESS STORAGE F...
优化器凭什么改写你的 SQL：等价变换、条件调度与主流数据库的取舍
笃行其道的博客
07-25 3831
文章摘要 SQL语句在提交到数据库后，会经过优化器的等价变换，但开发者往往忽视了这一过程。优化器的"等价"仅保证结果集一致，不保证执行顺序、表达式求值次数或错误抛出时机。常见变换包括常量折叠、谓词下推、外连接化简和子查询展开，但各有前提和边界条件（如函数易变性标记）。不同数据库在条件执行顺序、语义处理（如NOT IN转反连接）和优化策略上存在显著差异：PostgreSQL保守且规则驱动，Oracle激进且代价驱动，KES为兼容性牺牲部分优化空间。关键取舍包括变换驱动方式、语义激进程度、人工干预支持和计划稳定
MySQL多表查询实战：从基础关联到性能优化全解析
weixin_30897079的博客
08-14 347
在数据库应用开发中，多表查询是处理复杂业务逻辑的核心技术。其本质是通过连接（JOIN）操作，将分散在多个表中的数据按照关联关系进行整合，从而一次性获取结构化的业务数据。从原理上看，多表查询基于集合运算，通过内连接、外连接等不同方式实现数据的匹配与合并。这项技术的核心价值在于能够直接从数据库层面高效、准确地完成数据关联，避免了在应用层进行多次查询和数据拼接带来的性能损耗与逻辑复杂性。在应用场景上，无论是电商系统中的订单-用户-商品关联，还是内容管理系统中的文章-分类-作者关系，都深度依赖多表查询。特别是在处理
MySQL：SQL优化实际案例解析（持续更新）
秃了也弱了
03-12 907
mysql5版本，对于in并不是很友好，in参数过多就会走全表扫描。而8版本对in做了优化。如果用的是mysql5版本，in的过程比较慢，或许尝试用join操作来代替in可能会有奇效！在where条件中对字段进行函数操作，即使加了索引也会导致索引失效，最终是走全表扫描！如果使用between，全表扫描会变成范围搜索，索引就会正常使用了！同时，看情况用exists等能够替代in的方式。如果是mysql8版本，可以考虑使用。
MySQL（进阶）万字吃透 MySQL SQL 调优：索引原理 + Explain 执行计划 + 全场景 SQL 优化 + 索引失效避坑实战
eternal__day的博客
07-10 461
业务出现数据库卡顿、接口超时排查顺序：SQL & 索引优化 → 表结构优化 → MySQL 参数调优 → 操作系统内核优化 → 硬件扩容先做软件层面低成本优化，最后再考虑硬件升级，避免盲目扩容造成资源浪费。有索引：并发越高性能衰减平缓；无索引：少量并发就会造成 IO、CPU 打满，查询耗时指数级上涨，形成性能雪崩。百万数据下，无索引查询速度比主键索引慢几十倍；高并发场景，缺失索引会引发雪崩式性能衰减，严重影响业务；索引的核心价值：大幅减少磁盘扫描行数，降低 IO 与 CPU 消耗；
SQL执行顺序深度解析：从逻辑书写到物理执行的性能优化指南
最新发布
weixin_34343000的博客
08-15 406
在数据库查询优化中，理解SQL语句的逻辑书写顺序与实际物理执行顺序的差异至关重要。SQL作为一种声明式语言，其逻辑顺序（SELECT-FROM-WHERE-GROUP BY-HAVING-ORDER BY）描述了查询意图，而数据库优化器会根据物理执行顺序（FROM-JOIN-WHERE-GROUP BY-HAVING-SELECT-ORDER BY-LIMIT）进行查询重写和优化，以提升执行效率。这一原理直接影响查询性能，特别是在处理大数据量关联查询和聚合计算时。掌握执行顺序有助于避免全表扫描、临时表滥用等
MySQL之SQL优化篇（六）：其他查询优化
luoyooi的博客
01-20 817
MySQL之SQL优化篇（六）：其他查询优化
SQL优化之优化器
u010740597的专栏
09-28 822
RBO 所有规则为一组内置的规则，这些规则是硬编码在oracle数据库代码中的 具体有规则：oracle在代码里事先给各个类型的执行路径定了一个级别，一共15级，oracle认为等级值低的比等级值高的执行效率要高； 当有两条以上执行路径等级相同时，可以通过调整相关对象在数据字典中的缓存顺序来影响RBO对于执行计划的选择；RBO按照从右到左的顺序来决定谁是驱动表谁是被驱动表 执行计划一旦出现问
(转载)sql优化案例
qq_39863093的博客
07-06 225
sql优化案例 以下转自知乎 链接 分页查询优化 业务要根据时间范围查询交易记录，接口原始的SQL如下： 前提，有id建立的索引 select * from trade_info where status = 0 and create_time >= '2020-10-01 00:00:00' and create_time <= '2020-10-07 23:59:59' order by id desc limit 102120, 20; 表trade_info上有索引idx_statu
吃透 MySQL Join 底层：3 种关联算法的执行原理、适用场景与极致优化方案
果酱 の 博客
04-09 549
本文深入解析MySQL三大JOIN算法（NLJ、BNLJ、Hash Join）的底层原理与优化实践，厘清驱动表选择、索引依赖、执行计划等关键误区，结合实战案例与代码实现，助开发者从根本上解决80%的慢JOIN问题。
SQL数据库优化实战提升查询性能的10个关键技巧
u010682093的博客
10-04 347
数据库的查询优化器会决定表的连接顺序，但有时通过调整JOIN的顺序或使用STRAIGHT_JOIN（在MySQL中）可以提供提示，以获得更优的执行计划。优化的方法是使用“游标分页”或“键集分页”，即记录上一页最后一条记录的ID，然后使用`WHERE id > last_id LIMIT count`来进行查询，这样可以避免扫描大量无关的记录。同时，对于索引碎片化严重的表，定期重建索引可以恢复索引的性能，减少不必要的磁盘I/O。在设计复合索引时，可以考虑将查询中需要返回的列包含在索引中，以实现索引覆盖。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值