sql server 的 reverse 函数是原生字符串逆序函数,支持 varchar/nvarchar 等类型,但不兼容 text/ntext;需注意 null 处理、unicode 代理项对、索引失效风险及与其它函数组合时的空格和执行顺序问题。

SQL Server 的 REVERSE 函数能直接、可靠地实现字符串逆序,无需自定义逻辑或递归 CTE —— 它是原生函数,不是模拟方案。
REVERSE 函数的基本用法和参数限制
REVERSE 接收一个字符串表达式(string_expression),返回其字符顺序完全颠倒的新字符串。它支持 varchar、nvarchar、char、nchar,也接受可隐式转为 varchar 的类型(比如 int 会自动转成字符串再反转)。
常见错误现象:REVERSE(1234) 返回 '4321' 没问题,但 REVERSE(NULL) 直接返回 NULL,不是空字符串;若字段允许 NULL,记得加 IS NOT NULL 判断,否则后续拼接或比较可能意外中断。
- 不能直接传
text或ntext(已弃用,且不兼容),需先CAST成varchar(max) - 传入
binary类型时,按字节反转,不是按字符——慎用于含 Unicode 的二进制字段 - 对变量使用时,确保变量长度足够:比如
DECLARE @s VARCHAR(5); SET @s = 'hello'; SELECT REVERSE(@s);没问题;但若@s定义为VARCHAR(3),存入'abc'后反转仍是'cba',而截断风险在赋值阶段就发生了
处理 Unicode 和代理项对(Surrogate Pairs)的坑
SQL Server 默认按字符反转,但遇到 UTF-16 中的代理项对(如某些 emoji 或古汉字),结果取决于排序规则(collation)。如果用了带 _SC 后缀的排序规则(例如 Latin1_General_100_CI_AS_SC),REVERSE 会把代理项的高低两个码位当成独立字符处理,导致反转后无法还原成合法 Unicode 字符。
实操建议:
- 查当前列排序规则:
SELECT collation_name FROM sys.columns WHERE object_id = OBJECT_ID('YourTable') AND name = 'YourColumn'; - 若必须处理含 emoji 的字段,优先用
nvarchar+ 非_SC排序规则(如Latin1_General_100_CI_AS);_SC规则虽支持完整 Unicode,但牺牲了REVERSE的语义正确性 - 测试关键数据:
SELECT REVERSE(N'??'), LEN(N'??'), DATALENGTH(N'??');—— 若返回乱码或长度异常,说明代理项被拆开了
在 WHERE 条件中用 REVERSE 做后缀匹配?别这么干
写 WHERE REVERSE(name) LIKE 'zyx%' 查“以 xyz 结尾的名字”,逻辑没错,但性能灾难:数据库无法使用 name 列上的常规 B-tree 索引,每次都要全表扫描并计算每个值的反转结果。
更现实的替代方案:
- 改写为
WHERE name LIKE '%xyz'—— 虽然也是索引失效,但至少避免了函数调用开销,部分版本优化器还能做前缀剪枝 - 真要高频查后缀,建计算列 + 索引:
ALTER TABLE users ADD name_reversed AS REVERSE(name) PERSISTED;,然后CREATE INDEX IX_users_name_reversed ON users(name_reversed); - 注意:
PERSISTED是必须的,否则无法在计算列上建索引;且该列会占用额外存储空间
和其它函数组合使用的边界情况
REVERSE 经常和 LEFT、RIGHT、LEN 连用,比如提取倒数第 N 个字符:RIGHT(REVERSE(name), 1)。但要注意嵌套层级带来的隐式转换和空格问题。
典型陷阱:
-
REVERSE('abc ')→' cba'(末尾空格跑到开头),如果原始字段是char(10),那反转后前面会堆满空格,LEN()仍返回 10,但DATALENGTH()才反映真实字节数 - 和
UPPER/LOWER组合时,大小写转换发生在反转之后:UPPER(REVERSE('Hello'))→'OLLEH',不是'OLLEh';顺序不能颠倒 - 对含换行符或制表符的字符串反转,这些控制字符也会被翻到前面,导出或展示时可能引发格式错乱
Unicode 多字节字符本身不是问题,但排序规则、字段定义、是否 PERSISTED、以及 WHERE 中滥用——这四点最容易在线上环境突然暴露,而且往往在数据量变大后才被发现。










