incorrect string value错误本质是客户端传入字节序列无法被目标列字符集表示，须逐层排查：先查列实际字符集（show full columns）、再确认连接层是否set names utf8mb4、最后验证应用连接配置是否显式声明charset=utf8mb4。
直接改字段或表的字符集是最稳妥的解法，临时加 COLLATE 只能救急，且可能让索引失效。
遇到 Incorrect string value 错误时该查什么
这个错误本质是客户端传入的字节序列（比如中文、emoji）无法被目标列当前的字符集表示。常见触发点包括：
– 列定义为 CHARACTER SET latin1 却插入中文
– 列是 utf8（即 utf8mb3），但插入了 4 字节 emoji
– 表字符集是 utf8mb4，但某列显式声明为 utf8 或 latin1
- 先查具体列的字符集：
SHOW FULL COLUMNS FROM your_table_name LIKE 'your_column_name';，重点关注Collation列 - 再确认插入语句来源：是应用直连？还是通过中间件/ORM？连接时是否执行了
SET NAMES utf8mb4？ - 别只看
SHOW CREATE TABLE的默认值——它不反映单个列的实际设置
Illegal mix of collations 报错的三种应对方式
这类错误多出现在 JOIN、UNION、WHERE 比较等场景，MySQL 发现两边字段的 collation 不兼容，拒绝隐式转换。
- 首选：统一两张表对应列的
COLLATION，例如都设为utf8mb4_unicode_ci，用ALTER TABLE ... MODIFY COLUMN ... COLLATE utf8mb4_unicode_ci - 次选（仅限临时调试）：在
WHERE或ON条件中强制指定，如a.name = b.name COLLATE utf8mb4_unicode_ci - 慎用：对整张表执行
CONVERT TO CHARACTER SET utf8mb4，它会重写所有字段，但大表会锁表，且若含全文索引需先删后建
为什么 SET NAMES utf8mb4 有时不起作用
这个命令只影响后续查询中字符串字面量和参数的默认 collation，它不改变已存在的表结构、视图定义或列元数据。如果问题出在视图里，或者某列本身定义为 CHARACTER SET latin1，那 SET NAMES 完全无效。
- 验证当前会话下某列的真实
collation：SELECT COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'db' AND TABLE_NAME = 't' AND COLUMN_NAME = 'c'; - 视图的列
collation是“推导出来”的，必须在CREATE VIEW的SELECT子句中用COLLATE显式修饰，否则每次查询都按源表或连接上下文重新推导 - 连接池配置里也要确保初始化 SQL 包含
SET NAMES utf8mb4，否则复用连接时可能沿用旧会话状态
真正麻烦的不是改字符集本身，而是改完之后要验证每条路径：DML 插入、JOIN 查询、ORDER BY 排序、甚至 GROUP_CONCAT 的拼接结果。任何一处漏掉，都可能在某个业务分支里突然报错。
