组合索引，前置列与where条件关系

最新推荐文章于 2020-12-01 19:10:16 发布
最新推荐文章于 2020-12-01 19:10:16 发布
阅读量2k 收藏
点赞数
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/launch_225/article/details/25509089
版权

链接地址：http://blog.csdn.net/launch_225/article/details/25509089


SQL> create table t1 as select * from dba_objects;

Table created.

SQL> create index idx_z on t1(object_id,owner);

Index created.

SQL> create index idx_f on t1(owner,object_id);

Index created.

SELECT /*+ INDEX(T1,IDX_Z) */status from t1 where owner='PUBLIC' AND OBJECT_ID=26122;

Execution Plan
----------------------------------------------------------
Plan hash value: 2939511897

-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       |    17 |   595 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1    |    17 |   595 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IDX_Z |    17 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OBJECT_ID"=26122 AND "OWNER"='PUBLIC')

Note
-----
   - dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          4  consistent gets                                 --4个逻辑读
          0  physical reads
          0  redo size
        527  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
          
SELECT /*+ INDEX(T1,IDX_f) */status from t1 where owner='PUBLIC' AND OBJECT_ID=26122

Execution Plan
----------------------------------------------------------
Plan hash value: 2808883862

-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       |    17 |   595 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1    |    17 |   595 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IDX_F |    17 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OWNER"='PUBLIC' AND "OBJECT_ID"=26122)

Note
-----
   - dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets       
          4  consistent gets                               --与上面的相等，4；
          0  physical reads
          0  redo size
        527  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
          
SELECT /*+ INDEX(T1,IDX_f) */ STATUS FROM T1 WHERE OBJECT_ID>20000 AND OWNER='PUBLIC';

Execution Plan
----------------------------------------------------------
Plan hash value: 2808883862

-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       | 14657 |   500K|   489   (1)| 00:00:06 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1    | 14657 |   500K|   489   (1)| 00:00:06 |
|*  2 |   INDEX RANGE SCAN          | IDX_F | 14657 |       |    52   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OWNER"='PUBLIC' AND "OBJECT_ID">20000 AND "OBJECT_ID" IS NOT
              NULL)

Note
-----
   - dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       3535  consistent gets                               ---此索引owner前置，逻辑读为3535
          0  physical reads
          0  redo size
     372119  bytes sent via SQL*Net to client
      16363  bytes received via SQL*Net from client
       1442  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      21605  rows processed
      
select /*+ index(t1,idx_z) */ STATUS FROM T1 WHERE OBJECT_ID>20000 AND OWNER='PUBLIC'

Execution Plan
----------------------------------------------------------
Plan hash value: 2939511897

-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       | 14657 |   500K|   148   (0)| 00:00:02 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1    | 14657 |   500K|   148   (0)| 00:00:02 |
|*  2 |   INDEX RANGE SCAN          | IDX_Z |   167 |       |   145   (0)| 00:00:02 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OBJECT_ID">20000 AND "OWNER"='PUBLIC' AND "OBJECT_ID" IS NOT
              NULL)
       filter("OWNER"='PUBLIC')

Note
-----
   - dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       3637  consistent gets                             ---object_id前置的逻辑读3637比上面的值3535更多
          0  physical reads
          0  redo size
     372119  bytes sent via SQL*Net to client
      16363  bytes received via SQL*Net from client
       1442  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      21605  rows processed

--可以根据上面得出：等值扫描时，所消耗的逻辑读是相等的；
--范围扫描时，=的列前置的索引所消耗的逻辑读更少；
                          
将条件=和>的位置对调下；可以看到得到结论以上面相符；                          
select /*+ index(t1,idx_z) */ STATUS FROM T1 WHERE OBJECT_ID=20000 AND OWNER>'PUBLIC'       

Execution Plan
----------------------------------------------------------
Plan hash value: 2939511897

-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       |    35 |  1225 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1    |    35 |  1225 |     3   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IDX_Z |     3 |       |     2   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OBJECT_ID"=20000 AND "OWNER">'PUBLIC' AND "OWNER" IS NOT NULL)

Note
-----
   - dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          4  consistent gets
          0  physical reads
          0  redo size
        527  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
          
select /*+ index(t1,idx_F) */ STATUS FROM T1 WHERE OBJECT_ID=20000 AND OWNER>'PUBLIC'                     

Execution Plan
----------------------------------------------------------
Plan hash value: 2808883862

-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       |    35 |  1225 |   135   (0)| 00:00:02 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1    |    35 |  1225 |   135   (0)| 00:00:02 |
|*  2 |   INDEX RANGE SCAN          | IDX_F |   151 |       |   130   (0)| 00:00:02 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OWNER">'PUBLIC' AND "OBJECT_ID"=20000 AND "OWNER" IS NOT NULL)
       filter("OBJECT_ID"=20000)

Note
-----
   - dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        111  consistent gets
          0  physical reads
          0  redo size
        527  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed


launch_225
关注
浅析C++中前置声明的应用与陷阱
09-05
在C++编程中，前置声明（Forward Declaration）是一种在不完全了解类的详细定义的情况下，提前告知编译器某个标识符代表的是一个类的技术。它主要用于解决头文件循环依赖的问题，减少编译错误，并优化编译效率。在...
mysql 索引顺序_MySQL中where条件的顺序对索引的影响
weixin_42370927的博客
01-18 8700
看到有资料说，where条件的顺序和索引的顺序不一致，会影响查询的效率，根据的逻辑是：where条件的运行是从右到左的，将选择性强的条件放到最右边，可以先过滤掉大部分的数据(而选择性不强的条件过滤后的结果集仍然很大)，在根据其它条件过滤时，需要比较的数据量就少，提高查询的效率。当我看到这个逻辑时，自我认为不是太合理，数据库引擎在执行SQL语句时，都是要经过查询优化器的，查询优化器会将SQL进行优化...
where条件顺序与建索引顺序
weixin_33826268的博客
07-26 3616
查询时，如果数据量很大，where 后面的条件与建索引的顺序相同，也没有什么多少差别，聚集索引稍微快点; 但where 后面的条件与建索引顺序不同，速度会慢下来，到底慢多少，不同的机器会不一样，没有绝对的说法。MSSQL引擎首先对条件进行优化，优化以后再查询。1，还是那句，先看执行计划。2.2008的话，对where的顺序它会自己优化，测试过，顺序对执行计划没有影响，不过2005好像有。所以从规范...
组合索引中where条件第一字段的筛选_如何通过索引让 SQL 查询效率最大化
weixin_39815410的博客
11-30 451
如何通过索引让 SQL 查询效率最大化什么时候创建索引？ 如果出现如下情况，可以创建索引。字段的数值唯一性的限制 索引可以起到约束的作用，比如唯一索引，主键索引，都可以起到唯一约束的作用。当字段的数值唯一时，可以考虑建立唯一索引或者主键索引。频繁作为 Where 查询条件的字段 在表数据量比较大的时候，某个字段在 SQL 查询的 where条件时，就学英语给这个字段创建索引。SELECT comm...
前置式自吸混流泵的开发与研制.rar
05-06
前置式自吸混流泵结合了离心泵的高速旋转特性与轴流泵的大流量优势。在启动时，泵内的叶片通过快速旋转产生负压，吸入流体，形成自吸效果。同时，泵内的流体混合流动，既增加了流体的能量，也扩大了流量范围，使得该...
加速度计与前置放大器
08-16
前置放大器通常是指与加速度计配套使用的信号放大设备，它可以将加速度计输出的微弱信号放大到一个适合后续信号处理和分析的水平。前置放大器可以集成于加速度计内或者作为一个独立的设备使用。在实际应用中，前置...
组合索引和单值索引使用时的注意点
记忆碎片
10-24 3610
题目:给定一张mytable表，其中有4个字段(name,sex,birth,birthaddr)，分别建立组合索引(name,sex,birth,birthaddr)where条件后边使用where name=xx and sex=xx或者name=xx and sex=xx，或者name=xx or sex=xx 或者sex=xx or name=xx，哪种会使得索引失效?假如是单值索引又是什
组合索引中where条件第一字段的筛选_MySql学习笔记（二） 索引的设计和使用
weixin_39639622的博客
12-01 465
作为开发人员，数据库的索引是我们再熟悉不过的了。那么实话真的会了吗，在项目开发中随便定义一个int、varchar后边跟个primary key或者加个index就好了么？考虑到这些咋还真的需要看看专业的人都是怎么做的。在mysql中索引是提升性能的常用工具，一般来说我们就是通过让where的条件字段变成索引，或者如果where条件比较多的话一般将前边的条件做成索引。这样就可以通过索引快...
SQL优化之组合索引中字段的顺序
franage的博客
04-03 3234
SQL优化之组合索引中字段的顺序 记一次SQL优化：组合索引中字段顺序有讲究，越离散的字段越靠前，哪个列可以降低索引扫描成本放在前面。 Refer：https://blog.csdn.net/pan_tian/article/details/8279501 或者 https://bbs.csdn.net/topics/390849952 ...
mysql组合索引与字段顺序
dxyzhbb的博客
08-27 7369
很多时候，我们在mysql中创建了索引，但是某些查询还是很慢，根本就没有使用到索引！一般来说，可能是某些字段没有创建索引，或者是组合索引中字段的顺序与查询语句中字段的顺序不符。 看下面的例子： 假设有一张订单表(orders)，包含order_id和product_id二个字段。 一共有31条数据。符合下面语句的数据有5条。执行下面的sql语句： select product_id from or...
有些 where 条件会导致索引无效
weixin_34250709的博客
05-12 1509
在查询中，WHERE 条件也是一个比较重要的因素，尽量少并且是合理的 where条件是徆重要的，尽量在多个条件的时候，把会提取尽量少数据量的条件放在前面，减少后一个 where 条件的查询时间。有些 where 条件会导致索引无效： 1.where 子句的查询条件里有！=，MySQL 将无法使用索引。  2.where 子句使用了 Mysql 函数的时候，索引将无效，比如：select * ...
数据库触发联合索引的几个条件
海涛的博客
06-30 9160
联合索引是建立在某个表（Table）上的，由多个列（Column）构成的索引。 触发联合索引是有条件的： 示例如下。首先创建表： CREATE TABLE E (e1 INT, e2 VARCHAR(9), e3 INT, PRIMARY KEY(e1, e3)); 这样就建立了一个联合索引：e1,e3 1、使用联合索引的全部索引键，可触发索引的使用。 例如：SELECT
sql order by与索引之间的关系（where条件出现字段才有效）
热门推荐
写博客只为学习
04-11 2万+
ORDER BY 通常会有两种实现方法，一个是利用有序索引自动实现，也就是说利用有序索引的有序性就不再另做排序操作了。另一个是把结果选好之后再排序。 用有序索引这种，当然是最快的，不过有一些限制条件，来看下面的测试。 测试数据：student表有两个字段id ,sid ,id是主键。一共有20W条记录，id从1到200000,sid也是从1到200000的数据。 第一种情况 : or
SQL Server学习之复合索引
chiefsailor的专栏
06-19 2537
概要什么是单一索引,什么又是复合索引呢? 何时新建复合索引，复合索引又需要注意些什么呢？本篇文章主要是对网上一些讨论的总结。一.概念单一索引是指索引列为一列的情况,即新建索引的语句只实施在一列上。用户可以在多个列上建立索引，这种索引叫做复合索引(组合索引)。复合索引的创建方法与创建单一索引的方法完全一样。但复合索引在数据库操作期间所需的开销更小，可以代替多个单一索引。当表的行数远远大于索引键的数目
Oracle索引原理：跳跃式扫描与组合索引优化
此外，还提到了组合索引的设计策略和Oracle 9i以后引入的跳跃式索引扫描功能，这使得在where条件中未出现前置列的组合索引也能被有效利用。" 在Oracle数据库中，索引是一种关键的性能优化工具，尤其在处理大型表时...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值