最稳妥方式是查询information_schema获取实际字符集与排序规则，再用动态SQL生成ALTER TABLE语句批量修改，并需验证列级字符集是否同步。
确认当前数据库和表的字符集状态
直接查 information_schema 是最稳妥的方式，避免靠记忆或猜测。很多问题其实出在没看清当前实际值——比如你以为是 utf8mb4，结果全是 latin1；或者排序规则写成 utf8mb4_general_ci，但 MySQL 8.0+ 默认已是 utf8mb4_0900_ai_ci。
执行这条语句能一次性看到所有非系统库中表的字符集与排序规则：
SELECT table_schema, table_name, table_collation
FROM information_schema.tables
WHERE table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
ORDER BY table_schema, table_name;
注意：table_collation 是表级排序规则，它由建表时指定，或继承自数据库默认值，但不等于列的排序规则（columns.collation_name）。批量改表时，只改表级不影响已有列，但新列会按新规则创建。
生成 ALTER TABLE 修改语句（安全可预览）
别手写几十条 ALTER TABLE——容易漏、易出错、不可复现。用 SQL 动态拼接，先查后看再执行：
例如把所有 mydb 库下表统一改为 utf8mb4 字符集和 utf8mb4_unicode_ci 排序规则：
SELECT CONCAT('ALTER TABLE `', table_schema, '`.`', table_name, '` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;') AS stmt
FROM information_schema.tables
WHERE table_schema = 'mydb'
AND (table_collation != 'utf8mb4_unicode_ci' OR table_collation IS NULL);
关键点：
-
CONVERT TO会同时修改表字符集、排序规则，并**转换所有文本列的数据**（如VARCHAR、TEXT），这是最常用也最彻底的方式 - 如果只想改表默认值但不动已有列数据，用
ALTER TABLE ... CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci，但后续新增列才生效 - 务必加
WHERE过滤条件，跳过已符合目标的表，避免无谓锁表
执行前必须检查的三个风险点
批量 ALTER TABLE 不是“一键替换”，尤其在生产环境：
-
锁表现象：MySQL 5.6+ 的
CONVERT TO在多数存储引擎（InnoDB）上仍需重建表，期间表不可写。大表可能锁数分钟甚至更久 - 主从延迟：DDL 语句会写入 binlog，从库重放时同样耗时。若主库执行完立刻切流量，从库可能还没跟上，导致查询不一致
-
索引长度超限：
utf8mb4单字符最多占 4 字节，原来utf8（实为utf8mb3）下 767 字节的VARCHAR(191)索引，在utf8mb4下等价于VARCHAR(191)× 4 = 764 字节，看似安全；但若原列定义是VARCHAR(255)+ 原utf8，改完可能触发Specified key was too long错误
建议：对单表 > 1GB 或有全文索引/前缀索引的表，先单独测试；用 pt-online-schema-change 替代原生命令可规避锁表，但需额外部署 Percona Toolkit。
改完之后验证列级字符集是否同步
表级改完 ≠ 列级自动更新。有些老表建的时候显式指定了列的 CHARACTER SET latin1，即使表默认是 utf8mb4，该列仍保持原字符集。这类列在 CONVERT TO 后会被正确转换，但如果你用的是仅改表默认值的语法，它们就完全不受影响。
快速检查是否存在“钉子户”列：
SELECT table_schema, table_name, column_name, character_set_name, collation_name
FROM information_schema.columns
WHERE table_schema = 'mydb'
AND character_set_name != 'utf8mb4'
AND data_type IN ('varchar', 'char', 'text', 'tinytext', 'mediumtext', 'longtext');
发现异常列，再单独执行：
ALTER TABLE `mydb`.`mytable` MODIFY `mycol` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
真正麻烦的不是批量操作本身，而是那些建表时硬编码了字符集的遗留字段——它们不会出现在表级变更的覆盖范围内，却会在某次导入、拼接或排序时突然暴露问题。
