触发器中文乱码主因是运行时字符集环境未对齐，而非语法错误；MySQL不持久化创建时的连接字符集，故SHOW CREATE TRIGGER无法体现编码问题，须检查是否显式使用_utf8mb4前缀修饰字符串字面量。
触发器里中文乱码，基本不是触发器写错了，而是它运行时的字符集环境没对齐——尤其在 MySQL 5.7 升级到 8.0 后更常见。
为什么 SHOW CREATE TRIGGER 看不出编码问题？
MySQL 不在触发器元数据中持久化创建时的连接字符集。即使你当年用 SET NAMES latin1 创建了触发器，升级后 SHOW CREATE TRIGGER 输出里也不会带 CHARACTER SET latin1 注释，但执行时仍按老逻辑解析字符串字面量。
- 用
SHOW CREATE TRIGGER xxx检查 DDL，如果里面没显式声明CHARACTER SET utf8mb4（比如字符串常量没加_utf8mb4'中文'前缀），就大概率是隐患点 - 触发器内硬编码的中文，如
INSERT INTO log VALUES ('用户已更新');，实际按character_set_client解析——若该值是latin1，那这串字节进库就是错的 - 别依赖
my.cnf里的character_set_server=utf8mb4，它不影响已有触发器的运行时解析行为
触发器内中文字符串必须加 _utf8mb4 前缀
不加前缀的字符串字面量，MySQL 会按当前 character_set_client 解析；加了前缀才强制按指定字符集解释字节。
- 错误写法：
SET @msg = '新增订单成功';—— 若客户端连的是 latin1，这串字节存进变量就是乱码字节 - 正确写法：
SET @msg = _utf8mb4'新增订单成功';—— 强制按 utf8mb4 解析源码中的字节 - 所有地方都要加：IF 条件里的比较值、INSERT 的 VALUES、RETURN 表达式、甚至 CONCAT 的参数
- 别用
CAST('xxx' AS CHAR)，它不指定字符集，行为取决于character_set_connection，不可控
CONVERT 在触发器里只能轻量补救，不能根治
触发器里用 CONVERT(col USING utf8mb4) 是临时转换字段值，不是修复存储本身。它快不了多少，还容易掩盖真正的问题。
- 只在必要字段上用：比如老表字段是
latin1，又不能立刻改表结构，才在触发器里转 - 避免嵌套转换：
CONVERT(CONVERT(name USING latin1) USING utf8mb4)这种写法性能差，且极易翻车 - TEXT/BLOB 字段慎用
CONVERT：可能截断或报错，不如直接ALTER TABLE ... MODIFY ... CHARACTER SET utf8mb4 - 真正拖慢触发器的是多层转换 + 长字段处理，不是单次
CONVERT本身；测试得用SHOW PROFILE或慢日志，EXPLAIN看不到触发器开销
升级 MySQL 8.0 后触发器乱码更明显，因为默认值变了
MySQL 8.0 默认 character_set_server=utf8mb4，但老触发器是在 5.7 下用 latin1 连接创建的，元数据没存编码意图，重载后行为会变——看起来像“突然坏了”，其实是暴露了历史债务。
- 升级后第一件事：连上去立刻执行
SHOW VARIABLES LIKE 'character_set%';，确认character_set_client是不是已变成utf8mb4 - 如果仍是
latin1，说明客户端连接没设 charset，触发器里所有无前缀字符串都按 latin1 解析 - 修复顺序必须是：先改应用连接参数（如 JDBC URL 加
charset=utf8mb4），再批量重写触发器加_utf8mb4前缀，最后考虑改表结构 - 别指望靠
ALTER DATABASE ... CHARACTER SET utf8mb4让旧触发器自动变正常——它只影响新对象
最易被忽略的一点：触发器里的中文乱码，往往不是触发器本身逻辑问题，而是它运行时所处的连接上下文（character_set_client）和创建时的上下文不一致。这个差异在跨版本升级、不同客户端混用、或运维手动连库执行脚本时特别致命。
