ALTER TABLE CONVERT TO CHARACTER SET utf8mb4会真正转换列字符集和排序规则，而DEFAULT CHARACTER SET仅影响新增列；必须同步修改列COLLATE并确保客户端、服务端、应用层全链路utf8mb4对齐，否则仍会报错或乱码。
ALTER TABLE 修改表字符集时，只改表级默认值，不改已有列
执行 ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci 才会真正转换列的字符集和排序规则；而 ALTER TABLE table_name DEFAULT CHARACTER SET utf8mb4 仅影响后续新增列，已有 VARCHAR、TEXT 字段仍保持原 utf8 或 latin1 设置，插入四字节 emoji 仍会报错 Incorrect string value。
必须同步修改列的 COLLATE，否则排序/比较行为异常
即使字符集改成 utf8mb4，若列定义里显式写了 COLLATE utf8_general_ci（或未指定但继承了旧表默认），MySQL 仍用旧排序规则处理该列——这会导致大小写敏感性不一致、中文排序错乱、索引失效等问题。
- 推荐统一用
utf8mb4_unicode_ci（MySQL 5.7+）或utf8mb4_0900_as_cs（MySQL 8.0+） - 检查现有列：运行
SHOW CREATE TABLE table_name，看每列末尾是否带COLLATE - 批量修正示例：
ALTER TABLE table_name MODIFY column_name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
TEXT 类型字段需额外注意长度限制与行格式
TINYTEXT/TEXT/MEDIUMTEXT/LONGTEXT 在 utf8mb4 下实际可存字符数不变，但每个字符最多占 4 字节，容易触发 max_allowed_packet 或行溢出。尤其当表使用 COMPACT 行格式且含多个 TEXT 列时，转换后可能因页内存储不足而强制转为 Dynamic 格式。
- 转换前建议先执行
ALTER TABLE table_name ROW_FORMAT=DYNAMIC - 确认
innodb_file_format= Barracuda（MySQL 5.6+ 默认启用）且innodb_large_prefix=ON - 避免对大表直接
CONVERT TO，优先在低峰期操作并监控磁盘空间
客户端连接、服务端配置、应用层三者必须全部对齐
只改表没用。如果 my.cnf 里 character-set-server=utf8mb4 没配，或者应用 JDBC URL 缺少 ?characterEncoding=utf8mb4，又或者 MySQL 连接时执行了 SET NAMES utf8，那所有转换都白做——数据写入时仍被截断或转义。
- 验证服务端配置：
SHOW VARIABLES LIKE 'character_set%'，确保character_set_server和collation_server均为utf8mb4相关值 - 验证连接层：
SHOW VARIABLES LIKE 'collation_connection'，应与表列一致 - PHP 中记得设
mysqli_set_charset($conn, 'utf8mb4')；Python PyMySQL 需在connect()传charset='utf8mb4'
SHOW CREATE TABLE 就算完——拿含 emoji 的字符串实测插入、查询、ORDER BY、LIKE 匹配，才是真生效。很多问题拖到上线后才发现，是因为开发环境连的不是同一套配置。 
