乱码根源是客户端、连接层、字段三层字符集未对齐，需立即验证并统一为utf8mb4；UPDATE不报错但结果异常说明MySQL接收时已错误解析；须检查三处运行时字符集、表字段实际编码及COLLATE规则，并针对性修正。
乱码不是更新操作“改坏了”，而是字符集在客户端、连接层、字段三者之间原本就没对齐，改完只是让错配更明显。必须立刻验证并同步修正这三层。
UPDATE 后查出来是问号或 ？先确认三处运行时字符集
执行 UPDATE 本身不会报错，但结果异常，说明 MySQL 接收时已按错误编码解析。立刻连上数据库运行：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;
三个值必须全是 utf8mb4。常见陷阱：
- 应用代码里只设了连接参数，但没在执行
UPDATE前调用set_charset('utf8mb4')（如 mysqli）或没在 DSN 里带charset=utf8mb4（如 PDO） - Navicat/DBeaver 等工具改了连接设置，但当前会话是旧连接，需断开重连
- MySQL 服务端配置改了
character-set-server，但客户端启动时没加--default-character-set=utf8mb4，仍按latin1初始化连接
表字段实际存储编码 ≠ 数据库默认编码
SHOW CREATE TABLE your_table; 查看字段定义，重点盯两处：
- 建表语句末尾是否有
DEFAULT CHARSET=utf8mb4 - 每个中文字段（如
name VARCHAR(100)）后面是否显式写了CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
如果字段没显式声明，即使库默认是 utf8mb4，它也可能继承自旧的 latin1 表结构。此时 ALTER TABLE t CHARACTER SET utf8mb4 只改元数据，无效；真正生效的是：
ALTER TABLE your_table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意：大表执行会锁表、重建索引、临时磁盘空间翻倍，线上务必选低峰期。
SQL 文件里执行 UPDATE 仍乱码？检查文件真实编码
编辑器显示“UTF-8”不等于文件真是 UTF-8。Windows 上 VS Code 默认可能存成 UTF-8 with BOM，MySQL 会把 BOM 当非法字符跳过，导致后续中文偏移解码；Linux/macOS 下用 file -i your.sql 看真实编码。
- 若文件是
GBK编码，不能直接导入：iconv -f gbk -t utf8mb4 your.sql > fixed.sql - 导入时必须加参数：
mysql --default-character-set=utf8mb4 -u root -p db_name - 若 SQL 文件开头没有
SET NAMES utf8mb4;，手动加到第一行（必须在任何USE或CREATE之前）
UPDATE 成功但 SELECT 出来还是乱码？重点看字段级 COLLATE
字符集对了，排序规则（COLLATE）错也会导致查询乱码。比如字段是 utf8mb4 但用了 utf8mb4_general_ci，而客户端发来的是 utf8mb4_unicode_ci 比较逻辑，某些边界字符可能映射失败。
查字段实际 COLLATE：
SHOW FULL COLUMNS FROM your_table WHERE Field = 'name';
确保输出中的 Collation 列是 utf8mb4_unicode_ci（或你选定的兼容规则），不是 latin1_swedish_ci 或空值。
修正方式（以 name 字段为例）：
ALTER TABLE your_table MODIFY name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
这个动作会重写字段定义，比 CONVERT TO 更精准，也避免误改其他约束。
