ALTER TABLE CONVERT TO CHARACTER SET 失败主因是字段存有声明字符集无法表示的字节序列，如latin1表中误存utf8mb4字节；需先用VARBINARY绕过校验，再转回VARCHAR指定正确字符集，并同步修正连接层配置。
ALTER TABLE CONVERT TO CHARACTER SET 失败：常见报错和根本原因
直接执行 ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 报错，大概率不是语法问题，而是字段里存了当前字符集无法表示的字节序列。比如表原是 latin1，但实际存了未经声明的 utf8mb4 编码字节（常见于历史 PHP + MySQL 混乱配置），MySQL 在转换时会校验并拒绝“非法”字节，抛出类似 Incorrect string value: '\xF0\x9F\x98\x8A' for column 'name' 的错误。
这不是字符集不支持 emoji，而是 MySQL 发现「当前列声明为 latin1，却存着 4 字节 utf8mb4 字节」——它认为这是数据损坏，宁可失败也不强行转。
- 先用
SHOW CREATE TABLE t确认当前CHARACTER SET和各列的COLLATION - 用
SELECT HEX(col), col FROM t WHERE LENGTH(col) != CHAR_LENGTH(col)快速筛出可能含多字节字符的行（latin1下CHAR_LENGTH和LENGTH应相等） - 别跳过校验直接加
IGNORE——那只会静默丢数据，不是修复
安全转换的两步法：先改列声明，再转内容
想保留原始字节（比如你确认那些“非法”字节其实是正确 utf8mb4 内容，只是表声明错了），就不能用 CONVERT TO，得拆成两步：先让 MySQL “承认”这些字节合法，再统一重编码。
典型场景：旧表声明为 latin1，但应用一直以 utf8mb4 发送数据，现在要正规化。
- 第一步：把列类型临时改成
VARBINARY（绕过字符集校验）：ALTER TABLE t MODIFY col VARBINARY(255); - 第二步：再转回
VARCHAR并指定正确字符集：ALTER TABLE t MODIFY col VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 注意：
MODIFY会重建列，大表务必在低峰期操作；CHANGE也可用，但需重复写列名
为什么不能只改表级字符集？
ALTER TABLE t DEFAULT CHARACTER SET utf8mb4 只影响新列，对已有列的 CHARACTER SET 和 COLLATION 完全没作用。很多人卡在这一步，以为改了表就全好了，结果 SHOW CREATE TABLE 一看，列还是 latin1。
- 表级字符集只是默认值，不覆盖已存在列的定义
- 真正生效的是每列自己的
CHARACTER SET，必须显式修改（用MODIFY或CHANGE） - 如果列是
TEXT类型，记得同时指定COLLATE，否则可能退化为utf8mb4_general_ci（已弃用）
连接层和客户端也得同步改
就算表和列都转成 utf8mb4，如果应用连接时没声明字符集，或者 MySQL 配置里 init_connect 还是 SET NAMES latin1，新插入的数据照样变乱码。
- 检查
mysql --defaults-file或应用数据库连接字符串里是否有charset=utf8mb4 - 确认 MySQL 服务端配置：重点看
character_set_server、collation_server，以及客户端连接时的character_set_client、character_set_results - 临时验证可用：
SET NAMES utf8mb4;后再查，看是否正常显示 emoji 或中文
