REVERSE函数本身不直接匹配后缀，而是将后缀匹配转化为前缀匹配以利用索引：如查以.log结尾的文件名，需用REVERSE(filename) LIKE 'gol.%'，并配合函数索引才能提速，否则仍全表扫描。
REVERSE函数在后缀匹配中的真实作用
SQL里的REVERSE本身不直接匹配后缀，但它能把字符串倒过来，把“后缀问题”转化成“前缀问题”——而前缀匹配（比如用LIKE 'abc%'或STARTS WITH）是数据库原生高效支持的。这是它唯一靠谱的排查逻辑，别指望它自己“识别后缀”。
MySQL/PostgreSQL中用REVERSE+LIKE查相同后缀
比如想找出所有以.log结尾的文件名，直接WHERE name LIKE '%.log'能用，但没法走索引；换成倒序后，.log变成gol.，就可以用前缀索引：
SELECT * FROM logs WHERE REVERSE(filename) LIKE 'gol.%';
注意三点：
-
REVERSE结果无法利用原始字段的索引，除非你提前建函数索引（PostgreSQL支持CREATE INDEX ON t ((REVERSE(col)))，MySQL 8.0+也支持） - 不同数据库对
REVERSE的NULL处理一致：输入NULL，输出NULL，所以WHERE REVERSE(col) IS NOT NULL才能过滤掉空值 - 大小写敏感性取决于字段collation，
REVERSE('Log')仍是goL，不会自动转小写
SQL Server里没有REVERSE？其实有，但要注意LEN和DATALENGTH差异
SQL Server确实有REVERSE函数，但常见坑是误用LEN计算长度来截取后缀——LEN会忽略末尾空格，而DATALENGTH不会。比如LEN('abc ') = 3，但DATALENGTH('abc ') = 6（假设是varchar）。若你用RIGHT(col, 4)查.log，而字段末尾带空格，就可能漏数据。
更稳的做法仍是倒序+前缀：
SELECT * FROM app_logs WHERE REVERSE(log_path) LIKE 'gol.%';
只要确保log_path类型是varchar或nvarchar，REVERSE就能正确处理Unicode。
真正容易被忽略的边界情况
用REVERSE辅助排查时，最常栽在三个地方：
- 字段含NULL或空字符串：
REVERSE('')返回空串，REVERSE(NULL)返回NULL，二者在WHERE里都不会命中LIKE条件，需显式加AND col IS NOT NULL AND col != '' - 多字节字符（如中文、emoji）：MySQL 5.7+和PostgreSQL默认按字符反转，不是按字节，这点放心；但旧版MySQL用
utf8（非utf8mb4）时，emoji会被截断，REVERSE结果就错 - 性能预期错位：哪怕建了函数索引，
REVERSE(col) LIKE 'x%'的查询计划仍可能不如原生ENDS WITH（如果数据库支持），比如SQL Server 2022+已支持STRING_AGG和ENDS WITH语法，这时硬套REVERSE反而多此一举
实际排查时，先确认数据库版本是否原生支持后缀操作符，再决定要不要绕路用REVERSE。
