不能直接高效实现“逆向查找”。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，索引就失效。
多数时候，“逆向查找”只是需求表述偏差；先确认是否真要查反转结果，还是只是想查后缀、回文、或模糊模式——后者往往有更稳更快的正向解法。
