Oracle多列列表分区必须用VALUES((v1,v2),(v3,v4))嵌套语法，不支持单列写法；常见错误是误写为VALUES(1,'北区',2)，将触发ORA-14035；适用于region_code+order_type等强语义组合场景。
多列列表分区只支持 VALUES ((v1,v2), (v3,v4)) 语法，不支持单列写法
Oracle 列表分区允许用多个列作为分区键，但必须用嵌套括号明确表示元组组合。常见错误是写成 PARTITION p1 VALUES (1, '北区', 2) —— 这会被解析为三列独立值，触发 ORA-14035: invalid partition key specified。正确写法必须是 VALUES ((1,'北区'), (2,'南区'))，外层括号表示值组集合，内层括号表示每个组合。
使用场景集中在区域+类型、渠道+状态这类强业务语义组合字段。例如订单表按 (region_code, order_type) 分区，能避免跨 region 扫描，也比单列分区更细粒度控制数据分布。
- 建表时必须显式声明所有参与列，顺序不能错；交换或合并分区时，列顺序和类型必须完全一致
- 默认分区（
VALUES (DEFAULT)）仍可用，但仅匹配未被任何元组覆盖的行，不继承多列逻辑 - 不支持间隔分区（
INTERVAL）或自动列表分区（AUTO）与多列列表混用
ALTER TABLE ... MERGE PARTITIONS 不支持多列列表分区
MERGE PARTITIONS 在 Oracle 12c 中只接受 RANGE 和 LIST 类型的一级分区，但**实际仅对单列 LIST 分区有效**。一旦用了多列列表（如 PARTITION BY LIST (a,b)），执行 MERGE PARTITIONS p1,p2 INTO PARTITION p2 会直接报 ORA-14055: partitions are not adjacent —— 因为 Oracle 内部不认为多列 LIST 分区存在“相邻”概念。
这意味着：想归档旧数据、清理低水位分区时，无法用 MERGE 合并两个按 (region, status) 定义的分区。你只能先 EXCHANGE 出数据到临时表，再 INSERT /*+ APPEND */ 合并后重载，或直接 DROP + RECREATE 新分区（需停写）。
- 不要依赖文档里“LIST 分区支持 MERGE”的笼统描述，务必验证分区定义是否含多列
-
USER_TAB_PARTITIONS中的HIGH_VALUE字段对多列 LIST 是空值，无法通过它判断逻辑顺序 - 若真需合并，优先考虑改用 RANGE 分区（如将多列映射为整型编码）或升级到 19c+ 的
MOVE PARTITION ... MERGE在线能力
本地索引维护在多列列表分区下容易失效
多列列表分区上的本地索引（LOCAL INDEX）在执行 TRUNCATE PARTITION 或 DROP PARTITION 时不会自动失效，但若后续做了 EXCHANGE PARTITION 或 SPLIT PARTITION，就极易触发 UNUSABLE 状态——尤其当交换表结构与原分区列顺序/类型有细微差异（如 VARCHAR2(10) vs VARCHAR2(20)）时。
关键检查点不是索引名，而是 USER_IND_PARTITIONS.status。别只看 USER_INDEXES.status = 'VALID'，那只是全局视图汇总，真正起作用的是每个分区索引的状态。
- 每次
EXCHANGE后必须运行SELECT index_name, partition_name, status FROM user_ind_partitions WHERE index_name = 'XXX'; - 重建单个失效分区索引用
ALTER INDEX idx_name REBUILD PARTITION p1;，不要全索引重建 - 多列 LIST 分区不支持
UPDATE INDEXES子句（该子句仅对 RANGE/SPLIT/MERGE 有效），所以所有索引维护都得手动
默认分区 + 多列列表的边界行为常被忽略
多列列表分区中加 PARTITION p_default VALUES (DEFAULT) 看似安全，但 Oracle 对 DEFAULT 的匹配逻辑是“全列值都不匹配任何已定义元组”，而不是“任一列不匹配”。这意味着：如果定义了 ((1,'A'), (2,'B'))，那么 (1,'C')、(3,'A')、(3,'C') 都会进默认分区——但它不会帮你发现 (1,'A') 和 (1,'B') 这类漏配组合。
生产环境中，默认分区容易悄悄膨胀，尤其当业务新增子类型但没同步更新分区定义时。监控重点不是数据量，而是 USER_TAB_PARTITIONS.num_rows 是否持续增长且无对应 DML 日志。
- 定期用
SELECT COUNT(*) FROM t PARTITION (p_default) WHERE rownum 抽样查内容，确认是否真为“兜底”而非“漏配” - 不要在默认分区上建本地索引，它会随新数据不断分裂，且无法预测高水位
- DDL 变更脚本里，凡涉及多列 LIST 分区增删，必须配套检查默认分区当前数据占比，超 5% 就要告警
