必须标记为PERSISTED，因SQL Server仅允许对物理存储的确定性计算列创建索引；非持久化列值每次查询实时计算，无法建立稳定索引结构。
计算列本身不能直接被索引加速 JOIN，但把它物化 + 建索引后，就能让 JOIN 条件走索引——前提是 JOIN 里真用了这个计算列，且没做任何破坏有序性的操作。
为什么计算列要先 persisted 才能建索引
SQL Server 默认的计算列是虚拟列（computed column），值不落地、不存储，每次查询都要实时计算。这意味着即使你对它建了索引，SQL Server 也拒绝接受——报错 Cannot create index on computed column 'xxx' because it is not persisted。
必须显式声明 PERSISTED，让数据库把计算结果物理存进表里，才具备被索引的资格。
- 不加
PERSISTED：只能用在 SELECT 或 WHERE 中，JOIN 时无法利用索引 - 加了
PERSISTED：可建非聚集索引，JOIN 条件若严格匹配该列，就可能触发 Merge Join 或避免类型转换 - 注意：
PERSISTED列会占用磁盘空间，更新基础字段时它自动重算（有轻微写开销）
什么场景下值得为计算列建索引
不是所有计算列都适合。典型有效场景是：JOIN 条件中长期存在函数包装，又无法改写原始 SQL（比如遗留系统、ORM 自动生成语句）。
-
ON UPPER(a.name) = UPPER(b.name)→ 在 a、b 表上分别建name_upper AS UPPER(name) PERSISTED，再对它建索引 -
ON DATEADD(day, 1, a.order_date) = b.ship_date→ 建next_order_date AS DATEADD(day, 1, order_date) PERSISTED索引 -
ON ISNULL(a.code, '') = b.code→ 建code_clean AS ISNULL(code, '') PERSISTED索引（注意：b.code 也得是 NOT NULL 或同步处理）
反例：ON LEN(a.desc) > LEN(b.desc) 这种非等值、非 SARGable 的条件，建索引无意义。
建索引后 JOIN 还不走？检查这三点
即使计算列已 PERSISTED 并建了索引，JOIN 仍可能退化为 Hash Join 或带 Sort 的 Merge Join。关键看执行计划里子节点是否标 Ordered="true"：
- 确认 JOIN 条件是否**完全一致**使用该计算列，比如写了
UPPER(a.name)却建了name_lower AS LOWER(name)，白搭 - 检查关联字段是否有隐式转换：
a.name_upper是varchar(50)，b.name_upper是nvarchar(50)→ 触发转换，索引失效 - 统计信息过期：
DBCC SHOW_STATISTICS('table', 'ix_name_upper')查modification_counter，超总行数 20% 就得UPDATE STATISTICS table WITH FULLSCAN
比计算列更轻量的替代方案
如果只是想绕过函数导致的索引失效，优先考虑表达式索引（SQL Server 2016+ 支持）：
CREATE INDEX ix_a_name_upper ON a (UPPER(name));
它不需要改表结构、不占额外存储，效果和 PERSISTED 计算列 + 索引几乎一样，且维护成本更低。但注意：表达式索引只支持单表，跨表 JOIN 时仍需两边都有对应表达式索引，否则优化器不敢用。
真正容易被忽略的是：计算列索引或表达式索引，只有在 JOIN 条件**字面完全匹配**时才生效；任何看似微小的差异（空格、排序规则、括号位置）都会让它沉默。
