计算列需PERSISTED才能建索引以加速GROUP BY；必须匹配高频分组逻辑，避免嵌套函数；有写放大、存储和维护成本；优先考虑物理列等更轻量方案。
直接加计算列不一定提速，关键得看它能不能被索引覆盖、是否参与 WHERE 或 GROUP BY 的过滤逻辑。
计算列必须持久化才能建索引
SQL Server 默认创建的计算列是虚拟的（NOT PERSISTED），不占存储空间，但也不能建索引。分组查询要走索引加速，这列必须显式声明为 PERSISTED。
- 不加
PERSISTED：无法在该列上创建索引，GROUP BY my_computed_col仍会触发全表扫描 - 加了
PERSISTED：可建索引，且能参与覆盖索引设计，避免回表 - 注意权限：需要
ALTER表权限，且表达式必须是确定性的（比如DATEADD(day, 1, create_date)可以，GETDATE()不行）
计算列 + 索引要匹配实际分组模式
别为了“看起来整洁”而抽象出一个通用计算列。它必须精确对应你高频查询里的分组逻辑，否则就是白忙。
- 查“按年月分组订单数”？建计算列
order_year_month AS FORMAT(order_date, 'yyyy-MM') PERSISTED，再建索引CREATE INDEX IX_orders_ym ON orders(order_year_month) - 查“按部门+职级组合统计”？建
dept_level_key AS CONCAT(dept_id, '-', level_code) PERSISTED，而不是分别对两个字段建复合索引——后者在WHERE dept_id = X AND level_code = Y场景更优，但分组时未必走得到 - 避免嵌套函数：像
UPPER(LEFT(name, 10))这类表达式会让索引选择性下降，也增加持久化开销
和普通索引比，计算列索引的代价容易被忽略
它不是免费午餐。每次 INSERT/UPDATE 涉及基础列，SQL Server 都要实时算出值并写入，对写密集场景有真实压力。
- 写放大：如果基础列更新频繁（比如
status、last_modified），计算列会拖慢 DML 性能 - 存储占用：哪怕只是
ISNULL(flag, 0)，也会多占 4 字节/行，千万级表就是 ~40MB - 维护成本：执行
DBCC SHOW_STATISTICS时，统计信息包含该列，过期后可能影响优化器对分组路径的选择 - 替代方案更轻量：如果只是想按日期分组，优先考虑新增物理的
order_month DATE列 + 默认约束，比计算列更可控
真正省事的点不在“加计算列”，而在“让分组字段变成索引可直接驱动的原子值”。一旦你开始为每个分组口径都加一个计算列，说明数据建模或查询模式本身可能需要重构了。
