RANGE-HASH复合分区不能一概而论解决数据倾斜：适合时间有序且多维查询场景，但用户分布极不均时可能加剧热点；需主分区单调递增、子分区数为2的幂次；PostgreSQL需手动模拟，运维成本高。
什么是 RANGE-HASH 复合分区，它真能解决你的数据倾斜问题？
不能一概而论。range-hash 适合「时间有序 + 高频查询分散在多个业务维度」的场景，比如按 create_time range 分区后，再对 user_id 做 hash 子分区——这样既保留时间范围扫描效率，又避免单个 range 分区因某几个热用户写入爆炸而膨胀。但如果你的 user_id 分布极度不均（比如 5% 用户占 90% 流量），hash 子分区反而会放大热点，此时 range-list 更稳妥。
- RANGE 主分区必须是单调递增字段（如
date、id），否则无法自动管理边界 - HASH 子分区数建议设为 2 的幂次（
4、8、16），避免 MySQL/Oracle 内部取模冲突 - PostgreSQL 不原生支持 RANGE-HASH，需用
PARTITION BY RANGE+ 手动建子表 + 触发器模拟，运维成本陡增
创建 RANGE-LIST 复合分区时，LIST 子分区值必须提前穷举吗？
是的，而且这是最容易翻车的地方。LIST 不像 HASH 可自动散列，你必须显式声明每个子分区包含哪些离散值，漏一个就会报错 ERROR: no partition of relation "t" found for row。
- 典型错误：把
status字段按'active'、'inactive'建 LIST，但业务突然写入'pending'—— 直接 INSERT 失败 - 补救方案只有两个：
ALTER TABLE ... ADD PARTITION（MySQL 8.0+ / Oracle）或提前预留DEFAULT分区（仅 Oracle 支持，MySQL 不支持） - 如果状态值动态增长（如订单类型从 10 种扩到 50 种），LIST 维护成本远高于 HASH，这时该换 RANGE-RANGE 或考虑归档冷数据
为什么 ALTER TABLE ADD PARTITION 在复合分区下常卡住或失败？
因为底层要重写整个子分区数据，不是简单改元数据。尤其当主分区已存在大量数据，且子分区键有索引时，锁表时间可能长达数小时。
- MySQL 中对 RANGE-HASH 表执行
ALTER TABLE ... ADD PARTITION，会触发全分区重建，期间 DML 阻塞 - Oracle 要求新增的 LIST 子分区值不能与现有分区重叠，且必须在
VALUES IN中完整列出，少一个单引号都会报ORA-14074 - 安全做法：在低峰期操作；用
pt-online-schema-change（MySQL）或DBMS_REDEFINITION（Oracle）做在线变更；新分区尽量预建，别等业务压上来才加
查询性能没提升反而变慢？检查这三个隐性开销
复合分区不是银弹。分区裁剪（pruning）失效、跨分区 JOIN、子分区索引冗余，都会吃掉性能红利。
- WHERE 条件没覆盖全部分区键（比如只写
WHERE create_time > '2024-01-01'，漏了user_id），数据库可能扫所有 HASH 子分区 - JOIN 两张同结构复合分区表时，若分区键名或类型不一致（如一张用
user_id INT，另一张用user_id BIGINT），优化器无法对齐分区，退化成全表连接 - 每个子分区都默认继承主表索引，但若查询只落在少数子分区，却为每个子分区维护完整索引，磁盘和写入开销翻倍——考虑用局部索引（
LOCAL INDEX，Oracle）或按需在热点子分区建索引（MySQL）
最常被忽略的是：分区字段的数据类型和字符集必须严格一致，哪怕只是 VARCHAR(32) 和 VARCHAR(64) 的差异，都可能导致裁剪失败。这类细节不报错，只悄悄降级为全分区扫描。
