MySQL 中 SUBSTRING 截取中文乱码？本质是字节 vs 字符混淆
核心问题在于：SUBSTRING 函数默认按字节进行截取。在 utf8mb4 编码下，一个中文字符通常占用 3 到 4 个字节。若错误地使用返回字节数的 LENGTH() 函数来配合 SUBSTRING 操作，极易截取到半个汉字，从而产生乱码。正确的解决方案是使用 CHARACTER_LENGTH() 函数，它返回的是我们直观可见的字符数，能确保精准定位到“第几个字”。
SUBSTRING(str, pos, len) 的 pos 和 len 都按字符位置算
需要明确一个关键点：SUBSTRING 函数本身不区分编码，其参数 pos（起始位置）和 len（长度）在定义上就是基于“字符数”计算的。但前提是，你传递给它的数值必须是字符数，而非字节数。
- 典型的错误写法：
SUBSTRING(name, LENGTH(LEFT(name, 2)), 1)。此代码试图先用LEFT取前2个字节，再用LENGTH()计算其字节长度作为起始位。风险在于，LEFT(name, 2)取出的2个字节可能只是一个汉字的一部分，导致后续计算完全偏离预期。 - 正确的做法：直接使用字符数。例如，
SUBSTRING(name, 1, 2)就是截取前2个字符，简单直接。若需动态计算，例如截取最后2个字符，可写作：SUBSTRING(name, CHARACTER_LENGTH(name) - 2 + 1, 2)。 - 额外注意：在
utf8mb4的排序规则（如utf8mb4_0900_as_cs）下，SUBSTRING的行为是稳定可靠的。但如果使用的是旧版的utf8（实为 utf8mb3），处理四字节的 Emoji 表情时仍可能出错。
CHARACTER_LENGTH() 不是万能补丁，得看字段实际编码
使用 CHARACTER_LENGTH() 就能一劳永逸吗？并非如此。该函数返回的是 Unicode 字符的个数，但其准确性依赖于字段本身声明的字符集。设想一个场景：一个字段被定义为 latin1 字符集，但实际存储的却是 UTF-8 编码的中文。此时，CHARACTER_LENGTH() 可能会将一个汉字错误地计为3个字符。这并非函数缺陷，而是数据存储层出现了编码不匹配。
- 第一步，检查字段的真实字符集：执行
SHOW FULL COLUMNS FROM table_name LIKE 'column_name';，重点关注Collation列，确保其指向utf8mb4_*系列的排序规则。 - 临时转换的权宜之计：若暂时无法修改表结构，可在查询时进行编码转换：
SUBSTRING(CONVERT(column_name USING utf8mb4), 1, 5)。但此方法存在性能开销，不建议在数据量大的表或 WHERE 条件中频繁使用。 - 更简洁的替代方案：对于简单的截取操作，
LEFT(column_name, 5)与SUBSTRING(column_name, 1, 5)效果完全相同，前者书写更简洁。RIGHT()函数同理。
遇到 SUBSTRING 返回空或问号？先查连接层编码
有时，即使 SQL 语句逻辑无误，执行结果仍可能出现乱码、空字符串或问号。这通常源于数据库连接层的编码问题。如果客户端连接使用的是 latin1 编码，或未正确设置 SET NAMES utf8mb4，那么 SUBSTRING 函数接收到的可能已是一个被损坏的字符串，后续任何字符数计算都将失效。
- 连接时指定编码：在命令行连接时，可添加参数：
mysql --default-character-set=utf8mb4 -u user -p。 - 执行前校验编码设置：运行查询
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;，确保这三个系统变量的值均为utf8mb4。 - 一个常见的错误现象：执行
SUBSTRING('你好世界', 1, 2)却返回空值或乱码。这大概率是客户端解码失败所致，而非函数本身功能失效。
归根结底，真正的挑战往往不在于函数语法本身，而在于确保字符集声明、连接参数与实际字段存储三者之间的一致性。只要其中任何一层未能对齐，缺少了关键的 mb4 支持，那么之前所有基于 CHARACTER_LENGTH() 的精心计算都可能前功尽弃。
