MySQL 5.0+、PostgreSQL 13+及启用pg_trgm扩展的版本原生支持REVERSE()；SQL Server虽有同名函数但属T-SQL特有，SQLite和Oracle不原生支持，需用递归CTE、自定义函数或应用层处理。
MySQL 和 PostgreSQL 都支持 REVERSE()，但 SQL Server 和 SQLite 不原生支持 —— 直接调用会报错 Invalid function name 'REVERSE' 或类似提示。
哪些数据库能直接用 REVERSE()？
能用的：MySQL 5.0+、PostgreSQL（需 pg_trgm 扩展或 13+ 内置）、MariaDB。
不能用的：SQL Server 要用 REVERSE()（拼写一样但属 T-SQL 特有函数，不是标准 SQL）；SQLite 完全没这个函数；Oracle 用 REVERSE() 是错的，实际要用 UTL_RAW.CAST_TO_VARCHAR2(UTL_RAW.REVERSE(UTL_RAW.CAST_TO_RAW(...))) 这种绕法。
- MySQL 示例：
SELECT REVERSE('hello');→ 返回'olleh' - PostgreSQL 13+ 可直接用：
SELECT REVERSE('world'); - SQL Server 虽然也叫
REVERSE()，但它是 T-SQL 函数，不能在跨数据库兼容 SQL 中混用
SQLite 和 Oracle 怎么安全反转字符串？
SQLite 没内置函数，得靠递归 CTE 或应用层处理。简单场景下可用自定义函数（需启用扩展或用 Python/JS 绑定），但生产环境更推荐在应用代码里反转。
- SQLite 递归 CTE 示例（仅限 3.8.3+）：
WITH RECURSIVE r(s, i) AS ( SELECT 'abc', length('abc') UNION ALL SELECT s || substr('abc', i, 1), i-1 FROM r WHERE i > 1 ) SELECT s FROM r ORDER BY i DESC LIMIT 1;—— 实际不实用，性能差且易出错 - Oracle 推荐用
LISTAGG+ 分析函数拆字再聚合，但比直接调函数慢得多；更稳的方式是查出来后由 Java/Python 处理
REVERSE() 在 WHERE 子句中会影响索引吗？
会。只要字段参与了函数计算，比如 WHERE REVERSE(name) = 'dlrow'，绝大多数数据库无法走 name 字段上的普通 B-tree 索引。
- MySQL 中可建函数索引：
CREATE INDEX idx_rev_name ON t ((REVERSE(name))); - PostgreSQL 需表达式索引：
CREATE INDEX idx_rev_name ON t (REVERSE(name)); - 但 SQL Server 的函数索引要求函数必须是“确定性”的，而
REVERSE()是确定性的，可以建：CREATE INDEX idx_rev_name ON t (REVERSE(name));
真正麻烦的是跨数据库迁移时硬编码了 REVERSE() —— 表面跑得通，换环境就挂。如果业务逻辑真需要反转匹配（比如查倒序邮箱后缀），优先考虑在应用层做，或者统一用正则/子串提取替代。
