# 计算列索引：SQL Server 中如何利用持久化技巧加速 JOIN 关联 必须显式标记为 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"`。若发现索引未被使用，请逐一排查以下三个因素： 1. **JOIN 条件是否严格匹配该计算列**？例如，你创建了 `name_lower AS LOWER(name)`，但条件中却写成了 `UPPER(a.name)`，自然无法匹配。 2. **检查关联字段是否存在隐式类型转换**：例如 `a.name_upper` 为 `varchar(50)`，而 `b.name_upper` 为 `nvarchar(50)`——类型不同导致的转换会使索引失效。 3. **统计信息是否过时**：使用 `DBCC SHOW_STATISTICS('table', 'ix_name_upper')` 查看 `modification_counter`。若修改行数超过总行数的 20%，应立即执行 `UPDATE STATISTICS table WITH FULLSCAN` 刷新统计信息。 --- ### 比计算列更轻量的替代方法 若仅希望绕过函数导致的索引失效，可优先考虑表达式索引（SQL Server 2016 及以上版本支持）。例如： ```sql CREATE INDEX ix_a_name_upper ON a (UPPER(name)); ``` 这种方法无需修改表结构，也不占用额外存储，效果与 `PERSISTED` 计算列加索引几乎相同，且维护成本更低。但需注意：表达式索引仅支持单表，在跨表 JOIN 时，要求关联双方都有对应的表达式索引，否则优化器将无法使用。 真正容易忽视的一点是：计算列索引或表达式索引，仅在 JOIN 条件**字面完全一致**时才会生效。任何细微差异——例如空格、排序规则、括号位置——都会导致索引无法被使用。调试时务必留意这一点。