sql - Oracle top-n 查询排序性能-6ren

sql - Oracle top-n 查询排序性能

转载作者：行者123 更新时间：2023-12-02 00:40:56

我是 sql 优化的新手，我试图理解为什么 IN 子句中包含超过 1 个项目会导致巨大的性能损失，以及如果可能的话如何防止它。以下或多或少是我正在处理的内容。第二个查询是我当前所拥有的，我希望提高性能。在现实生活中，TABLE_1 有数百万行，计划的排序部分的 CPU 成本为 21M。

SELECT 
    TOPNWRAPPER.*, 
    TABLE_2.X, 
    TABLE_2.Y 
FROM 
    TABLE_2, 
    ( 
        SELECT 
            * 
        FROM 
            ( 
                SELECT 
                    /*+ index (TABLE_1 TABLE_1_B_E_F_ID) */ 
                    TABLE_1.ID, 
                    TABLE_1.C, 
                    TABLE_1.B, 
                    TABLE_1.E, 
                    TABLE_1.F
                FROM 
                    TABLE_1 
                WHERE 
                    ( TABLE_1.F IN ( ‘STATE1’ ) ) AND 
                    ( TABLE_1.B= 'SOMETEXT' ) AND 
                    ( TABLE_1.C=1 ) AND 
                    ( TABLE_1.E= 'IN' ) AND 
                    ( TABLE_1.D IS NULL ) 
                ORDER BY 
                    TABLE_1.ID 
            ) 
        WHERE 
            ( ROWNUM <= 150 ) 
    ) TOPNWRAPPER 
WHERE 
    ( TOPNWRAPPER.ID = TABLE_2.T1_ID_FK ) 
ORDER BY 
    TOPNWRAPPER.ID ASC

统计数据:

|--------------------------------------------------------------------------------------------------------------------------|
|| Id  | Operation                        | Name                        | Starts | E-Rows | A-Rows |   A-Time   | Buffers ||
|--------------------------------------------------------------------------------------------------------------------------|
||   0 ||SELECT STATEMENT                 |                             |      1 |        |    120 |00:00:00.01 |     965 ||
||   1 |||NESTED LOOPS                    |                             |      1 |        |    120 |00:00:00.01 |     965 ||
||   2 ||||NESTED LOOPS                   |                             |      1 |      1 |    120 |00:00:00.01 |     845 ||
||   3 |||||VIEW                          |                             |      1 |      1 |    120 |00:00:00.01 |     245 ||
||*  4 ||||||COUNT STOPKEY                |                             |      1 |        |    120 |00:00:00.01 |     245 ||
||   5 |||||||VIEW                        |                             |      1 |      1 |    120 |00:00:00.01 |     245 ||
||*  6 ||||||||TABLE ACCESS BY INDEX ROWID| TABLE_1                     |      1 |      1 |    120 |00:00:00.01 |     245 ||
||*  7 |||||||||INDEX RANGE SCAN          | TABLE_1_B_E_F_ID            |      1 |     25 |    120 |00:00:00.01 |     125 ||
||*  8 |||||INDEX RANGE SCAN              | TABLE_2_T1_ID_FK            |    120 |      1 |    120 |00:00:00.01 |     600 ||
||   9 ||||TABLE ACCESS BY INDEX ROWID    | TABLE_2                     |    120 |      1 |    120 |00:00:00.01 |     120 ||
|--------------------------------------------------------------------------------------------------------------------------|
|                                                                                                                          |
|Predicate Information (identified by operation id):                                                                       |
|---------------------------------------------------                                                                       |
|                                                                                                                          |
|   4 - filter(ROWNUM<=150)                                                                                                |
|   6 - filter((“TABLE_1”.”C”=1 AND “TABLE_1”.”D” IS NULL))                                                                |
|   7 - access(“TABLE_1”.”B”='SOMETEXT' AND                                                                                |
|              “TABLE_1”.”E”=‘IN' AND “TABLE_1”.”F”=’STATE1’)                                                              |
|   8 - access(“TOPNWRAPPER”.”ID”=“TABLE_2”.”T1_ID_FK”)                                                                         |
+--------------------------------------------------------------------------------------------------------------------------+

当我更新查询以在 IN 子句中包含“STATE2”时，计划中会添加一个额外的排序步骤。

SELECT 
    TOPNWRAPPER.*, 
    TABLE_2.X, 
    TABLE_2.Y 
FROM 
    TABLE_2, 
    ( 
        SELECT 
            * 
        FROM 
            ( 
                SELECT 
                    /*+ index (TABLE_1 TABLE_1_B_E_F_ID) */ 
                    TABLE_1.ID, 
                    TABLE_1.C, 
                    TABLE_1.B, 
                    TABLE_1.E, 
                    TABLE_1.F
                FROM 
                    TABLE_1 
                WHERE 
                    ( TABLE_1.F IN ( 'STATE1', 'STATE2' ) ) AND 
                    ( TABLE_1.B= 'SOMETEXT' ) AND 
                    ( TABLE_1.C=1 ) AND 
                    ( TABLE_1.E= 'IN' ) AND 
                    ( TABLE_1.D IS NULL ) 
                ORDER BY 
                    TABLE_1.ID 
            ) 
        WHERE 
            ( ROWNUM <= 150 ) 
    ) TOPNWRAPPER 
WHERE 
    ( TOPNWRAPPER.ID = TABLE_2.T1_ID_FK ) 
ORDER BY 
    TOPNWRAPPER.ID ASC

统计数据:

|-------------------------------------------------------------------------------------------------------------------------------------------------------|
|| Id  | Operation                          | Name                        | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem ||
|-------------------------------------------------------------------------------------------------------------------------------------------------------|
||   0 ||SELECT STATEMENT                   |                             |      1 |        |    150 |00:00:00.01 |    1076 |       |       |          ||
||   1 |||NESTED LOOPS                      |                             |      1 |        |    150 |00:00:00.01 |    1076 |       |       |          ||
||   2 ||||NESTED LOOPS                     |                             |      1 |      1 |    150 |00:00:00.01 |     926 |       |       |          ||
||   3 |||||VIEW                            |                             |      1 |      1 |    150 |00:00:00.01 |     176 |       |       |          ||
||*  4 ||||||COUNT STOPKEY                  |                             |      1 |        |    150 |00:00:00.01 |     176 |       |       |          ||
||   5 |||||||VIEW                          |                             |      1 |      1 |    150 |00:00:00.01 |     176 |       |       |          ||
||*  6 ||||||||SORT ORDER BY STOPKEY        |                             |      1 |      1 |    150 |00:00:00.01 |     176 | 15360 | 15360 |14336  (0)||
||   7 |||||||||INLIST ITERATOR             |                             |      1 |        |    165 |00:00:00.01 |     176 |       |       |          ||
||*  8 ||||||||||TABLE ACCESS BY INDEX ROWID| TABLE_1                     |      2 |      1 |    165 |00:00:00.01 |     176 |       |       |          ||
||*  9 |||||||||||INDEX RANGE SCAN          | TABLE_1_B_E_F_ID            |      2 |     50 |    165 |00:00:00.01 |      11 |       |       |          ||
||* 10 |||||INDEX RANGE SCAN                | TABLE_2_T1_ID_FK            |    150 |      1 |    150 |00:00:00.01 |     750 |       |       |          ||
||  11 ||||TABLE ACCESS BY INDEX ROWID      | TABLE_2                     |    150 |      1 |    150 |00:00:00.01 |     150 |       |       |          ||
|-------------------------------------------------------------------------------------------------------------------------------------------------------|
|                                                                                                                                                       |
|Predicate Information (identified by operation id):                                                                                                    |
|---------------------------------------------------                                                                                                    |
|                                                                                                                                                       |
|   4 - filter(ROWNUM<=150)                                                                                                                             |
|   6 - filter(ROWNUM<=150)                                                                                                                             |
|   8 - filter((“TABLE_1”.”C”=1 AND “TABLE_1”.”D” IS NULL))                                         |
|   9 - access(“TABLE_1”.”B”='SOMETEXT' AND                                                                                |
|              “TABLE_1”.”E”='IN' AND ((“TABLE_1”.”F”='STATE1') OR (“TABLE_1”.”F”='STATE2'))                                              |
|  10 - access(“TOPNWRAPPER”.”ID”=“TABLE_2”.”T1_ID_FK”)                                                              |
|                                                                                                                                                       |
+-------------------------------------------------------------------------------------------------------------------------------------------------------+

这几天我一直在四处寻找。我尝试的一个建议是使用提示 /*+ USE_CONCAT (OR_PREDICATES(1)) */ ，这有助于将内存使用量减少一半，但它并没有完全消除问题。

编辑:环顾四周( http://use-the-index-luke.com/sql/sorting-grouping/indexed-order-by#tip-ixord-full )并认为这可能是由于 order by 造成的。如果我将 order by 语句更改为: TABLE_1.F,TABLE_1.ID 和 TOPNWRAPPER.F,TOPNWRAPPER.ID ASC 那么排序操作就会消失，不幸的是我需要基于 ID 的前 n 行。或者，我尝试在 (ID F) 上创建一个新索引来进行测试，它也删除了排序操作，但 ID 每行都是唯一的，这使得表访问操作的效率降低。

编辑2:

OPERATION      |OPTION           |CPU COST
--------------------------------------------
SORT           |ORDER BY STOPKEY |21042774
|NESTED LOOPS  |OUTER            |56052
||TABLE ACCESS |BY INDEX ROWID   |38980
|||INDEX       |RANGE SCAN       |30086

最佳答案

性能差异可能并不重要。执行计划的差异是因为如果前导列使用相等条件，则多列索引访问只会隐式排序。

性能差异

不要太担心执行计划的成本。尽管它被称为“基于成本的优化器”，但成本是一个奇怪的数字，世界上只有少数人完全理解。

比较解释计划成本很复杂的一个原因是总成本有时小于子操作成本之一。正如我在my answer here中解释的那样，这可以通过 COUNT STOPKEY 操作发生。这是 Oracle 的说法，“这个子操作将花费如此巨大的费用，但是 COUNT STOPKEY 可能会在它达到那么高之前将其切断”。通常最好比较计划的最高成本，但即使是这个数字有时也可能会产生误导，正如该答案中的其他示例所示。

这意味着通常运行时间是唯一重要的事情。如果两个查询的 A-Time(实际时间)仅为 0.1 秒，那么您的工作可能已经完成。

执行计划差异

执行计划的差异是由多列索引的存储和访问方式造成的。有时扫描索引时，结果会自动存储，有时则不会。这就是为什么一个计划具有 COUNT STOPKEY 而另一个计划具有更昂贵的 SORT ORDER BY STOPKEY。

为了演示此计划差异，请创建一个仅包含 2 列和 4 行的简单表和索引:

create table test1 as 
select 1 a, 10 b from dual union all
select 1 a, 30 b from dual union all
select 2 a, 20 b from dual union all
select 2 a, 40 b from dual;

create index test1_idx on test1(a, b);

begin
    dbms_stats.gather_table_stats(user, 'TEST1');
end;
/

下面是索引存储方式的简化思路。数据首先按前导列排序存储，然后按尾随列排序。

               +----+
        +------+Root+-------+
        |      +----+       |
        |                   |
      +-v-+               +-v-+
   +--+A=1+--+         +--+A=2+--+
   |  +---+  |         |  +---+  |
   |         |         |         |
 +-v--+   +--v-+     +-v--+   +--v-+
 |B=10|   |B=30|     |B=20|   |B=40|
 +----+   +----+     +----+   +----+

如果查询仅访问前导列 A 中的一个值，那么它可以按顺序读取列 B 中的值，而无需任何额外的工作。 Oracle 会先读取 A block 之一，然后按顺序读取 B block ，甚至无需尝试。

请注意此查询如何具有 ORDER BY，但执行计划中没有 SORT。

explain plan for select * from test1 where a = 1 and b > 0 order by b;
select * from table(dbms_xplan.display(format => 'basic'));

Plan hash value: 598212486

--------------------------------------
| Id  | Operation        | Name      |
--------------------------------------
|   0 | SELECT STATEMENT |           |
|   1 |  INDEX RANGE SCAN| TEST1_IDX |
--------------------------------------

但是，如果查询访问前导列 A 中的多个值，则不一定会按顺序检索 B 中的结果。 Oracle 可以按顺序读取 A block ，但 B block 顺序仅适用于一个 A 值。

现在，执行计划中会显示一个额外的 SORT ORDER BY 操作。

explain plan for select * from test1 where a in (1,2) and b > 0 order by b;
select * from table(dbms_xplan.display(format => 'basic'));

Plan hash value: 704117715

----------------------------------------
| Id  | Operation          | Name      |
----------------------------------------
|   0 | SELECT STATEMENT   |           |
|   1 |  SORT ORDER BY     |           |
|   2 |   INLIST ITERATOR  |           |
|   3 |    INDEX RANGE SCAN| TEST1_IDX |
----------------------------------------

这就是为什么将 (value1, value2) 中的 column1 = value1 更改为 column1 可能会添加额外的 SORT 操作。

关于sql - Oracle top-n 查询排序性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39135808/

文章推荐： java - Rest url 中查询参数的日期时间格式

文章推荐：允许对成员进行数字操作的 scala 类型签名

文章推荐： c++ - 三元运算符的意外结果

javascript - Ember.js，性能，性能 :
性能:数据存储写入与请求日志写入
我们希望通过我们的应用收集使用情况统计信息。因此，我们希望在服务器端的某个地方跟踪用户操作。就性能而言，哪个选项更合适: 在 App Engine 请求日志中跟踪用户操作。即为每个用户操作写入一个日
LINQ 性能
在针对对象集合的 LINQ 查询的幕后究竟发生了什么？它只是语法糖还是发生了其他事情使其更有效的查询？最佳答案您是指查询表达式，还是查询在幕后的作用？查询表达式首先扩展为“普通”C#。例如: v
WPF 性能
我正在构建一个简单的照片库应用程序，它在列表框中显示图像。 xaml 是:
java缓存系统和静态HashMap存储-性能
对于基于 Web 的企业应用程序，使用“静态 Hashmap 存储对象” 和 apache java 缓存系统有何优缺点？哪一个最有利于性能并减少堆内存问题例如: Map store=Applica
jquery存储变量类(性能)
我想知道在性能方面存储类变量的最佳方式是什么。我的意思是，由于 Children() 函数，存储一个 div id 比查找所有其他类名更好。还是把类名写在变量里比较好？例如这样: var $inne
Cassandra 性能
我已经阅读了所有这些关于 cassandra 有多快的文章，例如单行读取可能需要大约 5 毫秒。到目前为止，我不太关心我的网站速度，但是随着网站变得越来越大，一些页面开始需要相当多的查询，例如一个页
MySQL 性能
最近，我在缓存到内存缓存之前的查询一直需要很长时间才能处理!在这个例子中，它花费了 10 秒。在这种情况下，我要做的就是获得 10 个最近的点击。我感觉它加载了所有 125,592 行然后只返回 1
基本操作的C#性能
我找了几篇文章(包括SA中的一些问题)，试图找到基本操作的成本。但是，我尝试制作自己的小程序，以便自己进行测试。在尝试测试加法和减法时，我遇到了一些问题，我用简单的代码向您展示了这一点
Java远程调试——性能
这个问题在这里已经有了答案: Will Java app slow down by presence of -Xdebug or only when stepping through code? (
Javascript with() 性能
我记得很久以前读过 with() 对 JavaScript 有一些严重的性能影响，因为它可能对范围堆栈进行非确定性更改。我很难找到最近对此的讨论。这仍然是真的吗？最佳答案与其说 with 对性能有
MySQL 性能
我们有一个数据仓库，其中包含非规范化表，行数从 50 万行到 6 多万行不等。我正在开发一个报告解决方案，因此出于性能原因我们正在使用数据库分页。我们的报告有搜索条件，并且我们已经创建了必要的索引，但
mysql - 性能
我有一条有效的 SQL 语句，但需要很长时间才能处理我有一个 a_log 表和一个 people 表。我需要在 people 表中找到给定人员的每个 ID 的最后一个事件和关联的用户。 SELECT
JavaScript 性能
很难说出这里问的是什么。这个问题是含糊的、模糊的、不完整的、过于宽泛的或修辞性的，无法以目前的形式得到合理的回答。如需帮助澄清此问题以便重新打开它，visit the help center 。已关
CSS 性能
通常当我建立一个站点时，我将所有的 CSS 放在一个文件中，并且一次性定义与一组元素相关的所有属性。像这样: #myElement { color: #fff; background-
CSS 性能
两者之间是否存在任何性能差异: p { margin:0px; padding:0px; } 并省略最后的分号: p { margin:0px; padding:0px } 提前致谢!
PHP高精数学-性能
我的应用程序 (PHP) 需要执行大量高精度数学运算(甚至可能出现一共100个数字) 通过这个论坛的最后几篇帖子，我发现我必须使用任何高精度库，如 BC Math 或 GMP，因为 float 类型不
Javamail 性能
我一直在使用 javamail 从 IMAP 服务器(目前是 GMail)检索邮件。 Javamail 非常快速地从服务器检索特定文件夹中的消息列表(仅 id)，但是当我实际获取消息(仅包含甚至不包含
ruby 性能
我非常渴望开发我的第一个 Ruby 应用程序，因为我的公司终于在内部批准了它的使用。在我读到的关于 Ruby v1.8 之前的所有内容中，从来没有任何关于性能的正面评价，但我没有发现关于 1.9 版
redis结构、性能
我是 Redis 的新手，我有一个包含数百万个成员(member) ID、电子邮件和用户名的数据集，并且正在考虑将它们存储在例如列表结构中。我认为 list 和 sorted set 可能最适合我的情

行者123

个人简介

我是一名优秀的程序员,十分优秀！

作者热门文章

滴滴打车优惠券免费领取

全站热门文章

首页

博学

6Ren·AI

商城

sql - Oracle top-n 查询排序性能