MySQL 8.0 information_schema字符集为utf8mb3如何修改

根因说明 #

information_schema.SCHEMATA中记录的该库字符集为utf8mb3是MySQL 8.0早期版本的硬编码历史遗留问题，不属于配置错误：

• information_schema是完全虚拟的系统元数据库，没有独立的库属性配置，也不存在实际的表数据存储，所有元数据均来自底层InnoDB数据字典和mysql系统库的系统表。
• 该返回值是代码中写死的元数据字段值，不代表数据库实际运行、存储时使用了utf8mb3字符集，也不会影响普通业务查询的字符集逻辑。
• 触发PRTG/.NET报错的本质是监控程序或MySQL .NET驱动读取元数据时，没有兼容这个遗留返回值，并非数据库本身配置异常。

解决方案（按优先级排序） #

1. 监控侧兼容（零风险，首选） #

不需要修改数据库任何配置，直接调整监控链路即可解决报错：

• 在PRTG的MySQL监控传感器配置中，给连接字符串显式添加Charset=utf8mb4参数，强制.NET驱动使用utf8mb4字符集建立连接，不依赖服务端返回的库默认字符集。
• 如果是自定义查询脚本实现的复制监控，在执行复制状态查询前先执行SET NAMES utf8mb4;，指定连接会话的字符集即可规避报错。
• 复制状态监控本身不需要读取information_schema的库级字符集属性，也可以直接修改监控查询逻辑，跳过无关的字符集元数据读取步骤。

2. 升级MySQL小版本（永久修复显示问题） #

该硬编码bug在MySQL 8.0.30及之后的小版本中已经被官方修复：

• 升级到8.0.30之后的稳定小版本（如8.0.36、8.0.40）后，查询information_schema.SCHEMATA时该库的字符集会正确返回utf8mb4，不会再触发驱动的字符集兼容报错。
• 同大版本下的小版本升级是向前兼容的，升级前做好全量备份即可，不会改动业务数据和用户配置。

3. 严禁执行的操作 #

以下操作会直接损坏系统元数据，导致数据库实例不可用，绝对不要尝试：

• 执行ALTER DATABASE information_schema CHARACTER SET xxx类语句修改系统库属性，这类语句本身会被数据库权限拦截，即使通过底层修改绕过拦截也会造成元数据错乱。
• 直接修改mysql系统库下的隐藏InnoDB字典表，这类表没有对外兼容逻辑，改动后会直接导致实例无法启动。
• 手动修改information_schema下的系统视图定义，系统视图逻辑是编译进MySQL服务端二进制的，手动改动会触发服务崩溃。

校验方法 #

执行以下SQL可以确认实例实际字符集配置正常，不存在utf8mb3相关的运行时风险：

-- 查看全局默认字符集配置
SHOW VARIABLES LIKE 'character_set_server';
-- 查看数据库、表的实际字符集配置（排除information_schema的虚拟元数据返回）
SELECT DEFAULT_CHARACTER_SET_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME NOT IN ('information_schema');

只要返回的用户库、系统库（除information_schema的虚拟返回值外）均为utf8mb4，就说明实例配置无问题。

内容的提问来源于stack exchange，提问作者M.Barbara