如何让SQL中的LEFT和RIGHT函数具备Sargability特性？

核心结论：不是必须用通配符，但要兼顾性能与规则要求 #

T-SQL Lint触发的“非sargable”错误，本质是因为你在WHERE子句的列上直接使用了RIGHT()函数，导致SQL Server无法利用[Name]列上的索引，只能执行全表扫描。这和字符串长短无关——当表数据量达到一定规模时，全表扫描的性能损失会远大于任何“长字符串处理”的开销。

替代方案：既规避Lint错误，又保证性能 #

你有多种选择，不用局限于开头带通配符的LIKE：

1. 反向索引+REVERSE函数（推荐） #

如果需要匹配固定后缀，可以给[Name]列的反向值建索引，把后缀匹配转换成前缀匹配，让SQL Server能利用索引：

-- 创建反向值索引
CREATE INDEX IX_YourTable_Name_Reverse ON YourTable(REVERSE([Name]))

-- 查询写法
WHERE REVERSE(B.[Name]) LIKE REVERSE('-mypostfix') + '%'

这种写法是sargable的，能触发索引查找，Lint也不会报错，性能远优于全表扫描的RIGHT()写法。

2. 持久化计算列+索引 #

如果后缀长度固定（比如这里是10个字符），可以给表添加一个持久化计算列存储后缀，再给该列建索引：

-- 添加持久化计算列
ALTER TABLE YourTable ADD NameSuffix AS RIGHT([Name], 10) PERSISTED

-- 给计算列建索引
CREATE INDEX IX_YourTable_NameSuffix ON YourTable(NameSuffix)

-- 查询写法
WHERE B.NameSuffix = '-mypostfix'

这种写法完全符合sargable要求，Lint会通过，查询时直接利用计算列的索引，性能最优。

3. 忽略Lint错误（仅限小数据量场景） #

如果你的表数据量极小（比如几百行），全表扫描的性能影响可以忽略，你可以直接忽略这个Lint错误。大多数Lint工具支持通过注释忽略特定规则，比如：

-- t-sql-lint-disable: non-sargable-condition
WHERE RIGHT(B.[Name], 10) = '-mypostfix'

关于“RIGHT对长字符串更快”的误区 #

你觉得RIGHT()更快，大概率是在小数据量测试下的错觉。当表有上万甚至几十万行时，索引查找只需要定位符合条件的行，而全表扫描要遍历每一行并计算RIGHT()值——哪怕字符串很长，索引的定位开销也远小于全表遍历的开销。长字符串场景下，索引的优势反而更明显。

内容的提问来源于stack exchange，提问作者Peter Fyffe