最准方法是查 information_schema：库级用 SCHEMATA 表，表级用 TABLES 表，列级用 COLUMNS 表；SHOW CREATE TABLE 和 @@character_set_database 不可靠，因不反映后续 ALTER 修改；连接层需同时检查 client、connection、collation 三参数。
直接查 information_schema 最准，别信 SHOW CREATE TABLE 输出的“默认值”——它不反映列是否被后续单独改过。
查数据库级字符集和排序规则
最常用也最容易出错的地方：很多人只看 @@character_set_database，但这个值只代表当前默认数据库的配置，不是你正在操作的那个库。
- 先用
USE your_db;切到目标库，再执行SELECT @@character_set_database, @@collation_database; - 或者更稳妥地查系统表：
SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'your_db'; - 注意：如果
DEFAULT_COLLATION_NAME是utf8mb4_0900_ai_ci，说明是 MySQL 8.0+ 默认配置；如果是utf8mb4_general_ci，大概率是老版本迁移过来没更新
查表和列的实际字符集与排序规则
SHOW CREATE TABLE t; 显示的是建表时的声明，但 ALTER COLUMN 可能已单独改过某列，此时它完全失效。
- 查表默认配置：
SELECT TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table'; - 查某列真实配置（关键！）：
SELECT CHARACTER_SET_NAME, COLLATION_NAME FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table' AND COLUMN_NAME = 'your_column'; - 如果返回
CHARACTER_SET_NAME或COLLATION_NAME是NULL，说明该列是VARBINARY、BLOB等二进制类型，不走字符集解析逻辑
查连接层的字符集与排序规则
应用连上 MySQL 后没执行 SET NAMES utf8mb4;，就可能用 latin1_swedish_ci 做连接 collation，导致函数返回值、临时表字段都按错规则比较。
- 查当前连接设定：
SELECT @@character_set_client, @@character_set_connection, @@collation_connection; - 常见错误组合：
character_set_client = utf8mb4但collation_connection = latin1_swedish_ci→ 字符串字面量（如WHERE name = '张三'）会按 latin1 规则比较，结果不可靠 - 验证方法：执行
SELECT 'a' = 'A' COLLATE utf8mb4_0900_ai_ci;和SELECT 'a' = 'A' COLLATE utf8mb4_bin;，看是否都返回1
真正容易被忽略的是列级 collation 的独立性——哪怕整库都是 utf8mb4_0900_ai_ci，只要某一列被 ALTER TABLE ... MODIFY COLUMN ... COLLATE utf8mb4_bin 改过，JOIN 或 WHERE 里跟其他列混用就会触发 Illegal mix of collations 错误，且报错位置往往不指向那列本身。
