REVERSE函数在MySQL、SQL Server和PostgreSQL 13+中内置支持,Oracle和SQLite需自定义;用于路径处理易混淆字符级反转与层级反转,提取扩展名时性能较差且需空值防护,SQL Server中还须注意Unicode排序规则与数据类型限制。
REVERSE 不是 SQL 标准函数,各数据库支持情况不一:MySQL、SQL Server、PostgreSQL(从 13 开始)原生支持;Oracle 和 SQLite 默认不提供,需用自定义函数或递归 CTE 模拟。如果你执行 SELECT REVERSE('abc'); 报错 function does not exist 或 invalid identifier,先查文档确认当前数据库版本是否内置该函数。
NULL 输入返回 NULL,不报错 CREATE FUNCTION reverse_text,否则会提示 function reverse(unknown) does not exist REVERSE,常用 UTL_RAW.CAST_TO_VARCHAR2(UTL_RAW.REVERSE(UTL_RAW.CAST_TO_RAW('abc'))),但仅限单字节字符,中文会乱码 “镜像路径”常指把类似 /a/b/c 变成 c/b/a/(即逐级翻转),但直接套用 REVERSE('/a/b/c') 得到的是 'c/b/a/' —— 看似正确,实则只是字符级反转,无法区分路径层级。一旦路径含带点文件名(如 /home/user/report.v1.json),REVERSE 输出 sonj.1v.troper/resu/emoh/,完全失去语义。
SELECT REVERSE(path) FROM files; → 仅适合纯倒序展示,不适合路径解析 / 分割,再反转数组顺序,最后拼接 —— 这需要 STRING_SPLIT(SQL Server)、REGEXP_SPLIT_TO_ARRAY(PostgreSQL)或 JSON_TABLE(MySQL 8.0.4+)配合 REVERSE 做中间步骤 SUBSTRING_INDEX(MySQL)或 PARSENAME(SQL Server),比依赖 REVERSE 更可靠 虽然 SUBSTRING_INDEX 更直接,但有人用 REVERSE + LOCATE 截取扩展名,逻辑是:反转字符串 → 找第一个 . 的位置 → 截取 → 再反转回来。例如:
SELECT REVERSE(SUBSTRING(REVERSE(filename), 1, LOCATE('.', REVERSE(filename)) - 1)) AS extFROM filesWHERE filename LIKE '%.%';
filename 为空或不含 . 时,LOCATE 返回 0,导致 SUBSTRING(..., 1, -1) 返回空字符串,不报错但结果异常 CASE WHEN LOCATE('.', REVERSE(filename)) > 0 THEN ... ELSE NULL END REVERSE + 一次 LOCATE 比单次 SUBSTRING_INDEX(filename, '.', -1) 多约 20% CPU 开销(实测 10 万行数据) 在 SQL Server 中,REVERSE(N'café') 返回 N'éfác',看起来正常;但若列使用了拉丁文排序规则(如 SQL_Latin1_General_CP1_CI_AS),而字符串含组合字符(如带重音的 é),REVERSE 可能拆开基础字符与修饰符,造成显示错位。
REVERSE 后出现乱序或问号 NVARCHAR,且连接字符串时显式用 N'xxx' 前缀 REVERSE 对 TEXT 类型不支持(已弃用),必须先 CAST(col AS NVARCHAR(MAX)),否则报错 Argument data type text is invalid for argument 1 of reverse function 实际中,真正需要“镜像路径”的场景极少,多数时候是误把“路径层级反转”理解成了“字符串反转”。REVERSE 是个简单函数,但一旦脱离纯文本倒序,就很快撞上分隔符处理、编码边界、数据库兼容性这三堵墙。