update中文乱码说明客户端、连接层、字段三者字符集未统一为utf8mb4；须执行select @@character_set_client, @@character_set_connection, @@character_set_results验证三值全为utf8mb4，并检查show create table中字段是否显式声明character set utf8mb4。
修改操作（UPDATE）出现中文乱码，说明数据在写入或读取环节已被错误解码，不是“改坏了”，而是“一开始就没对齐”。必须同步检查客户端、连接层、字段三者字符集是否全为 utf8mb4，缺一不可。
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 CONVERT TO CHARACTER SET utf8mb4 才能真正重建字段编码；仅执行 ALTER TABLE t CHARACTER SET utf8mb4 只改元数据，无效。
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）错配也会导致比较/排序异常，间接影响视图、JOIN 或 WHERE 条件中的中文匹配。执行：
SHOW FULL COLUMNS FROM your_table LIKE 'your_column';
确认 Collation 列是 utf8mb4_unicode_ci 或 utf8mb4_general_ci，而不是 latin1_swedish_ci。修正方式：
- 单列：
ALTER TABLE t MODIFY content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 整表：
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意：大表执行 CONVERT TO 会锁表并消耗双倍磁盘空间，别在高峰期操作。
