REVERSE+CHARINDEX可行是因为将路径反转后，末尾分隔符变为首个可定位目标，从而精准提取文件名；核心是三步：RTRIM去空格→REVERSE翻转→CHARINDEX找首分隔符位置再计算起始点。
SQL里用REVERSE + CHARINDEX提取文件名为什么可行
因为Windows路径（如 C:UsersAlice
eport.xlsx）和类Unix路径（如 /home/bob/data/log.csv）都以斜杠结尾文件名，而CHARINDEX只能从左往右找第一个分隔符；把字符串翻转后，最后一个或/就变成第一个，再用CHARINDEX定位，就能精准切出文件名。
实际写法：先翻转、再找位置、最后截取
核心逻辑是三步：翻转路径 → 找第一个反斜杠/斜杠位置 → 从末尾往前取对应长度。注意不同数据库对字符串函数的兼容性差异：
- SQL Server 支持
REVERSE和CHARINDEX，且SUBSTRING索引从1开始 - PostgreSQL / MySQL 不直接支持
REVERSE（MySQL 8.0+ 有，但旧版需绕行），得换方案 - 路径末尾带
/或（比如目录路径）会导致结果为空，必须先RTRIM
SQL Server 示例（处理 C: empconfig.json）：
SELECT
SUBSTRING(
path,
LEN(path) - CHARINDEX('', REVERSE(RTRIM(path))) + 2,
LEN(path)
) AS filename
FROM (VALUES ('C: empconfig.json')) t(path);说明：REVERSE(RTRIM(path))确保无尾随空格干扰；CHARINDEX('', ...)返回翻转后第一个的位置（比如nojs.gnifocmpt:C中在第9位）；LEN - pos + 2算出原始串中文件名起始位置。
跨平台路径（含/和
不能只认，否则Linux路径失效；也不能简单REPLACE(path, '/', '')，因为可能混用（如网络路径 \server/share/file.txt）。稳妥做法是分别检查两种分隔符，取更靠后的位置：
SELECT
SUBSTRING(
path,
CASE
WHEN CHARINDEX('', REVERSE(RTRIM(path))) > 0
THEN LEN(path) - CHARINDEX('', REVERSE(RTRIM(path))) + 2
WHEN CHARINDEX('/', REVERSE(RTRIM(path))) > 0
THEN LEN(path) - CHARINDEX('/', REVERSE(RTRIM(path))) + 2
ELSE 1
END,
LEN(path)
) AS filename
FROM (VALUES ('/var/log/app.log'), ('C:Windowssystem.ini')) t(path);关键点：REVERSE(RTRIM(path))必须加，否则空格会让CHARINDEX返回0，导致SUBSTRING越界报错；ELSE 1兜底防全无分隔符（如README.md）。
比REVERSE+CHARINDEX更稳的替代方案有哪些
这个组合看着巧妙，但实际容易崩在边界情况：路径只有分隔符（C:）、空值、纯文件名、多级UNC路径（\hostsharepath o ile.txt）。生产环境建议：
- SQL Server 2016+ 优先用
STRING_SPLIT+ORDER BY+TOP 1，逻辑清晰不易错 - 如果必须兼容老版本，把
REVERSE+CHARINDEX封装成函数，并加ISNULL和NULLIF防空 - 真正复杂的路径解析（如带查询参数的URL式路径）别硬刚SQL，交给应用层处理
最常被忽略的是路径标准化——数据库里存的路径可能混着\、/、./甚至%20，光靠字符串函数切不干净。先清洗再提取，比补丁式修正更省事。
