虚拟列不能直接用作分区键，Oracle 12c 仅允许在 PARTITION BY 中引用已命名的显式列名，不支持表达式如 TRUNC(sale_date)，解析器不展开或推导等价性；必须先定义确定性虚拟列（如 yyyymm GENERATED ALWAYS AS (TO_CHAR(sale_date, 'YYYYMM'))），再以其列名分区，且 VALUES 字面量须与虚拟列输出完全一致。
虚拟列不能直接用作分区键。oracle 12c 明确禁止在 partition by 子句中直接引用表达式（如 trunc(created_date)），哪怕该表达式和你定义的虚拟列完全一致；它只接受已命名的、显式定义的列名，且该列必须是表结构中真实存在的、类型兼容的列。
为什么不能直接写 PARTITION BY TRUNC(sale_date)
语法校验阶段就会失败，报错类似 ORA-54013 或 ORA-14039，根本不是运行时问题。Oracle 的分区键解析器不展开表达式，也不做等价推导——它只认列名。即使你给 sale_date 加了函数索引或定义了同逻辑的虚拟列，只要没把它“落地”为一个独立列名并显式写进 PARTITION BY，就过不了建表这关。
正确做法：先建虚拟列，再用其列名分区
必须严格按顺序操作：
- 虚拟列定义必须带
GENERATED ALWAYS AS，且表达式是确定性的（禁用SYSDATE、USER、SYS_GUID()等） - 虚拟列类型要支持分区（
VARCHAR2、NUMBER、DATE可以；CLOB、LONG不行） -
PARTITION BY后只能跟这个虚拟列的**名字**，不能加任何函数包装 - 分区
VALUES中的字面量必须和虚拟列实际输出**完全一致**（大小写、空格、格式，比如'202301'和'2023-01'就不匹配）
示例：
CREATE TABLE sales (
id NUMBER,
sale_date DATE,
amount NUMBER,
yyyymm VARCHAR2(6) GENERATED ALWAYS AS (TO_CHAR(sale_date, 'YYYYMM')) VIRTUAL
)
PARTITION BY LIST (yyyymm) (
PARTITION p_202301 VALUES ('202301'),
PARTITION p_202302 VALUES ('202302'),
PARTITION p_other VALUES (DEFAULT)
);常见踩坑点：值不一致导致 ORA-14037
最隐蔽也最常出问题的是虚拟列输出和 VALUES 字面量不匹配。比如：
- 虚拟列用
TO_CHAR(sale_date, 'YYYY-MM')→ 输出'2023-01'，但VALUES ('202301')就错 - 虚拟列表达式隐式转时区，而插入数据时
sale_date是TIMESTAMP WITH LOCAL TIME ZONE，导致某几行生成'202301'，另几行生成'202302' - 建表前没查实际值分布：
SELECT DISTINCT yyyymm FROM sales，结果发现存在空格或大小写混用
建议在建表前先跑一次：SELECT DISTINCT TO_CHAR(sale_date, 'YYYYMM') FROM sales WHERE sale_date IS NOT NULL;，把结果直接复制进 VALUES 列表。
替代方案：用真实列 + 触发器同步值
如果虚拟列逻辑复杂、依赖非确定性上下文，或需要兼容老版本 Oracle，更稳妥的做法是用真实列承载分区键值：
- 新增一个
NOT NULL普通列（如quarter_code VARCHAR2(6)） - 配
BEFORE INSERT OR UPDATE触发器，强制赋值：:NEW.quarter_code := TO_CHAR(:NEW.sale_date, 'YYYY-Q'); - 用该真实列做
PARTITION BY LIST，确保所有插入/更新都走触发器 - 已有数据需先批量更新：
UPDATE sales SET quarter_code = TO_CHAR(sale_date, 'YYYY-Q');
这个方案绕开了虚拟列限制，但多了一次写入开销，且触发器里不能调用非确定性函数。
关键在于：Oracle 不帮你“猜意图”，它只认你白纸黑字定义的列名和值。想让分区生效，就得让虚拟列的输出可枚举、可预测、可对齐——否则再快的查询也卡在元数据校验那一步。
