phpMyAdmin 5.1 不支持图形化批量修改校对集，因其“勾选多行→编辑”功能生成的 MODIFY COLUMN 语句缺失 CHARACTER SET 和 COLLATE 子句，导致实际未生效；ENUM/SET 字段用 MODIFY 还可能清空数据，故必须手写带完整定义的独立 ALTER TABLE 语句，并优先对 ENUM 使用 CHANGE COLUMN，执行前需充分测试、备份并检查版本兼容性。
不能一键批量改多个字段的校对集，必须逐个执行 ALTER TABLE ... MODIFY COLUMN 或 CHANGE COLUMN，且每条语句只能改一个字段。
为什么 phpMyAdmin 5.1 不支持图形化批量改校对集
phpMyAdmin 的「结构」页里，“勾选多行 → 编辑”功能对字符集/校对集修改完全无效：它会为每个字段生成独立的 MODIFY COLUMN 语句，但不会自动补全 CHARACTER SET 和 COLLATE 子句，最终执行的是不带字符集声明的语句——MySQL 会按表默认值回退，结果就是“看似点了保存，实际没变”。
更危险的是，如果字段类型是 ENUM 或 SET，用 MODIFY 还可能触发隐式重建，导致旧数据被清空或转成空字符串。
所以图形界面只适合单字段微调；批量改校对集，必须走 SQL。
立即学习“PHP免费学习笔记（深入）”；
正确写法：用 MODIFY COLUMN 显式指定每个字段的新校对集
比如要把 users 表中 name、email、bio 三个 VARCHAR 字段全改成 utf8mb4_unicode_ci，得写三条独立语句：
ALTER TABLE `users` MODIFY COLUMN `name` VARCHAR(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `users` MODIFY COLUMN `email` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `users` MODIFY COLUMN `bio` TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意要点：
- 必须显式写出完整字段定义（类型、长度、是否
NOT NULL），不能只写字段名 - 如果原字段有
DEFAULT、COMMENT或GENERATED属性，也得一并复制过去，否则会被清空 - 对
TEXT/MEDIUMTEXT等类型，长度参数可省略，但CHARACTER SET和COLLATE不可少 - 别合并成一条语句——MySQL 不支持在一个
ALTER TABLE里多次MODIFY COLUMN
遇到 ENUM 字段时，必须用 CHANGE COLUMN 而非 MODIFY
ENUM 字段改校对集时，MODIFY 会强制重建枚举列表，极易丢数据。安全做法是用 CHANGE COLUMN 全量重申：
ALTER TABLE `orders` CHANGE COLUMN `status` `status` ENUM('pending','done','cancelled') CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL;关键点：
- 括号里的枚举值必须和原来完全一致（顺序可调，但一个都不能少）
- 必须显式带上
NOT NULL或NULL，否则默认约束会丢失 - 如果字段有
DEFAULT，末尾还得加DEFAULT 'pending' - 每改一个
ENUM字段，都得单独执行一条CHANGE语句
执行前必须验证和备份
批量改校对集不是“改个配置”，它会锁表、重建字段、可能触发数据转换。线上操作前务必：
- 先在测试库跑一遍所有
ALTER语句，用SELECT * FROM 表 WHERE 字段 REGEXP '[^[:ascii:]]'检查中文/emoji 是否仍能正常读出 - 导出要改的表结构（仅结构）和关键数据样本，留作回滚依据
- 确认 MySQL 版本 ≥ 5.7.31 或 8.0.19+，旧版本对
utf8mb4_0900_ai_ci支持不全，容易报错 - 避开业务高峰，单条语句执行时间超过 30 秒就该考虑分批或换策略
真正麻烦的从来不是写那几行 SQL，而是改完之后应用层缓存没清、ORM 模型还按旧校对集做排序、前端提交时又悄悄转成问号——这些都得人盯。
