题干与适用场景
PostgreSQL 18 默认使用虚拟生成列。生成列由其他列计算，不能直接写入。虚拟列在读取时计算且不占表存储；存储列在写入时计算并占用存储。选择会改变写入成本、读取成本、索引能力和迁移行为。
假设原始事件写入后不可变，报表频繁读取派生值，表规模足以让重写或读取 CPU 突增成为风险。
面试官考察点
面试官关注语义区分是否准确、是否知道表达式必须逐行且满足不可变约束，以及是否根据工作负载选择。强回答会讨论索引、查询计划、回填、回滚，并判断生成列是否比视图或物化视图更合适。
普通回答只说“虚拟省磁盘，存储更快”。强回答会说明 CPU 成本移动到哪里、表达式限制如何影响方案，以及如何验证迁移前后的结果一致。
回答前需要澄清的问题
- 读写比例是多少？哪些派生字段位于关键查询路径？
- 派生值是否需要索引、约束、分区，或复制到其他系统？
- 源列是否可变？表达式能否保持不可变且只依赖当前行？
- 表有多大？可接受的锁和重写预算是多少？
- 客户端依赖物理存储，还是只依赖 SQL 结果？
如果值很少读取且计算昂贵，存储列可以把成本移到写入。如果逻辑有跨行依赖或不满足不可变约束，生成列不合适，应使用视图、触发器或数据管道。
30 秒回答框架
“我会先看工作负载和表达式限制。虚拟列不占存储、不在写入时计算，但在读取时付出 CPU；存储列在写入时付出成本并占空间，有利于高频读取和索引。我会把虚拟列用于便宜且低频的派生，把存储列用于热点、昂贵或需要索引的值，先验证 PostgreSQL 18 的限制，再用影子列比较计划和结果，并保留回滚路径。”
分步骤深入解答
- 确认语义。 验证表达式只使用当前行和允许的不可变或内建函数。生成列不能直接写入，也不能引用另一个生成列。
- 测量工作负载。 估算每种方案的写放大、读 CPU、存储、缓存压力和索引收益。
- 选择物理行为。 写延迟和存储更紧张、读取计算便宜时选虚拟；读取热点、计算昂贵或需要索引时选存储。
- 检查边界。 虚拟列对用户自定义类型和函数有限制；生成列也不能作为分区键。确认复制和 ORM 反射行为。
- 安全迁移。 增加影子生成列，在采样和对抗数据上与旧表达式比较，切换客户端前检查计划变化。
- 运营和回滚。 监控读 CPU、写延迟、表和索引大小、空值或错误率、结果不一致，并保留旧投影直到新列验证完成。
替代方案包括便宜投影使用普通视图，跨行计算使用物化视图，需要下游持久值时使用 ETL 列。关键是明确派生数据的所有权。
高质量示范回答
“规范化国家代码是确定性的逐行计算，每个报表查询都会读取。我会测试存储生成列，因为在写入时付出一次成本，可以减少重复解析并支持需要的访问模式索引。很少查询的诊断标签则保留虚拟。迁移前增加影子列，在包含空值、边界和非法输入的数据上比较结果，检查计划，观察写延迟和索引增长；若 CPU 或存储超预算，就让客户端回到旧投影，并重新评估物化视图。”
常见错误
- 错误表现： 认为虚拟列总是更快 → 失败原因： 高频读取会反复消耗 CPU → 修正方法： 测量读取频率和表达式成本。
- 错误表现： 假设所有表达式都允许 → 失败原因： 存在逐行和不可变限制 → 修正方法： 先验证表达式与类型。
- 错误表现： 不比较就直接切换 → 失败原因： 空值和边界语义可能漂移 → 修正方法： 使用影子列和不一致检查。
- 错误表现： 忽略索引和存储 → 失败原因： 读取优化可能制造写入或磁盘压力 → 修正方法： 监控计划、索引大小和写延迟。
追问及应对
如果表达式调用用户自定义函数怎么办？
检查列是虚拟还是存储，并确认函数符合文档限制。虚拟列可能禁止用户自定义函数和类型；必要时改为存储列、视图或数据管道。
生成列可以作为分区键吗？
不能。分区应单独设计；需要分区裁剪时，显式物化一个受支持的键。
如何证明迁移等价？
在代表性样本以及空值、边界、非法输入和时区场景上比较旧新表达式，切换读取前对不一致告警。
什么时候物化视图更好？
当计算跨行或跨表、可以接受刷新延迟，并且需要独立刷新与索引时使用物化视图。生成列适合确定性的逐行派生。