mysql怎么用函数实现多字节字符的截取_使用SUBSTRING与CHARACTER_LENGTH

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() 的精心计算都可能前功尽弃。