如何运用SQL Server 2019中的新字符串函数优化查询？

SQL Server 2019未新增字符串函数，性能关键在于索引策略与批模式执行；CHARINDEX、TRIM等函数直接用于WHERE会致索引失效，需通过持久化计算列或ETL清洗配合索引优化，批模式可隐式加速大表字符串运算。

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 在语法上更简洁，但把它放进 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 谓词里“摘出来”——要么提前物化，要么交给全文索引或列存储处理。函数只是工具，索引和执行模式才是杠杆支点。