索引总结

如果是等值查询,那么哈希索引明显有绝对优势,因为只需要经过一次算法即可找到相应的键值;当然了,这个前提是,键值都是唯一的。如果键值不是唯一的,就需要先找到该键所在位置,然后再根据链表往后扫描,直到找到相应的数据;

从示意图中也能看到,如果是范围查询检索,这时候哈希索引就毫无用武之地了,因为原先是有序的键值,经过哈希算法后,有可能变成不连续的了,就没办法再利用索引完成范围查询检索;

同理,哈希索引也没办法利用索引完成排序,以及like ‘xxx%’ 这样的部分模糊查询(这种部分模糊查询,其实本质上也是范围查询);

哈希索引也不支持多列联合索引的最左匹配规则;

B+树索引的关键字检索效率比较平均,不像B树那样波动幅度大,在有大量重复键值情况下,哈希索引的效率也是极低的,因为存在所谓的哈希碰撞问题。

【聚簇索引】
平时习惯逛图书馆的童鞋可能比较清楚,如果你要去图书馆借一本书,最开始是去电脑里面查书名然后根据书名来定位藏书在那个区,哪个书柜,哪一行,第多少本。。。清晰明确,一目了然,因为藏书的结构与图书室的位置,书架的顺序,书本的摆放顺序与书籍的编号都是从大到小一致的顺序摆放的,所以很容易找到。比如,你的目标藏书在C区2柜3排5仓,那么你走到B区你就很快知道前面就快到了C区了,你直接奔着2柜区就能找到了。 这就是雷同于聚簇索引的功效了,聚簇索引,实际存储的循序结构与数据存储的物理机构是一致的,所以通常来说物理顺序结构只有一种,那么一个表的聚簇索引也只能有一个,通常默认都是主键,设置了主键,系统默认就为你加上了聚簇索引,当然有人说我不想拿主键作为聚簇索引,我需要用其他字段作为索引,当然这也是可以的,这就需要你在设置主键之前自己手动的先添加上唯一的聚簇索引,然后再设置主键,这样就木有问题啦。
总而言之,聚簇索引是顺序结构与数据存储物理结构一致的一种索引,并且一个表的聚簇索引只能有唯一的一条;

【非聚簇索引】
同样的,如果你去的不是图书馆,而是某城市的商业性质的图书城,那么你想找的书就摆放比较随意了,由于商业图书城空间比较紧正,藏书通常按照藏书上架的先后顺序来摆放的,所以如果查询到某书籍放在C区2柜3排5仓,但你可能要绕过F区,而不是A.B.C.D…连贯一致的,也可能同在C区的2柜,书柜上第一排是计算机类的书记,也可能最后一排就是医学类书籍;

那么对照着来看非聚簇索引的概念就比较好理解了,非聚簇索引记录的物理顺序与逻辑顺序没有必然的联系,与数据的存储物理结构没有关系;一个表对应的非聚簇索引可以有多条,根据不同列的约束可以建立不同要求的非聚簇索引;

<think>嗯,用户让我介绍一下Oracle中的索引总结。首先,我需要回忆一下Oracle数据库索引的相关知识,确保信息准确。索引在数据库中非常重要,能显著提高查询速度,但不同类型的索引适用场景不同,这点需要详细说明。 用户可能想了解索引的基本概念,比如B树索引、位图索引、函数索引等。我应该先介绍每种索引的结构原理,然后说明它们的优缺点以及适用情况。比如,B树索引适合高基数列,而位图索引适合低基数列,像性别这样的字段。 还要注意索引的创建管理,比如如何创建、维护,以及索引的存储参数。用户可能关心如何选择合适的索引策略,所以需要给出一些实际例子,比如在OLTPOLAP环境中的不同选择。 另外,索引的维护也是重点,比如重建索引、监控索引使用情况。这部分用户可能容易忽略,但实际应用中很重要,避免索引过多导致性能下降。 可能需要提到组合索引的使用技巧,比如最左前缀原则,以及索引覆盖查询的优势。还有函数索引的使用场景,比如对字段进行函数操作后的查询优化。 用户可能有疑问为什么有时候索引不生效,可以简要说明索引失效的常见原因,比如隐式类型转换、使用函数导致索引无效等。 最后,总结一下如何根据实际业务需求选择合适的索引类型,并给出一些最佳实践,比如定期分析索引使用情况,删除无用索引等。确保回答结构清晰,分点说明,方便用户理解。</think>好的,我来总结一下 Oracle 数据库中的索引核心知识点,分以下几个部分: --- ### 一、索引基础概念 **作用**:加速数据检索的数据库对象(类似书籍目录) **代价**:占用存储空间,降低DML操作速度(需维护索引结构) --- ### 二、常用索引类型 #### 1. B-Tree 索引(平衡树索引) - **结构**:根节点 → 分支节点 → 叶子节点(存储ROWID键值) - **特点**: - 适合高基数(唯一值多)的列 - 支持精确查找范围查询 - **语法**: ```sql CREATE INDEX idx_name ON table(column); ``` #### 2. 位图索引(Bitmap Index) - **结构**:用位图存储键值与ROWID的映射 - **特点**: - 适合低基数(重复值多)的列(如性别、状态字段) - 适合OLAP场景 - 锁粒度大,不适合高并发DML - **语法**: ```sql CREATE BITMAP INDEX idx_name ON table(column); ``` #### 3. 函数索引 - **特点**:对列应用函数后的结果建立索引 - **典型场景**:`WHERE UPPER(name) = 'JOHN'` - **语法**: ```sql CREATE INDEX idx_name ON table(UPPER(column)); ``` #### 4. 组合索引(复合索引) - **规则**: - 遵循最左前缀原则(查询必须使用最左侧列) - 列顺序影响查询效率(高频查询列放左侧) - **语法**: ```sql CREATE INDEX idx_name ON table(col1, col2); ``` --- ### 三、特殊索引类型 1. **反向键索引(Reverse Key)** - 反转键值,缓解热块争用(如序列主键的索引) - 语法:`CREATE INDEX idx_name ON table(column) REVERSE;` 2. **降序索引** - 支持`ORDER BY column DESC`优化 - 语法:`CREATE INDEX idx_name ON table(column DESC);` 3. **索引组织表(IOT)** - 表数据按索引结构存储,适用于主键频繁访问的场景 --- ### 四、索引使用策略 #### 1. 创建原则 - 在WHERE/JOIN/ORDER BY涉及的列上创建索引 - 小表(数据量 < 总行数5%)通常不需要索引 - 避免在频繁更新的列上过多建索引 #### 2. 索引失效场景 - 使用`IS NULL`/`IS NOT NULL` - 列参与函数运算(如`TO_CHAR(create_time)=...`) - 隐式类型转换(如字符串列使用数字查询) - 使用`LIKE '%value%`前导通配符 #### 3. 索引维护 - **重建索引**: ```sql ALTER INDEX idx_name REBUILD; ``` - **监控使用情况**: ```sql SELECT * FROM v$object_usage WHERE index_name = 'IDX_NAME'; ``` --- ### 五、性能优化要点 1. **索引覆盖查询**:SELECT只查询索引列时,无需回表 2. **索引跳跃扫描**(Oracle 9i+):组合索引跳过前导列查询 3. **索引压缩**:减少存储空间,语法:`CREATE INDEX ... COMPRESS` --- ### 六、实践建议 1. 定期使用`ANALYZE INDEX ... VALIDATE STRUCTURE`检查索引健康度 2. OLTP系统避免过多位图索引 3. 使用`DBMS_STATS`收集统计信息优化执行计划 需要具体案例分析或某个知识点的详细解释,可以随时告诉我! 📊
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值