我们的文章会在微信公众号IT民工的龙马人生和博客网站( www.htz.pw )同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
由于博客中有大量代码，通过页面浏览效果更佳。
本文为个人学习《Expert Oracle Database Architecture Techniques and Solutions for High Performance and Productivity（第四版本》一书过程中的笔记与理解分享，仅用于学习与交流，部分内容参考原书观点并结合>实际经验进行整理。若涉及版权问题，请联系删除或沟通处理。也请大家支持购买原版书籍。
分区索引详解：本地索引与全局索引
什么是分区索引？
想象一下，你有一个巨大的图书馆（表），里面有几百万本书（数据行）。为了快速找到想要的书，你建立了索引卡片系统（索引）。当图书馆变得太大时，你把书分到不同的房间（分区）存放。这时候，索引系统也需要相应地进行分区管理。
分区索引主要有两种方式，就像管理图书馆的索引卡片有两种不同思路。
两种分区索引的对比
1. 本地索引：分房间管理的索引卡片
- 工作方式：每个图书房间（表分区）都有自己专属的索引卡片盒（索引分区）
- 特点：
- 索引卡片只记录本房间的书籍信息
- 找某个房间的书，只需要看该房间的索引卡片
- 某个房间维修时，其他房间的索引不受影响
2. 全局索引：集中管理的总索引卡片
- 工作方式：有一个总索引卡片盒，记录所有房间的书籍信息
- 特点：
- 索引卡片可能按书名或作者名重新整理，与房间划分无关
- 找书时可能需要查看整个总索引
- 总索引卡片盒坏了，所有房间的找书都会受影响
实际应用场景
数据仓库：偏爱本地索引
在数据仓库中（比如企业的报表系统），人们更倾向于使用本地索引，因为：
- 高可用性：某个分区出问题不影响其他分区
- 维护方便：整理某个分区的数据时，只需要重建该分区的索引
- 恢复灵活：可以单独恢复某个时间点的某个分区
OLTP系统：需要全局索引
在交易系统（如银行ATM）中，全局索引更常见，因为：
- 需要快速查询：无论数据在哪个分区，都能通过全局索引快速定位
- 保证唯一性：比如确保银行卡号在全表范围内唯一
本地索引的两种类型
前缀索引：按分区键排序的索引
好比图书馆先按楼层（分区键）再按书名排序的索引卡片。找书时，如果你知道在几楼，就能直接到对应的卡片盒查找。
非前缀索引：不按分区键排序的索引
好比只按书名排序的索引卡片。找书时，可能需要查看所有楼层的卡片盒，但如果你记得书名，优化器会智能地只搜索相关的卡片盒。
一个重要限制：唯一性约束
这是本地索引的一个关键限制：如果要保证某列的值全表唯一，这列必须包含在分区键中。
举个例子：
- ❌ 不能这样做：按时间分区，但想保证用户ID唯一
- ✅ 必须这样做：按用户ID分区，才能保证用户ID唯一
为什么有这个限制？
想象一下，如果要保证身份证号唯一，但数据按时间分区存放，系统需要检查所有分区的索引才能确认号码是否重复，这样就失去了分区的优势。
实用建议
-
选择策略：
- 数据仓库、报表系统：优先考虑本地索引
- 高并发交易系统：可能需要全局索引支持
-
设计思考：
- 经常按什么条件查询？这决定了索引类型
- 需要保证哪些字段的唯一性？这影响分区方案
-
性能优化：
- 查询时尽量使用分区键条件，这样能利用分区消除提升性能
- 非前缀索引在某些场景下也很有效，不要盲目排斥
总结
分区索引就像大图书馆的管理系统，没有绝对的好坏，只有适合与否。理解业务需求和数据特点，才能设计出最合适的索引方案。关键是要知道每种方式的优缺点，在实际应用中灵活选择。
------------------作者介绍-----------------------
姓名：黄廷忠
个人博客: (http://www.htz.pw)
CSDN地址: (https://blog.csdn.net/wwwhtzpw)
博客园地址: (https://www.cnblogs.com/www-htz-pw)