执行 SQL 的 UPDATE 语句后，中文全部变成问号——这个问题在 MySQL 中极为常见。但很多人误以为“数据被改坏了”，其实真相是：写入步骤一开始就没走对。数据根本没有被正确编码，只是错误解码后再存进去的。
我直接说结论：UPDATE 后中文变问号或乱码，不是数据被“改坏了”，而是写入时就被错误解码了——必须同步确认 character_set_client、character_set_connection、character_set_results 和字段实际编码这四者全为 utf8mb4，缺一不可。
如何立刻验证当前会话的三处运行时字符集？
别费劲去翻配置文件，直接连上 MySQL 查看“灵魂三问”：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;
结果必须全是 utf8mb4。你是否遇到过这种情况？看起来一切正常，但一查就发现至少有一个值不对。常见错误分布如下：
character_set_client是latin1：这说明应用连接时没带charset=utf8mb4参数，或者命令行没加--default-character-set=utf8mb4。这是一个很容易被忽略的失误，但后果很严重。character_set_connection是utf8（即 utf8mb3）：MySQL 会把 4 字节 UTF-8 字符（比如 emoji）直接截断，写入失败是小事，乱码才是真头疼。character_set_results是gbk：这种情况更隐蔽。写入可能正确，但 SELECT 出来时，客户端会按不同编码解码，显示成方块或问号一点也不奇怪。- 还有一点值得注意：如果你用的是 Navicat 或 DBeaver，当前会话是旧连接，改了设置但没断开重连，值不会刷新。很多人查了半天，结果发现是工具自己的缓存问题。
表字段真用的是 utf8mb4 吗？别信 DEFAULT CHARSET
用 SHOW CREATE TABLE your_table; 查看建表语句，重点盯两处：
- 每条中文字段定义是否显式写了
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci？比如这种：name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 建表语句末尾有没有
DEFAULT CHARSET=utf8mb4？如果没有，那字段很可能从旧库继承了一个latin1编码——这相当于“表面光鲜，内里一团糟”。
必须警惕一个常见误区：仅仅执行 ALTER TABLE t CHARACTER SET utf8mb4 是无效的。它只改了元数据，并没有重建字段存储格式。真正能解决问题的命令是：
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意：大表会锁表、重建索引、占用双倍临时空间。所以务必选低峰期操作，别在生产环境高峰期直接跑。
SQL 文件里执行 UPDATE 仍乱码？先看文件真实编码
编辑器显示“UTF-8” ≠ 文件真是 UTF-8。这里水分很大：
- Windows 上 VS Code 的默认设置可能存成
UTF-8 with BOM，MySQL 会把开头的当非法字符跳过，导致后续中文偏移解码。这就像在信号很好的线路上，你传了一段摩斯密码，结果对方接收时发现开头少了一个符号，后面全乱了。 - Linux/macOS 下可以用
file -i your.sql查看真实编码；如果显示charset=iso-8859-1或gbk，说明你传错了格式。 - GBK 编码文件不能直接导入：用
iconv -f gbk -t utf8mb4 your.sql > fixed.sql转换一下。 - 导入命令必须带参数：
mysql --default-character-set=utf8mb4 -u root -p db_name < fixed.sql - SQL 文件开头没
SET NAMES utf8mb4;？手动加到第一行，而且必须在任何USE或CREATE之前。这是最容易被忽略的“启动开关”。
UPDATE 成功但 SELECT 还是乱码？COLLATE 错了也会翻车
字段字符集对了，但排序规则（COLLATE）不对，结果照样乱码。比如：
- 字段是
utf8mb4，但COLLATE是utf8mb4_general_ci（已废弃的玩意儿）或utf8mb4_bin（区分大小写且排序异常）。 - 推荐统一用
utf8mb4_unicode_ci，MySQL 8.0+ 的utf8mb4_0900_ai_ci也很好。 - 如果要修改单列排序规则，执行：
ALTER TABLE t MODIFY name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 值得注意的是，
CONVERT(name USING utf8mb4)只是临时转输出，不能修复底层错配。它只把一堆错字再映射一遍——属于“治标不治本”的补救手段，不是根治方案。
最容易被忽略的点：客户端终端本身的编码（比如 Windows CMD 默认是 GBK）、IDE 控制台的输出编码、甚至日志系统的解码方式，都可能让“看起来乱码”的问题出现在链路末端，而不是数据库内部。所以排查时，要一层层往上追，不要只盯着 MySQL 看。
