SHOW COLLATION 返回的是 MySQL 服务器支持的所有排序规则（collation）列表，包括所属字符集、是否默认、比较强度等元信息，不反映当前数据库或连接的实际字符集配置。
SHOW COLLATION 返回的是什么
show collation 查的不是当前数据库的字符集，而是 mysql 服务器支持的所有排序规则（collation）列表，包括它们所属的字符集、是否为默认、比较强度等元信息。它不聚焦于当前数据库或表，容易误以为能直接看到 mydb 用的是 utf8mb4_0900_ai_ci ——其实不会。
查当前数据库的字符集要用 SHOW CREATE DATABASE
真正反映数据库级字符集配置的是建库语句里的 CHARACTER SET 和 COLLATE 子句：
SHOW CREATE DATABASE <database_name>;
常见错误现象：执行 SHOW COLLATION 后翻几十页找“自己库的名字”，结果发现根本没有库名字段——因为这个命令根本不输出数据库上下文。
- 如果没显式指定，新建数据库会继承服务器默认值（由
character_set_database系统变量决定） -
SHOW CREATE DATABASE中的DEFAULT CHARACTER SET才是该库的默认字符集，新建表若不指定，就用这个 - 注意：即使数据库设为
utf8mb4，单个表或列仍可覆盖，所以它只是起点，不是铁律
查当前连接/客户端的字符集设置
很多乱码问题其实出在连接层，而不是库本身。这时要看三个关键变量：
-
character_set_client：客户端发来的 SQL 语句按什么编码解析 -
character_set_connection：服务器内部转换用的中间编码 -
character_set_results：查询结果返回给客户端时用的编码
统一查这三者最简单的方式是：
SHOW VARIABLES LIKE 'character\_set%';
如果其中任意一个不是 utf8mb4（尤其 character_set_client 是 latin1），哪怕库和表全是 utf8mb4，中文照样可能变问号或 Mojibake。
为什么 SHOW COLLATION 容易被误用
它常被当成“字符集检查工具”，但实际用途很窄：只用于确认某个 collation 是否存在、是否支持某类排序（比如带重音、大小写敏感），或者做 CREATE TABLE ... COLLATE = xxx 前的可行性验证。
- 它不告诉你当前环境用了哪个 collation，也不反映任何运行时状态
- 搜索时如果关键词是 “mysql 查看数据库字符集”，
SHOW COLLATION会高频出现在旧文档里，造成路径依赖 - MySQL 8.0+ 默认
utf8mb4_0900_ai_ci，但老应用连上后可能因兼容性自动降级到utf8mb4_general_ci，这种动态行为SHOW COLLATION完全不体现
真正要定位字符集问题，得从库定义、连接变量、表结构三层一起看，少一层都可能漏掉根源。
