理解“为什么我的索引没有被使用?”这是一个相对广泛的话题,其中从简单的无索引到SQL执行计划及数据发布等原因导致,因此不使用索引有很多不同的原因,下面我们将跟踪Oracle官方文档的介绍逐一进行介绍:一 检查表的创建是否索引1.检查您认为应该通过索引访问的表是否确实在其上定义了索引。索引可能被删除或创建失败——例如,在导入表或执行加载之后,可能由于错误(软件或人为)而没有创建索引。下面的查询显示了检查索引的示例:SELECT index_name FROM user_indexes WHERE owner="&Table_Owner" and table_name = "&Table_Name";2.为什么要使用索引?Oracle并不仅仅因为索引存在就必须使用索引。如果查询需要查询表中的每一行(例如,在表连接中),那么为什么要查 询索引中的所有行和表中的所有行呢?在这种情况下,忽略索引可以获得更好的性能。优化器根据各种访问方法(包括 索引)对所有查询的适用性的统计信息做出决策,并选择最优方法二 从索引自身找原因1.在查询(谓词列表)的where子句中,索引的索引列是否为单个表(非连接)where条件中谓词提供? 如果没有,那么需要在查询中使用索引至少需要是谓词列表中索引的第一列(对于跳过扫描请在下面的学习中进行了解)。示例:您在单列EMP.EMPNO上定义了索引EMPNO_I1,并定义了连接索引EMPNO_DEPT_I2对列EMP.EMPNO和EMP.DEPT (EMP.EMPNO是第一列)。为了让优化器考虑任何一个索引,我们必须在谓词列表(WHERE子句)中使用列EMP.EMPNO:SELECT ename, sal, deptno FROM emp WHERE empno<100;2.例外情况处理:2.1.CBO优化器可以使用索引快速全扫描(INDEX_FFS),只要索引包含查询所需的所有列,并且索引键中至少有一个列具有NOT NULL约束。执行INDEX_FFS并不需要索引的前导列。注意,使用INDEX_FFS并不一定返回已排序的行。排序取决于读取索引块的顺序,并且只有在使用'order by'子句时才能保证以排序的顺序返回行。如下的:a. (1).在Oracle中的表数据没有默认的排序。所以如果没有指定排序,那么数据将按照在检索数据的对象中找到的顺序返回。预先排序的数据源(如索引)将返回排序的数据,但未排序的数据将返回未排序的数据(如全表扫描)。如果SQL发现查询的访问路径发生了变化,那么数据返回的顺序可能与以前不同。Oracle为了保证行顺序的ONLY方法是在语句中提供order by子句。 (2).在一些查询中,有2个参数可能会影响顺序,它们是: _newsort_enabled -该参数允许使用新的排序算法。 _gby_hash_aggregation_enabled—该参数允许group by子句使用散列聚合而不是排序。由于散列聚合不能保证返回数据的顺序,因此这可能会改变数据的顺序 上述两个参数的设置对排序的任何影响都是true或者false,设置它们将导致使用不同的排序代码。这个排序代码的目的纯粹是与性能相关的。顺序上的任何变化都是巧合。 (3).如下的情况将优先使用指数FFS而不是FTS a.索引必须包含查询中引用的所有列。 b.索引FFS仅适用于基于成本的优化器(CBO)(索引提示强制CBO)。 c.索引FFS可以用/*+ INDEX_FFS() */来暗示。如下实例:创建索引
无谓词扫描:
谓词中包含索引列:
FFS不满足要求,执行计划采用了SSI方式
2.2.CBO优化器可以使用索引跳过扫描(INDEX_SS)。执行INDEX_SS不需要索引的前导列: 索引跳跃扫描改进了对非前缀列的索引扫描,因为扫描索引块通常比扫描表数据块更快。非前缀索引是指不包含作为第一列的键列的索引。 如果将前缀索引想象成类似于分区表,这个概念就更容易理解了。在分区对象中,分区键(在本例中为前导列)定义了存储在哪个分区中的数据。在索引的情况下,每个键(前缀列)下的每一行都将按照该键排序。因此,在前缀索引的跳跃扫描中,前缀值被跳过,非前缀列作为逻辑子索引访问。后继列在前缀列中排序,因此可以忽略前缀进行“正常”的索引访问。 在这种情况下,复合索引逻辑上被分割成更小的子索引。逻辑子索引的数量取决于初始列的基数。因此,即使在where子句中没有使用前导列,也可以使用索引。如下是案例:
2.3.CBO优化器可以选择使用索引来实现排序。为了实现这一点,索引列需要在order by子句中。
如果业务要求优化器考虑使用索引来驱动ORDER BY语句而不是排序,则索引列必须是NOT NULL,否则不考虑。
这是因为优化器不能保证索引满足查询,因为NULL值不存储在单列索引中,只有当其中一列不是NULL时才存储在串联索引中。如果在NULL值构成部分结果集的情况下使用索引,则这意味着使用该索引的单个操作无法检索所有数据。因此,将使用另一种访问方法。
注意,索引提示可以被覆盖,因为不可能使用索引来满足查询。
ORDER BY必须匹配索引中列的顺序。如果ORDER BY指定的列位于不同的索引中,则不使用索引。
本次相关文档见:Document 344135.1 Ordering of Result DataDocument 70135.1 Index Fast Full Scan Usage To Avoid Full Table ScansDocument 212391.1 Index Skip Scan FeatureDocument 67409.1 When will an ORDER BY use an Index to Avoid Sorting?Document 10577.1 Driving ORDER BY using an Index
Oracle SQL语句为什么不走索引-场景一
来源:这里教程网
时间:2026-03-03 19:54:39
作者:
编辑推荐:
下一篇:
相关推荐
-
雷神推出 MIX PRO II 迷你主机:基于 Ultra 200H,玻璃上盖 + ARGB 灯效
2 月 9 日消息,雷神 (THUNDEROBOT) 现已宣布推出基于英
-
制造商 Musnap 推出彩色墨水屏电纸书 Ocean C:支持手写笔、第三方安卓应用
2 月 10 日消息,制造商 Musnap 现已在海外推出一款 Oce
热文推荐
- Oracle SQL语句为什么不走索引-场景一
Oracle SQL语句为什么不走索引-场景一
26-03-03 - 看这里!这是再经单不过的三个Oracle性能故障案例了
看这里!这是再经单不过的三个Oracle性能故障案例了
26-03-03 - 某业务系统 出现大量log file sync等待事件分析
某业务系统 出现大量log file sync等待事件分析
26-03-03 - [译] 甲骨文发布Oracle数据库对MongoDB的接口
[译] 甲骨文发布Oracle数据库对MongoDB的接口
26-03-03 - 使用merge into优化update关联更新
使用merge into优化update关联更新
26-03-03 - 数据库CPU高异常分析
数据库CPU高异常分析
26-03-03 - cursor: pin S wait on X等待事件故障分析
cursor: pin S wait on X等待事件故障分析
26-03-03 - 在线办公:巨头通往新质生产力的一把利剑
在线办公:巨头通往新质生产力的一把利剑
26-03-03 - 数据库管理-第175期 深入探索CPU性能(20240424)
数据库管理-第175期 深入探索CPU性能(20240424)
26-03-03 - Oracle 12CR2 RAC部署翻车,bug避坑经历
Oracle 12CR2 RAC部署翻车,bug避坑经历
26-03-03
