MySQL 5.7默认字符集为latin1、排序规则latin1_swedish_ci，8.0改为utf8mb4和utf8mb4_0900_ai_ci；升级易致乱码、索引超限、排序异常及连接层与字段级collation冲突。
MySQL 5.7 和 8.0 的默认字符集确实变了
5.7 默认是 latin1，8.0 改为 utf8mb4。这不是“可选升级”，而是硬性变更——新实例一创建，character_set_server 就是 utf8mb4，连带 collation_server 默认为 utf8mb4_0900_ai_ci。
这个变化直接导致两类问题：一是旧 SQL 在 5.7 能跑，在 8.0 因隐式转换失败而报错（比如 DATE 和字符串比较）；二是升级后没显式指定排序规则，ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 会悄悄套用 utf8mb4_0900_ai_ci，结果大小写行为突变（比如 'abc' 突然能匹配 'ABC'）。
utf8mb4 不等于“自动兼容”，关键在 collation
utf8mb4 只管编码长度（支持 emoji、生僻字），真正决定“WHERE name = 'X' 是否区分大小写”的是排序规则（collation）。常见误区是以为只要用了 utf8mb4 就万事大吉，其实：
-
utf8mb4_bin：按字节严格比较，'A'≠'a'，适合密码哈希或唯一标识字段 -
utf8mb4_0900_ai_ci：8.0 默认，不区分大小写（_ci）也不区分重音（_ai），比如'café'='cafe' -
utf8mb4_unicode_ci：更老的 Unicode 标准排序，精度略低，但兼容性广
如果你从 5.7 升级上来，原表用的是 utf8_general_ci（不区分大小写），而 8.0 默认变成 utf8mb4_0900_ai_ci，表面看行为一致，但实际排序权重、emoji 排序逻辑已不同，JOIN 或 ORDER BY 可能出意料结果。
执行 CONVERT TO 时 collation 容易被忽略
ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8mb4 这条命令不会保留原 collation，它会直接采用当前字符集的默认排序规则（即 utf8mb4_0900_ai_ci）。这意味着：
- 如果原表是
utf8+utf8_bin（区分大小写），转换后变成utf8mb4+utf8mb4_0900_ai_ci（不区分），查询结果数量可能翻倍 - 如果原表是
utf8+utf8_general_ci，转换后虽然都“不区分”，但排序顺序可能因 collation 内部算法差异而错乱（尤其含多语言数据时） - 正确做法是显式指定：
ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin
别依赖 SHOW CREATE TABLE 后再手工改——有些字段级 collation 比表级还优先，必须逐列检查 COLLATION 值。
如何确认你正在用的其实是哪个 collation
不要只查 character_set_server，很多坑出在连接层或字段层。必须分层验证：
- 连接级：
SHOW VARIABLES LIKE 'collation_connection'; - 数据库级：
SELECT DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'your_db'; - 表级：
SHOW CREATE TABLE your_table;看DEFAULT CHARSET和COLLATE - 字段级：
SHOW FULL COLUMNS FROM your_table;看每列的Collation列
最危险的情况是：连接用 utf8mb4_0900_ai_ci，但某字段定义为 CHARACTER SET utf8mb4 COLLATE utf8mb4_bin，这时 WHERE 条件会按 bin 规则比对，而 ORDER BY 可能按连接级规则排序——结果既难复现，又难调试。
