MySQL的SUBSTRING按字节截取，非字符；utf8mb4下中文占3-4字节，直接用SUBSTRING(name,1,2)易截断汉字；应改用CHARACTER_LENGTH和CONVERT等确保字符级操作。
SUBSTRING 默认按字节截取，不是按字符
MySQL 的 SUBSTRING 函数本身不感知字符编码，它只认“字节位置”。在 utf8mb4 下，一个中文占 3 或 4 字节，SUBSTRING(name, 1, 2) 就是取前 2 个字节——大概率卡在某个汉字中间，结果就是半个字、显示为 或空格。
这不是函数写错了，而是你传进去的 len 值（比如 2）被当成了字节数，但你想表达的是“2 个汉字”。
- 用
LENGTH('你好')返回 6（utf8mb4 下 2 个汉字 × 3 字节） - 用
CHARACTER_LENGTH('你好')返回 2（这才是人眼看到的“2 个字”） -
SUBSTRING的pos和len参数，语义上是“第几个字符、取几个字符”，但前提是：你给它的值得基于字符数，而不是字节数
连接层编码错配会让问题更隐蔽
即使字段定义是 utf8mb4，只要客户端连进来时没声明字符集，MySQL 就会用默认的 latin1 解析整个字符串——这时 SUBSTRING 拿到的输入本身就是损坏的，再怎么算字符数都白搭。
验证当前会话编码：SELECT @@character_set_client, @@character_set_connection, @@character_set_results;，三个都得是 utf8mb4。
- 命令行连接加参数：
mysql --default-character-set=utf8mb4 -u user -p - JDBC URL 加：
?charset=utf8mb4 - 查询前执行：
SET NAMES utf8mb4; - 临时兜底写法：
SUBSTRING(CONVERT(column_name USING utf8mb4), 1, 5)（别在大表WHERE里用）
SQL Server 和 MySQL 的行为根本不同
SQL Server 的 SUBSTRING 天然按字符计数，中文、英文、数字都算 1，SUBSTRING(name, 1, 4) 就是稳稳前 4 个汉字。但前提是字段类型别用过时的 text——它会按字节解析，导致乱码；必须改成 ntext 或 nvarchar。
- 别用
LEN()算长度前，先RTRIM(LTRIM(name))清空格，否则位置偏移 -
LEFT(name, 3)比SUBSTRING(name, 1, 3)更安全：字段只有 1 个字也不报错，返回实际内容 - 全角/半角符号要分开处理：
CHARINDEX('：', col)和CHARINDEX(':', col)是两回事
Impala 和 PHP 的 substr 都踩同一类坑
Impala 原生 substr()、PHP 的 substr() 默认都是字节级操作。UTF-8 中文被切成一半，必然乱码。
PHP 必须换 mb_substr($str, 0, 2, 'UTF-8')，且确保输入字符串确实是 UTF-8 编码（可用 mb_detect_encoding() 检查）；Impala 则得写 Java UDF，按 Unicode 码点切，不能碰字节。
- Java 的
String.substring()是安全的——它操作的是 char（UTF-16 code unit），对常用汉字没问题 - 但
new String(str.getBytes("UTF-8"), 0, 10)这种字节截取，一定出错 - 数据库外清洗时，别依赖
substr做中文截断，优先用语言层的多字节安全函数
真正麻烦的不是函数不会用，而是你以为你在切“字符”，其实数据库或驱动正在悄悄按“字节”喂给你数据。编码声明漏一处，后面所有截取逻辑都会漂移。
