分区表与VLDB实践
分区是 Oracle 管理大表和大索引的重要手段。优秀分区设计能改善查询裁剪、维护窗口、归档、并行执行和冷热数据治理；糟糕分区设计会制造更高复杂度。
# 1. 学习目标与定位
| 维度 | 内容 |
|---|---|
| 难度层级 | 高级设计 |
| 核心目标 | 从底层运行链路理解本篇主题，能把概念、SQL、指标、故障和工程取舍连起来 |
| 适合人群 | 开发人员关注分区键和查询条件；运维人员关注分区维护、索引状态、统计信息和归档窗口。 |
# 2. 核心概念总览
分区表与VLDB实践
├─ Range Partition
├─ List Partition
├─ Hash Partition
├─ Composite Partition
├─ Partition Pruning
├─ Partition-Wise Join
├─ Local Index
├─ Global Index
└─ Online Maintenance
这张图只用来定位本章范围。正文不会把每个词机械拆成固定问答，而是按 Oracle 的真实运行机制解释它们之间如何协作、在哪里影响开发、在哪里影响运维。
# 3. 底层原理详解
分区把一个逻辑大表拆成多个可独立管理的物理片段。优化器如果能根据谓词确定需要访问哪些分区，就可以做 Partition Pruning，显著减少扫描范围。
分区设计必须围绕数据生命周期和访问模式。按时间分区适合历史归档，按地区或租户列表分区适合隔离管理，哈希分区适合打散热点，组合分区适合复杂大表。
分区维护的难点在索引、统计信息和业务窗口。Local Index 维护简单但查询能力受分区键影响，Global Index 能支持跨分区访问但维护成本更高。
# 4. 关键机制拆解
# 4.1. 范围、列表、哈希和组合分区
Range Partition 常用于日期和递增范围，List Partition 常用于枚举维度，Hash Partition 用于均匀分布，Composite Partition 则组合多种策略。
选择分区键时要看查询谓词、数据增长、归档粒度和并发热点。分区键不是随便选一个字段，而是未来维护和访问路径的核心。
# 4.2. Partition Pruning 与查询设计
分区裁剪要求 SQL 谓词能让优化器判断分区范围。函数包裹分区键、隐式转换或缺少分区键条件，可能导致扫描大量分区。
开发人员写大表 SQL 时要主动包含分区条件。没有分区裁剪的大表查询，分区反而只是增加了对象复杂度。
# 4.3. Local/Global Index 与维护
Local Index 随分区拆分，分区 drop/truncate/exchange 更容易；Global Index 跨分区，能支持非分区键访问，但分区维护可能导致索引不可用或需要维护。
运维人员做分区操作前必须明确 UPDATE GLOBAL INDEXES、索引重建、统计信息和回滚方案。
# 4.4. VLDB 归档和在线维护
大表常见维护包括新增分区、分区交换、压缩历史分区、归档旧分区和在线重定义。优秀设计可以把大规模 delete 变成分区 truncate/drop。
不要等表已经数十 TB 才补分区治理。分区是模型设计，不是事后清理工具。
# 5. 功能模块细节补充
本节围绕概念图中的模块逐个补充底层细节，重点讲它们在 Oracle 运行链路中的位置和相互关系，而不是按固定角色模板拆分。
# 5.1. Range Partition
Range Partition 是大表治理能力的一部分。它通过把逻辑对象拆成可独立维护的分区来支持裁剪、归档、并行和在线维护；如果 SQL 不带分区键或索引策略错误，分区只会增加复杂度。
# 5.2. List Partition
List Partition 是大表治理能力的一部分。它通过把逻辑对象拆成可独立维护的分区来支持裁剪、归档、并行和在线维护；如果 SQL 不带分区键或索引策略错误，分区只会增加复杂度。
# 5.3. Hash Partition
Hash Partition 是性能诊断证据链中的观察点。Oracle 调优要先看数据库时间花在哪里，再关联 SQL_ID、等待事件、对象、会话、系统资源和变更记录；该模块用于把“感觉慢”变成可验证结论。
# 5.4. Composite Partition
Composite Partition 是大表治理能力的一部分。它通过把逻辑对象拆成可独立维护的分区来支持裁剪、归档、并行和在线维护；如果 SQL 不带分区键或索引策略错误，分区只会增加复杂度。
# 5.5. Partition Pruning
Partition Pruning 是大表治理能力的一部分。它通过把逻辑对象拆成可独立维护的分区来支持裁剪、归档、并行和在线维护；如果 SQL 不带分区键或索引策略错误，分区只会增加复杂度。
# 5.6. Partition-Wise Join
Partition-Wise Join 是 SQL 表达能力的一部分。它不是单纯语法糖，而会改变优化器改写空间、中间结果规模、访问路径、排序哈希和临时空间消耗；复杂 SQL 必须用真实执行计划和行数验证。
# 5.7. Local Index
Local Index 是访问路径和维护成本之间的取舍。索引能减少扫描、支持约束和排序，但会增加 DML 成本、空间消耗和统计信息复杂度；不同索引类型必须匹配数据分布、并发模型和维护窗口。
# 5.8. Global Index
Global Index 是访问路径和维护成本之间的取舍。索引能减少扫描、支持约束和排序，但会增加 DML 成本、空间消耗和统计信息复杂度；不同索引类型必须匹配数据分布、并发模型和维护窗口。
# 5.9. Online Maintenance
Online Maintenance 是大表治理能力的一部分。它通过把逻辑对象拆成可独立维护的分区来支持裁剪、归档、并行和在线维护；如果 SQL 不带分区键或索引策略错误，分区只会增加复杂度。
# 6. 开发人员重点提醒
- 大表查询必须评估分区裁剪。
- 按生命周期设计分区键，避免事后补救。
- 跨分区唯一约束和全局索引要提前评审。
# 7. 运维人员重点提醒
- 分区维护要检查索引状态、统计信息和备份影响。
- 历史归档优先使用分区交换或分区级操作。
- 监控分区大小倾斜和新增分区任务。
# 8. 典型问题与排查
- 分区表仍全扫：检查谓词、函数和隐式转换。
- 分区维护后 SQL 变慢：检查全局索引和统计信息。
- 单分区过大：检查分区粒度和数据倾斜。
# 9. 实践建议与检查清单
- 分区键匹配访问模式
- 分区裁剪可验证
- Local/Global 策略明确
- 历史归档脚本化
- 分区统计信息策略明确
# 10. 阶段小结
本篇的学习重点不是记住术语，而是能把底层机制、业务语义和生产证据连起来。读完本篇后，应该能解释关键组件如何协作、常见问题为什么发生、开发侧如何避免制造风险、运维侧如何用指标和日志把问题定位到具体链路。