ALTER TABLE CONVERT TO CHARACTER SET 仅修改CHAR、VARCHAR、TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT及ENUM/SET列，不改INT/DATETIME/BLOB；需显式指定COLLATE，全文索引需先删除；会锁表重写整表。
ALTER TABLE CONVERT TO CHARACTER SET 会改哪些列
它只修改 CHAR、VARCHAR、TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT 这些显式声明为字符类型的列，其他如 INT、DATETIME、BLOB 不受影响。但注意：ENUM 和 SET 也会被转换，因为它们底层依赖字符集排序规则。
常见错误现象：执行后发现中文显示乱码，但表结构里明明显示 utf8mb4 —— 很可能是列上没加 COLLATE，MySQL 用了默认校对规则，导致排序和比较行为异常。
- 务必在
CONVERT TO后显式指定校对规则，比如CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 如果表里有全文索引（
FULLTEXT），CONVERT TO会失败，需先删索引再重建 -
CONVERT TO是“重写整张表”，大表会锁表、耗时长，生产环境务必在低峰期操作
ALTER TABLE MODIFY COLUMN 和 CONVERT TO 的区别
MODIFY COLUMN 是精确控制单个字段，而 CONVERT TO 是批量重定义整张表的字符集和校对规则。前者适合局部调整，后者适合统一收口。
使用场景：已有表部分字段是 latin1，但只想改其中几个 VARCHAR 字段，就用 MODIFY COLUMN；如果全表都要切到 utf8mb4，且确认所有字符列都该一起变，CONVERT TO 更省事。
-
MODIFY COLUMN必须重复写出完整字段定义，例如：MODIFY COLUMN name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 漏写
NOT NULL或默认值会导致字段约束丢失，比如原字段是NOT NULL DEFAULT '0'，新语句没写就会变成可空且无默认值 -
MODIFY COLUMN对TEXT类型字段可能触发隐式转换，某些 MySQL 版本下会把TEXT自动转成MEDIUMTEXT，需提前验证
执行前必须检查的三项内容
跳过这三步，90% 的编码转换问题都出在这里。
- 查当前字符集配置：
SHOW CREATE TABLE `table_name`，重点看表级DEFAULT CHARSET和每列的CHARACTER SET、COLLATE - 确认客户端连接字符集是否一致，否则即使表改对了，
INSERT进来的数据仍是乱码 —— 检查character_set_client、character_set_connection、character_set_results是否都是utf8mb4 - 备份！不是导出 SQL，而是用
mysqldump --single-transaction --default-character-set=utf8mb4导出，避免 dump 过程中因字符集不匹配丢数据
ALTER TABLE 转换后中文仍乱码的典型原因
不是命令没生效，而是数据本身在入库时就已经损坏了 —— MySQL 不会修复历史乱码，只负责按当前字符集解释字节流。
比如原来用 latin1 存了 UTF-8 编码的中文（即“双重编码”），现在转成 utf8mb4，MySQL 会把每个 UTF-8 字节当做一个 latin1 字符去解，结果就是一堆问号或 Mojibake。
- 先用
SELECT HEX(column_name) FROM table_name LIMIT 1看原始字节，判断是否已损坏 - 如果
HEX()结果是类似C3A4C2B8C2A6这种偶数长度的十六进制串，大概率是 UTF-8 被当latin1存过，需要先用函数“反向修复”，不能直接改字符集 - 线上表一旦出现这种混合编码，建议停写、导出、清洗、重建，而不是在原表上硬转
真正麻烦的从来不是命令怎么写，而是你不知道数据到底以什么编码存进去的。
