客户端发送 SQL 时字符集怎么被 MySQL 解析
MySQL 不会直接信任客户端传来的字节流，它靠 character_set_client 告诉自己“这串字节是按什么编码写的”。如果客户端实际发的是 UTF-8 字节，但连接时没设对或设成 latin1，MySQL 就会用错规则去解码——结果可能是乱码、报错 Incorrect string value，或者更隐蔽的“看起来正常但查不到数据”。
常见错误现象：INSERT 成功但 SELECT 出来是问号；模糊查询 LIKE '%中文%' 查不到；明明存了“张三”，WHERE name = '张三' 却返回空。
- 务必在建连后立刻执行
SET NAMES utf8mb4（或utf8mb4对应的 collation），等价于同时设置character_set_client、character_set_results、character_set_connection - 应用层连接池（如 JDBC、PyMySQL）要显式配置
charset=utf8mb4，不能只依赖服务端默认值 -
character_set_client只影响 SQL 文本解析，不影响字段内容本身——别指望改它就能“修复”已存错的数据
字段存储时如何触发字符集转换
MySQL 在把客户端解析后的字符串写入字段前，会根据该字段定义的 CHARACTER SET 和 COLLATION 做一次转换。这个过程发生在 server 层，不经过引擎（InnoDB/MyISAM 自己不处理编码逻辑）。
关键点：转换是否发生，取决于 character_set_client 和字段字符集是否一致。不一致才转；一致就直通。
- 如果字段是
utf8mb4，而character_set_client = latin1，MySQL 会尝试把 latin1 字节“当作” latin1 解码成 Unicode，再转成 utf8mb4 存——但 latin1 根本表示不了中文，所以常出现Incorrect string value - 即使字段是
utf8mb4，若表默认字符集是utf8（即 utf8mb3），新建字段可能继承错，得显式声明CHARACTER SET utf8mb4 -
ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4会重写所有数据，但不会修正历史乱码；它只保证后续读写路径正确
SELECT 返回结果时怎么决定编码
结果集编码由 character_set_results 控制，它决定 MySQL 把内部 utf8mb4 字节转成什么编码发给客户端。如果这个值是 latin1，哪怕字段存的是正确 utf8mb4，“张三”也会被转成 latin1 字节再发出去——客户端用 utf8 解，就变乱码。
典型表现：命令行 mysql 客户端里看着是乱码，但用 Navicat 或 Python 查询却正常——因为它们各自设置了不同的 character_set_results。
- 不要依赖
SET NAMES后的隐式设置，某些 ORM（如 Django 的mysqlclient）会在每次查询前重置character_set_results - 在
my.cnf里配init_connect='SET NAMES utf8mb4'只对普通用户生效，root 用户和某些管理操作不走这条链路 -
SHOW VARIABLES LIKE 'character\_set%'是排查起点，重点看四个变量：client、connection、results、database是否全为utf8mb4
为什么 utf8mb4_bin 和 utf8mb4_unicode_ci 查询行为不同
字符集转换链路走到最后一步——比较和排序——才真正用到 COLLATION。同一个 utf8mb4 字段，用 utf8mb4_bin 就逐字节比，用 utf8mb4_unicode_ci 就按 Unicode 规则忽略大小写、合并变音符号。
容易踩的坑：线上从 utf8mb4_general_ci 切到 utf8mb4_0900_as_cs 后，唯一索引突然报重复键——因为新校对规则把 “ß” 和 “ss” 当等价，而旧规则不认为它们相等。
- 建表时别省略
COLLATE，尤其涉及唯一约束、ORDER BY、GROUP BY 的字段 -
utf8mb4_unicode_ci（MySQL 5.7）和utf8mb4_0900_as_cs（MySQL 8.0）对 emoji、德语 ß、土耳其 i 的处理差异很大，升级前必须做全量数据比对测试 - 临时修改排序行为可用
COLLATE utf8mb4_bin，比如WHERE name COLLATE utf8mb4_bin = '张'，但加了就无法走索引，慎用
整个链路最脆弱的一环不是存储，而是连接初始化那几毫秒——只要 character_set_client 和客户端真实编码不一致，后面所有环节都跟着错，而且错得悄无声息。
