范围-散列组合分区适合高并发写入且查询含时间+模糊匹配的场景，通过主分区按时间切分、子分区按低基数列哈希打散数据，缓解i/o竞争与索引争用，但需注意散列键选择、子分区数量（4/8/16）、显式表空间分配及统计信息全粒度收集。
范围-散列组合分区适合高并发写入但查询条件含时间+模糊匹配的场景
当你用 PARTITION BY RANGE 切好时间主分区后，子分区不是为了“看起来更细”，而是为了解决主分区内部的热点和分布不均问题。比如订单表按 order_date 月分区，但每月新增订单集中在最后几天，且查询常带 WHERE order_date BETWEEN ... AND ... AND status IN ('paid', 'shipped') ——此时单靠范围分区无法避免单个分区内的 I/O 竞争和索引争用。
散列子分区能强制把同一时间窗口的数据打散到多个物理段，提升并行插入吞吐量，也缓解本地索引的叶块竞争。但它不支持子分区裁剪：查询条件里没带散列键（比如 status），Oracle 就必须扫描该主分区内所有子分区。
实操建议：
- 散列键必须是低基数、稳定、非空的列，
status或channel_code比order_id更合适——后者散列后会导致关联查询无法走分区剪枝 -
SUBPARTITIONS N的 N 建议设为 4、8 或 16，避免过大（如 64）导致管理开销陡增，也别过小（如 2）起不到分散效果 - 务必显式指定每个子分区的表空间，例如
SUBPARTITION BY HASH(status) SUBPARTITIONS 8 STORE IN (ts_s1, ts_s2, ts_s3, ts_s4)，否则 Oracle 默认复用主分区表空间，I/O 还是挤在一块盘上
范围-列表组合分区适用于地域/状态等离散维度强过滤的业务
典型场景是物流或金融类系统：主分区按时间切（如 ship_date），子分区按发货地 origin_city 或客户等级 customer_tier 列表切。这类字段值有限、业务语义明确，且查询经常固定查某几个城市或某几类客户。
优势在于既能利用范围剪枝跳过历史分区，又能通过列表子分区精准定位到目标数据块，避免全主分区扫描。但缺点也很直接：列表值一旦新增（比如新开通一个城市），就必须手工 ALTER TABLE ... MODIFY PARTITION ... ADD SUBPARTITION，没法自动扩展。
实操建议：
- 列表子分区的值必须提前收敛，不要用动态生成的 ID 或 UUID 类字段做子分区键
- 建表时尽量把高频查询的城市/区域放在靠前的子分区定义里（虽然 Oracle 不保证顺序，但 DDL 可读性更高）
- 如果列表值超过 32 个，优先考虑改用范围-散列，否则子分区数量爆炸，
dba_tab_subpartitions查询变慢，备份恢复窗口拉长
组合分区的存储参数必须按子分区粒度单独配置
很多人以为写了 SUBPARTITIONS 8 就万事大吉，结果发现性能没提升甚至更差——根本原因是所有子分区默认共享主分区的 INITIAL 和 NEXT 参数，而实际每个子分区的数据量可能只有主分区的 1/10，却分配了和主分区一样大的初始 extent（比如 80MB），造成严重空间浪费和 extent 碎片。
更隐蔽的问题是：如果没显式指定 TABLESPACE，所有子分区会落到同一个表空间，哪怕物理文件分布在不同磁盘，ASM 条带策略也可能失效。
实操建议：
- 建表时用
SUBPARTITION TEMPLATE统一控制子分区存储，例如：SUBPARTITION TEMPLATE ( SUBPARTITION sp1 TABLESPACE ts_q1_01 STORAGE(INITIAL 8M NEXT 2M), SUBPARTITION sp2 TABLESPACE ts_q1_02 STORAGE(INITIAL 8M NEXT 2M) )
- 禁用
SEGMENT CREATION DEFERRED，确保子分区一创建就有真实段结构，否则首次插入时才分配空间，可能触发延迟等待 - 用
SELECT subpartition_name, tablespace_name, initial_extent FROM dba_tab_subpartitions WHERE table_name = 'YOUR_TABLE'定期核对，确认每个子分区的表空间和存储参数已生效
组合分区最易被忽略的坑：全局索引维护成本与统计信息滞后
组合分区本身不解决索引问题。一旦你建了全局索引（比如唯一约束依赖的索引），每次 ADD PARTITION 或 DROP PARTITION 都会导致全局索引失效，必须 REBUILD，而重建过程会锁表、消耗大量 UNDO 和 TEMP 空间。本地索引虽免维护，但跨子分区查询时无法合并索引范围扫描，性能反而不如单一分区表。
另一个隐形杀手是统计信息：Oracle 默认只收集主分区级统计信息，子分区的 num_rows、blocks 等长期为空，导致 CBO 估算严重失真，本该走索引的查询变成全分区扫描。
实操建议：
- 除非业务强要求唯一性跨全表，否则一律用本地索引；若必须全局索引，改用
UPDATE GLOBAL INDEXES子句在 DDL 中自动维护 - 执行
DBMS_STATS.GATHER_TABLE_STATS时，务必加GRANULARITY => 'ALL'，否则子分区统计信息永远不更新 - 检查
dba_tab_statistics中global_stats和stale_stats字段，比看last_analyzed更可靠
