优先统一库、表、字段的字符集与排序规则，再用collate显式对齐；convert仅用于修复脏数据编码转换，避免在索引字段或函数中滥用导致性能下降或校对冲突。
CONVERT函数报错“Illegal mix of collations”怎么办
直接原因是参与比较或拼接的字符串用了不同校对规则（collation），比如 utf8mb4_unicode_ci 和 utf8mb4_general_ci 混用，MySQL 拒绝隐式转换。此时不能只靠 CONVERT 临时兜底，得先确认源头字符集是否一致。
实操建议：
- 用
SHOW VARIABLES LIKE 'character_set%';和SHOW VARIABLES LIKE 'collation%';查看服务端默认设置 - 用
SHOW CREATE TABLE table_name;看字段实际定义的CHARACTER SET和COLLATION - 检查连接层：客户端执行
SET NAMES utf8mb4;或在连接字符串里加?charset=utf8mb4
CONVERT(expr USING charset) 的正确写法和限制
CONVERT 只能改字符集，不改校对规则；它返回的是 CHAR 类型字符串，不是原字段类型。如果后续还要参与索引查找或排序，性能会下降，且无法利用原字段的校对规则优化。
常见错误写法：
-
CONVERT(col_name USING utf8mb4)—— 错！utf8mb4是字符集名，必须加引号：CONVERT(col_name USING 'utf8mb4') - 在
WHERE条件里对索引字段用CONVERT—— 导致索引失效 - 把
CONVERT当万能解药，忽略表结构/连接层/客户端三方字符集是否真正统一
推荐替代方案：优先用 COLLATE 显式指定校对规则，例如：WHERE col_name COLLATE utf8mb4_unicode_ci = 'abc'，比 CONVERT 更轻量、更可控。
什么时候必须用 CONVERT 而不是 CAST 或 COLLATE
当需要真正改变字节序列（比如从 latin1 二进制数据误存为 utf8mb4 字段时），CAST 和 COLLATE 都只是逻辑重解释，而 CONVERT 会做实际编码转换。
典型场景：
- 修复历史脏数据：字段存的是
latin1编码字节，但定义成utf8mb4，查出来是乱码 → 用CONVERT(CONVERT(col_name USING latin1) USING utf8mb4)双重转换还原 - 跨库同步时源库字符集不一致，ETL 过程中需强制转码
- 调用存储函数时输入参数编码不可控，需在函数体内做防御性转换
注意：CONVERT(... USING ...) 在 MySQL 8.0+ 支持所有内置字符集，但像 gbk 到 utf8mb4 这类转换，若遇到非法字节会静默截断，务必配合 VALIDATE 或前置校验。
CONVERT 在函数内使用的坑：结果集校对规则继承问题
自定义函数返回值的校对规则默认继承第一个参数的校对规则，跟函数体里怎么写 CONVERT 无关。这意味着即使你在函数里写了 CONVERT('abc' USING 'utf8mb4')，只要函数定义没显式声明 CHARACTER SET 和 COLLATION，调用方拿到的结果仍可能触发 “mix of collations” 错误。
解决办法：
- 定义函数时加上
RETURNS VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 避免在函数里拼接不同来源的字符串（比如拼接参数 + 常量字符串），常量字符串默认用连接层校对规则，容易不一致
- 测试时用
SELECT COLLATION(<code>your_function(...)) 确认返回值校对规则是否符合预期
最易被忽略的一点：函数内 CONVERT 转换后的值，如果参与了 UNION 或子查询，MySQL 会按“最宽泛校对规则”合并结果集，可能再次引入隐式转换冲突——这时候光改函数不够，还得统一整个查询链路的校对上下文。
