不能直接高效实现“逆向查找”。REVERSE函数在WHERE子句中使用（如WHERE REVERSE(name) LIKE '%xyz'）会导致全表扫描，因普通索引无法生效；需建函数索引或改用正向匹配（如WHERE name LIKE '%def'）才可兼顾语义与性能。

REVERSE函数在WHERE子句中能直接用于逆向匹配吗

不能直接高效实现“逆向查找”。REVERSE 是字符串函数，它把输入字符串倒过来，比如 REVERSE('abc') 返回 'cba'。但如果你写 WHERE REVERSE(column) LIKE '%xyz'，数据库无法利用索引（除非你建了函数索引），实际是全表扫描+逐行计算，数据量一大就明显变慢。

想查“以某个逆序串结尾”的字段，该怎么写

本质是查“原字段以某串的逆序开头”，比如想找以 'def' 结尾的记录，等价于：原字段反转后以 'fed' 开头。这时用 LIKE 配合前缀更合理：

• 错误写法：WHERE REVERSE(name) LIKE '%fed'（后缀匹配，仍要扫描全部）
• 正确思路：WHERE REVERSE(name) LIKE 'fed%'（前缀匹配，部分引擎可走索引，若已建函数索引）
• 更通用且免函数索引的写法：WHERE name LIKE '%def' —— 直接正向表达意图，语义清晰，也方便加普通索引（虽然 LIKE '%xxx' 仍无法用索引，但至少不额外增加计算开销）

MySQL / PostgreSQL / SQL Server 对 REVERSE 的支持差异

各主流数据库都支持 REVERSE，但行为细节不同：

• MySQL 8.0+ 和 SQL Server 支持 REVERSE()，对 NULL 安全（返回 NULL）；MySQL 5.7 也支持，但注意它对多字节字符（如中文）按字节反转，可能出乱码
• PostgreSQL 没有内置 REVERSE，需用 string_to_array + array_reverse + array_to_string 组合，或自定义函数；简单场景建议用 SELECT substring(column, length(column) - n + 1) 手动截取替代
• SQLite 不支持 REVERSE，必须用 substr(column, -n) 或扩展加载自定义函数

真正需要逆向扫描时，函数索引怎么建

只有当你频繁执行类似 WHERE REVERSE(phone) LIKE '123%' 这类查询，且数据量大、性能瓶颈明显，才值得建函数索引。建法因库而异：

• PostgreSQL：CREATE INDEX idx_rev_phone ON users ((REVERSE(phone)));
• MySQL 8.0+：CREATE INDEX idx_rev_phone ON users (REVERSE(phone));（需开启 innodb_functional_index=ON）
• SQL Server：CREATE INDEX idx_rev_phone ON users (REVERSE(phone));（支持，但注意统计信息更新频率）

注意：函数索引会增大存储、拖慢 INSERT/UPDATE，而且只对完全匹配该函数表达式的查询生效——换一个参数、多一层 TRIM 或改用 = 而非 LIKE，索引就失效。

多数时候，“逆向查找”只是需求表述偏差；先确认是否真要查反转结果，还是只是想查后缀、回文、或模糊模式——后者往往有更稳更快的正向解法。