直接使用ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4会重置列定义，导致VARCHAR(255)被缩为191、显式COLLATE被覆盖为版本默认值，并可能因索引长度超限（767字节）报错或截断，且不兼容全文索引；安全做法是用MODIFY COLUMN显式重写每列字符集与排序规则，同步校准客户端连接及服务端配置。
为什么不能直接用 ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4
这条命令看似最直白，但实际会悄悄把列的字符集、排序规则、甚至字段长度都重置——比如把 VARCHAR(255) 变成 VARCHAR(191)（因为 utf8mb4 单字符最多占 4 字节，InnoDB 索引前缀限制 767 字节），导致字段被截断或建索引失败。更麻烦的是，它还会把原本显式指定的 COLLATE utf8mb4_unicode_ci 覆盖成默认 collation，而不同 MySQL 版本默认值可能不同（如 8.0 默认是 utf8mb4_0900_ai_ci）。
- 先确认当前表结构：
SHOW CREATE TABLE `your_table`;，重点看列定义里的CHARACTER SET和COLLATE - 不依赖“自动转换”，而是显式重写每列的字符集和排序规则
- 如果表有全文索引，
CONVERT TO会直接报错，必须先删再重建
如何安全地逐列修改字符集而不改字段定义
核心是只改字符集相关属性，不动类型、长度、是否 NULL、默认值这些。用 MODIFY COLUMN 或 CHANGE COLUMN，并完整复述原列定义，仅替换字符集部分。
- 例如原列是：
title VARCHAR(255) NOT NULL DEFAULT ''，应改为：MODIFY COLUMN title VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' - 对 TEXT / BLOB 类型列也一样：
MODIFY COLUMN content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 主键或唯一索引字段若长度超限（如
VARCHAR(255)），需先缩小长度或改用innodb_large_prefix=ON+ROW_FORMAT=DYNAMIC（MySQL 5.7+ 默认支持）
表级别和连接级别的 utf8mb4 必须同步生效
只改表和列还不够。客户端连接仍可能用旧的 character_set_client，导致插入时被隐式转码，存进去还是乱码。
- 检查当前连接字符集：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results; - 在应用连接字符串里显式加参数，例如 JDBC：
?characterEncoding=utf8mb4&useUnicode=true；PHP PDO：charset=utf8mb4 - MySQL 配置文件中设置全局项（重启生效）：
init_connect='SET NAMES utf8mb4'，但注意该语句对 SUPER 权限用户无效
常见报错及绕过方式
ERROR 1709 (HY000): Index column size too large 是最常卡住的地方，本质是索引键长度超了 InnoDB 限制。
- 临时方案：执行
SET GLOBAL innodb_file_format=Barracuda; SET GLOBAL innodb_file_per_table=ON; SET GLOBAL innodb_large_prefix=ON;（5.7.7+ 已默认开启） - 然后改表行格式：
ALTER TABLE your_table ROW_FORMAT=DYNAMIC; - 再执行列修改。注意：DYNAMIC 行格式要求表空间为独立表空间（
innodb_file_per_table=ON） - 如果仍有索引问题，可临时删掉唯一索引/主键，改完再加回来（需停写或锁表）
改完别忘了验证：插入一个带 emoji 的字符串（如 ?），查出来是否原样返回。很多“看起来成功”的转换，其实只是客户端渲染掩盖了存储层问题。
