数据倾斜主因是分区键与业务分布不匹配，范围分区易倾斜因业务增长不均，哈希分区仅适等值查询，复合分区（range+hash）兼顾归档与查询效率，统计信息不准会加剧倾斜。
为什么范围分区容易倾斜？
按时间或ID范围分区时，只要业务增长不均匀，就必然倾斜。比如订单表按 ORDER_ID 范围分区，但新注册用户下单集中、老用户沉寂，导致最新几个分区塞满70%数据；又或者按 TRADE_DATE 每月一分区，但促销月交易量是平日5倍，单个分区体积暴涨3倍以上。
- 检查方法：
SELECT partition_name, num_rows FROM user_tab_partitions WHERE table_name = 'YOUR_TABLE'，看行数标准差是否 > 2×均值 - 根本原因：范围本身不保证数据均匀，只保证逻辑连续
- 别指望靠“多分几个小范围”解决——这只会让管理成本飙升，热点仍存在
哈希分区能解决均匀性问题吗？
能，但有硬约束：只适用于等值查询（WHERE col = ?），不支持范围扫描（WHERE col BETWEEN ... AND ...）。如果你的高频查询是“查某用户最近3个月流水”，哈希分区会让这个查询跨全部子分区，性能反而更差。
- 建表示例：
PARTITION BY HASH (USER_ID) PARTITIONS 8，必须指定具体分区数，不能用MAXVALUE - 注意：哈希函数由Oracle内置实现，不可替换；
USER_ID必须是非空、稳定值（NULL会导致分配到默认分区，加剧倾斜） - 如果原表已有数据，重建分区需
ALTER TABLE ... MODIFY PARTITION ...或导出导入，无法在线重分布
复合分区才是生产环境主流解法
Range + Hash 组合，兼顾归档与查询效率。主分区按时间范围（如月），子分区按账号哈希，既保留时间维度可裁剪，又把单月数据打散到多个物理段。
- 典型建表语句：
PARTITION BY RANGE (TRADE_DATE) SUBPARTITION BY HASH (PAYEE_ACCOUNT) SUBPARTITIONS 4 - 子分区数建议设为2的幂（4/8/16），避免Oracle内部哈希桶冲突
- 注意：子分区不能单独指定表空间，需在主分区定义里统一声明，否则报
ORA-14109 - 查询时若带
TRADE_DATE和PAYEE_ACCOUNT两个条件，优化器才能精准定位到唯一子分区；缺一个，就可能扫整个主分区
统计信息不准确会让倾斜雪上加霜
即使分区物理均匀，如果 DBMS_STATS 没采集直方图，优化器仍会误判数据分布，导致执行计划错误——比如对实际只有5行的值估算成250万行，直接放弃索引走全表扫描。
- 强制采集高精度直方图：
DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCHEMA', tabname=>'TABLE', method_opt=>'FOR COLUMNS SIZE 254 COL_NAME') - 避免用
AUTO_SAMPLE_SIZE处理极端倾斜列（如含大量NULL或少数值占99%），改用固定采样率：estimate_percent => 100 - 检查直方图是否生效：
SELECT column_name, histogram, num_buckets FROM user_tab_col_statistics WHERE table_name='TABLE' AND column_name='COL_NAME'，确认histogram不是HEIGHT BALANCED或空值
