SQL Server 2019新字符串函数查询优化技巧

谈及 SQL Server 2019 中的字符串函数，首先需要纠正一个常见误解：该版本并未新增任何字符串函数。CHARINDEX、TRIM、CONCAT_WS 等函数早在 2017 甚至更早的版本中就已存在。影响查询效率的核心因素并非函数的新旧，而是索引策略与执行模式的协同配合——这一点经常被开发者忽略。

CHARINDEX 能否利用索引？不能，但可通过间接方式实现索引加速

直接使用 WHERE CHARINDEX('abc', Column) > 0 会导致全表扫描，原因很明确：函数作用于列上，破坏了索引的有序性。不过，通过持久化计算列可以巧妙绕过这一限制。关键要点包括：

• 必须使用 PERSISTED 关键字将计算结果物理存储，否则无法创建索引。
• 计算列的表达式应保持简单，例如 CHARINDEX('张', CustomerName) 是允许的，但 CHARINDEX(UPPER(@keyword), UPPER(CustomerName)) 则不行——其中混入了变量和函数嵌套，优化器无法处理。
• 过滤索引的谓词需明确指定，比如使用 WHERE CustomerNameContains > 0，不建议写成 >= 1，因为 SQL Server 优化器对 > 0 的识别更为稳定。
• 还需注意一个易错点：如果原列允许 NULL，那么 CHARINDEX 对 NULL 输入会返回 NULL 而非 0，导致计算列值为 NULL，从而整行被过滤索引排除——设计时需提前考虑。

用 TRIM 替换 LTRIM+RTRIM，但避免在 WHERE 子句中直接使用

TRIM 语法比 LTRIM(RTRIM(...)) 更简洁，但若将其放入 WHERE TRIM(Name) = 'John'，同样会导致索引失效——这与 RTRIM(LTRIM(Name)) = 'John' 的危险程度完全一致。正确做法主要有两种：

• 在 ETL 或应用层提前清洗数据后再写入，或者创建计算列 NameClean AS TRIM(Name) PERSISTED，然后对该列建立索引。
• TRIM(' ' FROM Column) 与 TRIM(Column) 行为相同，但显式指定字符可以让你拥有更多控制权——例如，当你只想去除连字符 '-' 时，二者差异就显现出来了。
• 性能方面两者没有本质区别，TRIM 本质上是语法糖，底层调用的依然是相同的字符串处理逻辑。

批模式执行（Batch Mode）或可隐性加速字符串运算

SQL Server 2019 在行存储表上启用了“行存储上的批模式”（Batch Mode on Rowstore），这对涉及字符串函数的大批量过滤查询具有隐性收益。具体而言：

• 当查询包含大表扫描 + CHARINDEX 或 SUBSTRING 时，若满足条件（例如内存充足、统计信息较新，且查询计划选择了批模式），CPU 向量化处理可使字符串查找速度提升 2–5 倍。
• 该模式无需显式启用，但可通过 SELECT * FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) 查看执行计划 XML 中是否包含 BatchMode="on"。
• 注意：批模式不会改变函数语义，也无法修复索引失效问题，它只是让“不得不扫描”的场景运行得更快一些。

归根结底，真正限制性能的从来不是函数名称是否新颖，而是你是否成功将字符串操作从 WHERE 谓词中“剥离”——要么提前物化，要么交由全文索引或列存储处理。函数只是工具，索引与执行模式才是性能的杠杆支点。