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