MySQL中每个数据库的字符集信息存储在information_schema.schemata表的DEFAULT_CHARACTER_SET_NAME字段中，直接查询该字段最准确，不依赖当前连接设置。
查 information_schema.schemata 的 DEFAULT_CHARACTER_SET_NAME 字段
MySQL 中每个数据库的字符集信息就存在 information_schema.schemata 表里，关键字段是 DEFAULT_CHARACTER_SET_NAME。直接查它最准，不依赖当前连接或客户端设置。
实操建议：
- 用
SELECT schema_name, default_character_set_name, collation_name FROM information_schema.schemata;一次性看全 - 加
WHERE schema_name NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys')排除系统库（避免干扰） - 注意：
collation_name是排序规则，它隐含了字符集，但不如default_character_set_name直观可靠
SHOW DATABASES 不显示字符集，别白试
SHOW DATABASES 只列库名，不带任何字符集信息。有人误以为加 LIKE 或 WHERE 能过滤出 utf8mb4 库，其实语法都不支持——它根本不是 SELECT，没法投影字段。
常见错误现象：
-
SHOW DATABASES WHERE default_character_set_name = 'utf8mb4';→ 报错ERROR 1064 - 在客户端里右键“刷新数据库”后仍看不到编码 → 因为 GUI 工具底层调的也是
SHOW DATABASES - 试图用
STATUS或SELECT @@character_set_database查全局默认值 → 那只是当前库的，不是“所有库”的快照
字符集可能和建库语句不一致？是的，但只发生在异常场景
理论上，information_schema.schemata 的 DEFAULT_CHARACTER_SET_NAME 来自建库时的 CHARACTER SET 子句；但若手动改过表或列的字符集，不会反向影响库级定义。
容易踩的坑：
- 用
ALTER DATABASE db_name CHARACTER SET = utf8mb4;修改后，schemata表会立刻更新 —— 这是唯一安全的修改方式 - 直接 UPDATE
information_schema.schemata？不行，它是只读视图，写操作直接报错ERROR 1288 - 从旧版本 MySQL 升级后发现字符集显示为
latin1，但实际表用了utf8mb4→ 说明建库时没指定，沿用了老版本默认值，需逐个ALTER DATABASE
跨版本兼容性：5.7 和 8.0 的字段名一样，但别信 CHARACTER_SET
MySQL 5.7 和 8.0 的 information_schema.schemata 表结构一致，DEFAULT_CHARACTER_SET_NAME 始终可用。但要注意，有些老文档或脚本会引用已废弃的别名字段，比如 CHARACTER_SET（无下划线），它在 5.7+ 已不存在，查出来是 NULL 或报错。
实操建议：
- 永远用
DEFAULT_CHARACTER_SET_NAME，大小写不敏感但建议小写保持习惯 - 在自动化脚本里加个字段存在性检查：
SELECT COUNT(*) FROM information_schema.COLUMNS WHERE TABLE_SCHEMA='information_schema' AND TABLE_NAME='schemata' AND COLUMN_NAME='DEFAULT_CHARACTER_SET_NAME'; - 如果连
information_schema都查不到（极少见），先确认用户有SELECT权限，不是权限被显式拒绝
真正容易被忽略的是：同一个库下不同表可以有不同字符集，schemata 只管库级默认值，不反映实际数据表的编码。要查具体表，得翻 information_schema.tables 和 information_schema.columns。
