根本原因是字符集上下文不匹配：当字段为utf8mb4中文而会话字符集为latin1或旧utf8时，mysql错误解码字节导致分隔符定位偏移，substring_index据此截取必然乱码。
为什么SUBSTRING_INDEX在中文字段里返回乱码
根本原因不是SUBSTRING_INDEX本身出错，而是它底层依赖的字符集上下文不匹配。当字段实际存储的是utf8mb4编码的中文，但连接会话的character_set_client或character_set_results被设为latin1或旧版utf8时，MySQL会在解析分隔符（如.、/）前先做一次错误的字节解码——导致字符串“看起来”被截断在错误位置，后续再用SUBSTRING_INDEX切，结果自然乱码。
SUBSTRING_INDEX + 中文分隔符必须显式指定字符集
即使表字段定义了CHARACTER SET utf8mb4，SUBSTRING_INDEX仍按当前会话的字符集理解字符串长度和分隔符位置。中文分隔符（比如“/”、“-”、“｜”）若混在latin1会话中，会被当成单字节处理，而实际占3字节，造成偏移错位。
- 错误写法：
SUBSTRING_INDEX('订单-2024-05-01', '-', 2)→ 在latin1会话中可能只识别第一个“-”，但因字节错位，返回结果含乱码 - 安全写法：先确保会话字符集正确，再执行
SET NAMES utf8mb4;SELECT SUBSTRING_INDEX(CAST('订单-2024-05-01' AS CHAR CHARACTER SET utf8mb4), '-', 2); - 更稳妥的做法是把字段本身转成明确字符集：
SUBSTRING_INDEX(CONVERT(your_column USING utf8mb4), '-', 2)
用SUBSTRING_INDEX提取中文路径或URL时的典型陷阱
常见于日志表存有http://example.com/用户中心/订单管理这类路径，想用SUBSTRING_INDEX(url, '/', -1)取末段“订单管理”，却得到“单管理”或空值。
- 问题根源：路径字段虽定义为
utf8mb4，但客户端连接未声明字符集，MySQL用character_set_connection默认值（常为latin1）解析斜杠位置，导致从右数第1个“/”落在某个中文字符中间字节上 - 验证方法：
SELECT LENGTH('用户中心'), CHAR_LENGTH('用户中心');—— 若前者是6、后者是4，说明是utf8mb4；若两者相等且为4，可能是utf8（不支持emoji），但已足够支持常用中文 - 修复步骤：
① 连接时加参数：?charset=utf8mb4（JDBC/PHP/PDO均适用）
② 查询前执行：SET NAMES utf8mb4;
③ 字段级兜底：SUBSTRING_INDEX(CONVERT(path_col USING utf8mb4), '/', -1)
替代方案：SUBSTRING_INDEX不可靠时该用什么
当字段混合中英文+emoji+符号，且无法控制客户端字符集（如第三方ETL工具直连），SUBSTRING_INDEX极易失效。此时应放弃“按分隔符计数”，改用基于字符位置的函数组合。
- 用
LOCATE定位最后一个分隔符（需两次调用）：SELECT SUBSTRING(your_col, LOCATE('/', your_col, LOCATE('/', your_col) + 1) + 1);—— 但依然依赖字符集正确 - 真正健壮的做法：在应用层处理。MySQL的字符串函数本质是字节操作，对多字节字符无原生“字符感知”。把原始字符串
SELECT出来，在Python/Java里用str.rsplit('/', 1)[-1]或String.substring()处理，完全避开MySQL字符集链路 - 如果必须在SQL内解决，且确认字段是
utf8mb4，可用SUBSTRING_INDEX配合CONVERT ... USING utf8mb4包裹整个字段，而不是只包裹分隔符
最常被忽略的一点：SUBSTRING_INDEX的第三个参数是“出现次数”，不是“字符位置”，它不会校验分隔符是否落在合法字符边界上——这个责任始终在你设置的字符集一致性上。
