REVERSE + CHARINDEX 能找最后一个字符是因为翻转后末位变首位，将“末位查找”降维为“首位查找”，再通过 LEN(@str) - CHARINDEX('\', REVERSE(@str)) + 1 换算回原位置，需判空处理且注意1-based索引。
REVERSE + CHARINDEX 为什么能找最后一个字符
直接用 CHARINDEX 只能从左往右找第一次出现的位置，没法定位“最后一个”。但把字符串翻转后，最后一个匹配字符就变成了第一个——这时候再用 CHARINDEX 找，结果就是翻转后的“第一个位置”，再换算回原字符串索引即可。关键在于：翻转不是目的，是把“末位查找”降维成“首位查找”。
计算原始字符串中最后一个匹配字符的正确位置
假设要找字符串 @str 中最后一个 '\' 的位置（比如路径截取场景），不能直接 LEN(@str) - CHARINDEX('\', REVERSE(@str)) + 1 —— 这会错一位。因为 CHARINDEX 返回的是从 1 开始的偏移量，而翻转后原末尾字符变成位置 1，所以正确公式是：
LEN(@str) - CHARINDEX('\', REVERSE(@str)) + 1
但要注意边界：如果没找到，CHARINDEX 返回 0，此时结果会变成 LEN(@str) + 1，逻辑错误。实际使用必须加判断：
- 先用
CHARINDEX('\', REVERSE(@str))检查是否为 0 - 只在非 0 时才代入公式，否则返回 0 或 NULL
- SQL Server 中可结合
NULLIF和ISNULL避免无效计算
常见错误：空格、大小写和多字符陷阱
REVERSE 对空格敏感，如果原字符串末尾有空格，REVERSE 会把它们移到开头，可能干扰 CHARINDEX 结果。例如 'abc\ '（末尾带空格）翻转后是 ' \cba'，CHARINDEX('\', ...) 仍能命中，但若匹配的是字母或数字，就容易漏判。
-
REVERSE不处理大小写，CHARINDEX('A', REVERSE(@str))不等于CHARINDEX('a', ...) -
CHARINDEX不支持通配符，不能用'%a%'，只能查固定子串；想查“最后一个数字”，得先用其他方式提取 - 多字符搜索（如
'.txt'）可用，但REVERSE后也要反转搜索串：CHARINDEX('.txt', REVERSE(@str))❌，应写成CHARINDEX('txt.', REVERSE(@str))✅
替代方案比一比：PATINDEX 和 RIGHT + CHARINDEX
如果只是找最后一个分隔符，PATINDEX('%\%', REVERSE(@str)) 并不更好——它仍然返回翻转后的位置，换算逻辑一样，且性能略差。有人用 RIGHT(@str, 1) 配合循环，但 SQL Server 不支持原生字符串循环，硬写会变标量函数，严重拖慢集合操作。
真正值得考虑的是 STRING_SPLIT（SQL Server 2016+）配合 ORDER BY value DESC OFFSET 0 ROWS FETCH NEXT 1 ROWS ONLY，但仅适用于分隔符明确、需拆分的场景；对单字符定位，REVERSE + CHARINDEX 仍是轻量、可靠、兼容性最好的选择。
别忘了：所有位置计算都基于 1-based 索引，任何减法漏了 +1 或 -1，结果就会偏一格——这是最常被忽略的细节。
