SUBSTRING_INDEX在中文字段中返回乱码的根本原因是字符集上下文不匹配：当字段为utf8mb4而会话字符集为latin1或旧utf8时，MySQL错误解码字节导致分隔符定位偏移，进而截取乱码。
SUBSTRING_INDEX 在中文字段里返回乱码，不是函数本身有 bug，而是它被放在了错误的字符集上下文中运行。
确认当前会话字符集是否匹配 utf8mb4
乱码最常见源头是 character_set_client、character_set_connection 和 character_set_results 三者不一致，且其中至少一个为 latin1 或旧版 utf8（即最多 3 字节的伪 UTF-8）。这种情况下，MySQL 会把一个 utf8mb4 中文字符（如“订”，占 3 字节）误拆成多个单字节单位处理，导致分隔符定位偏移。
执行这条命令验证：
SHOW VARIABLES LIKE 'character_set_%';
重点关注这三项值是否都为 utf8mb4。如果不是：
- 连接时加参数：JDBC 用
?useUnicode=true&characterEncoding=utf8mb4；PHP PDO 加PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4" - 临时修复：在查询前手动执行
SET NAMES utf8mb4; - 永久修复：修改 MySQL 配置文件
my.cnf的[client]和[mysqld]段，加入default-character-set = utf8mb4和collation-server = utf8mb4_unicode_ci
SUBSTRING_INDEX 处理中文分隔符时必须显式转换字段
即使表定义了 CHARACTER SET utf8mb4，SUBSTRING_INDEX 仍按当前会话字符集解析字符串长度和分隔符位置。中文分隔符（如“/”、“-”、“｜”）在 latin1 会话中会被当成单字节处理，而实际占 3 字节，造成截断点错位。
错误写法（会话为 latin1 时）：
SELECT SUBSTRING_INDEX('订单-2024-05-01', '-', 2);安全写法（强制字段以 utf8mb4 解析）：
SUBSTRING_INDEX(CONVERT(your_column USING utf8mb4), '-', 2)SUBSTRING_INDEX(CAST(your_column AS CHAR CHARACTER SET utf8mb4), '/', -1)- 若字段可能为空或 NULL，建议先用
IFNULL包裹，避免 CONVERT 返回 NULL 导致整行失效
提取中文路径末段时的典型失败现象
比如字段存着 http://example.com/用户中心/订单管理，想用 SUBSTRING_INDEX(url, '/', -1) 取出“订单管理”，结果却是“单管理”或空值——这是因斜杠位置被算在某个中文字符中间字节上。
验证是否已发生字节错位：
SELECT LENGTH('用户中心'), CHAR_LENGTH('用户中心');若前者是 12、后者是 4，说明是 utf8mb4 编码；若两者都是 4，可能是旧 utf8（不支持 emoji），但对常用中文也够用；若前者是 4、后者也是 4，那大概率是 latin1 上下文在骗你。
此时不能只靠 SET NAMES，必须字段级兜底：
- 用
CONVERT(col USING utf8mb4)强制重编码再切 - 避免用
SUBSTRING_INDEX处理含 emoji 或混合符号的路径（如?/用户中心/✅订单），改用应用层解析更可靠
当 SUBSTRING_INDEX 不可靠时，替代方案怎么选
如果字段含 emoji、中英文混排、第三方 ETL 工具直连无法控制客户端字符集，SUBSTRING_INDEX 就容易失效——它本质是字节偏移计算，不是语义切分。
可考虑：
- 应用层处理：Python 用
str.rsplit('/', 1)[-1]，Java 用url.substring(url.lastIndexOf('/') + 1)，完全绕过 MySQL 字符集陷阱 - MySQL 8.0+ 可用正则：
REGEXP_SUBSTR(url, '[^/]+$')，但需确保collation是 utf8mb4 相关，否则正则仍会错位 - 预处理字段：建触发器或 ETL 步骤，在入库时就把路径末段单独存为新列，避免每次查询都现场切
真正棘手的不是函数不会用，而是你以为它在按“字符”切，其实它在按“字节”跳——而中文字符的字节数，取决于你此刻坐在哪个字符集的椅子上。
