MySQL中字符串截取需警惕变量长度不足与字符集错位：VARCHAR(n)按字符数声明但UTF8mb4下中文/emoji占4字节，应按最大字节数预留空间，并用CHAR_LENGTH()而非LENGTH()判断长度，避免静默截断。
直接在存储过程中用 SUBSTRING() 或 LEFT() 硬截，大概率会触发 ORA-06502（Oracle）或静默丢数据（SQL Server），但在 MySQL 里更常表现为：调用失败、返回空、或字段被意外截断却不报错——根本原因不是函数写错了，而是变量容器太小或字符集没对齐。
声明变量长度必须 ≥ 实际可能最大字节数
MySQL 的 VARCHAR 声明长度是「字符数」，但底层存储按字节算。UTF8mb4 下一个中文/emoji 占 4 字节，所以声明 VARCHAR(50) 并不意味着能安全存下 50 个汉字。
- 若字段用于拼接用户输入（如日志摘要、评论预览），建议声明为
VARCHAR(500)起步；描述类内容直接上TEXT - OUT 参数如果由 Java/.NET 调用，
registerOutParameter指定的长度也得同步放大，否则驱动层就提前切掉 - 别信“业务说最多 20 个字”——用户粘贴 emoji + 全角符号后，20 字符可能撑到 120 字节
截断前必须用 CHAR_LENGTH() 判断，不能只看 LENGTH()
LENGTH() 返回字节数，CHAR_LENGTH() 才返回真实字符数。对中文、emoji 场景，混用会导致逻辑错位：比如想限制 20 个汉字，用 LENGTH(str) > 80 判断，结果遇到一个 ?（4 字节）就误判。
- 正确写法：
IF CHAR_LENGTH(input_str) > 30 THEN SET truncated = CONCAT(SUBSTRING(input_str, 1, 30), '…'); ELSE SET truncated = input_str; END IF; - 如果字段可能为
NULL，记得先IF input_str IS NULL THEN ...分支处理，否则CHAR_LENGTH(NULL)返回NULL，整个判断失效 - 省略号要用 Unicode 字面量
N'…'（尤其 SQL Server）或确保连接字符集为utf8mb4，否则显示成 或方块
避免在存储过程中做 CSV 解析或逐字符扫描
想在过程里拆分 'a,b,"c,d",e' 这种带引号的字符串？别试。MySQL 没有状态机支持，LOCATE()+SUBSTRING_INDEX() 会把引号内的逗号也当分隔符切开。
- 最稳方案：解析逻辑上推到应用层，存储过程只接收已拆好的单值（如临时表、JSON 数组）
- 若必须在库内处理，约定用不可见分隔符（如
\x01），调用前由应用层替换，过程里用SUBSTRING_INDEX(str, '\x01', n)安全提取 - 游标拆分性能差、调试难、并发易冲突，比用
help_topic表 JOIN 生成序号慢 3–5 倍，纯属吃力不讨好
入库前清理不可见字符比截断更重要
很多“截断报错”其实不是因为内容长，而是源字符串含 \r\n、零宽空格（U+200B）、BOM 头等控制字符，导致实际字节长度远超预期。
- 用
REGEXP_REPLACE(input_str, '[[:cntrl:]]', '')清掉所有控制字符（MySQL 8.0+） - 旧版本可用嵌套
REPLACE(REPLACE(input_str, '\r', ''), '\n', '')，但无法覆盖零宽字符 -
TRIM()默认只去半角空格，对 tab、全角空格、\r\n 都无效，别无脑依赖它
真正麻烦的从来不是“怎么截”，而是“谁来保证截得对”——字符集、连接层、变量声明、调用方参数设置，四个环节只要一环没对齐，截断就会变成玄学。动手前先查 SELECT @@character_set_client, @@collation_connection; 和字段 SHOW CREATE TABLE，比写十行 SUBSTRING 都管用。
