mysql触发器字符串报错源于collation不一致，需在所有字符串操作中显式指定与字段完全匹配的collate，包括if比较、函数参数、变量声明及赋值，且创建触发器前须设set names utf8mb4。
MySQL触发器里一写字符串就报错，不是语法问题，而是字符集上下文在执行时跟字段实际定义对不上——@@collation_connection 和字段的 COLLATION_NAME 不一致，就会立刻触发 Illegal mix of collations 或 Cannot convert string from binary to utf8mb4 这类错误。
触发器里字符串比较直接报 Illegal mix of collations 怎么修
典型场景是：IF NEW.name = 'admin'，但 name 字段用的是 utf8mb4_0900_as_cs，而当前会话的 @@collation_connection 是 utf8mb4_general_ci，MySQL 拒绝隐式转换。
- 先查字段真实校对规则：
SHOW FULL COLUMNS FROM your_table LIKE 'name'，看Collation列值 - 所有字符串操作必须显式加
COLLATE，且名称要一字不差：IF NEW.name COLLATE utf8mb4_0900_as_cs = 'admin' COLLATE utf8mb4_0900_as_cs - 函数参数也不能漏：
UPPER(NEW.name COLLATE utf8mb4_0900_as_cs)，否则UPPER()会按连接层校对规则处理，再比较时又崩 -
SHOW CREATE TRIGGER看不到校对信息，必须在触发器内用SELECT @@collation_connection实际验证运行时环境
触发器里中文变问号或乱码怎么定位
根本不是数据坏了，是触发器创建或执行时的字符集上下文错位。比如建触发器时 character_set_client 是 latin1，哪怕表是 utf8mb4，里面的 '用户登录' 字面量也会被当 latin1 解析，拼进去就丢字节。
- 检查触发器创建时的连接字符集：
SHOW VARIABLES LIKE 'character_set_client'，必须是utf8mb4 - 建触发器前强制设连接：
SET NAMES utf8mb4，再CREATE TRIGGER - 避免裸字符串：
'用户登录'→ 改成CONVERT('用户登录' USING utf8mb4) - 如果字段存的是 gbk 编码的二进制串（旧系统迁移常见），不能直接
CAST(new.col AS CHAR)，得走两步：CONVERT(CAST(new.col AS BINARY) USING gbk)再CONVERT( USING utf8mb4)；注意gbk必须写全称，不能简写
触发器里声明变量也出错？校对规则继承陷阱
局部变量默认没校对规则，一旦赋值来自不同 collation 的字段，就带入源头规则，后续参与比较或拼接就可能二次报错。
- 声明变量时必须显式指定：
DECLARE v_name VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs - 赋值时仍需对齐：
SET v_name = NEW.name COLLATE utf8mb4_0900_as_cs - 别指望
SET NAMES或 init_connect 能“一劳永逸”——触发器运行时不重跑初始化，只认当前会话的@@collation_connection - 如果变量后续要参与索引字段比较，避免用
CONVERT(v_name USING utf8mb4)，它会让条件无法走索引，且返回类型变成CHAR，再参与比较又可能触发新错误
最麻烦的点在于：即使库、表、字段全统一了，触发器仍可能崩——因为它的执行环境完全独立于表定义，只吃会话级的 @@collation_connection 和字段声明时的 COLLATE。每个字符串操作都得手动对齐，少一个 COLLATE 就可能出错。
