不能一键修改，必须逐表执行ALTER TABLE CONVERT TO；因ALTER DATABASE只改默认值，不触发表和字段的实际字符集与校对规则，否则JOIN/UNION会报Illegal mix of collations。
直接改表字符集会丢数据，先确认当前状态
修改 CHARSET 或 COLLATION 不是点几下就能完事的操作。如果表里已有中文、emoji 或带重音符号的字符，直接改可能触发隐式转换，导致乱码甚至截断。第一步必须查清现状：
SHOW CREATE TABLE `your_table_name`;
重点看三处：DEFAULT CHARSET（表级）、COLLATE（列级默认）、每个 VARCHAR/TEXT 列自己的 COLLATE。别只信 phpMyAdmin 右上角显示的“排序规则”，它常只反映表级设置，掩盖列级差异。
用 SQL 语句改比界面操作更可控
phpMyAdmin 的图形界面在“操作”页里提供“排序规则”下拉菜单，但它的行为不透明：有时只改表级 DEFAULT COLLATION，不触碰已有列；有时又强制批量改列，且不提示是否转换数据。推荐手动执行 ALTER TABLE：
- 仅改表默认值（新列生效，旧列不变）：
ALTER TABLE `users` DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
- 连同所有文本列一起转（含数据重编码）：
ALTER TABLE `users` CONVERT TO CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci;
- 只改某列（避免全表锁）：
ALTER TABLE `users` MODIFY `name` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意：CONVERT TO 会重建表，大表务必在低峰期操作，并确认磁盘空间足够。
utf8mb4 是底线，别再用 utf8
MySQL 的 utf8 实际是阉割版，最多存 3 字节字符，不支持 emoji 和部分中文生僻字。真正兼容 Unicode 的是 utf8mb4。改的时候必须同步处理三层：
- 连接层：确保 PHP 连接时指定
charset=utf8mb4（PDO DSN 加;charset=utf8mb4，mysqli 用set_charset('utf8mb4')） - 服务层：MySQL 配置文件中
collation-server和character-set-server设为utf8mb4_unicode_ci - 表与列层：如上用
CONVERT TO或MODIFY落实
漏掉任意一层，都可能让新插入的数据立刻变问号。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
校对规则选错会导致 ORDER BY 和 WHERE 失效
utf8mb4_general_ci 已废弃，utf8mb4_unicode_ci 更准但稍慢，utf8mb4_0900_as_cs（MySQL 8.0+）区分大小写和重音。选哪个取决于业务需求：
- 用户昵称搜索需忽略大小写？用
_ai（accent-insensitive）结尾的规则 - 密码哈希字段必须严格二进制比较？该列单独设为
utf8mb4_bin - 多语言混合排序（如中英混排）？
utf8mb4_unicode_ci比_0900_as_cs更稳
改完立刻测试：
SELECT * FROM users WHERE name = '张三';
和
SELECT * FROM users ORDER BY name LIMIT 5;
看结果是否符合预期。校对规则不是“设了就完”，它直接影响索引能否命中。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
