排查MySQL全库配置utf8mb4仍触发utf8别名警告的问题

核心触发原因 #

这个警告本质是MySQL在字符集转换或元数据校验时检测到了隐性的utf8（即UTF8MB3）引用，你没在代码里搜到是因为这些引用不在业务逻辑或表结构定义里，而是在存储过程元数据、会话连接配置、库级默认配置三个容易被忽略的位置：

1. 存储过程元数据继承了旧字符集 #

创建存储过程时，系统会自动记录当时会话的character_set_client、collation_connection作为存储过程的内置属性，后续调用该存储过程时会优先用这套属性处理字符串。如果当初创建存储过程时，会话默认字符集是utf8（UTF8MB3别名），就算后续你把库、表全改成utf8mb4，存储过程的元数据里还是保留旧字符集配置，调用时就会触发警告。
验证方法：执行以下SQL查询存储过程的字符集属性，替换为你的实际库名：

SELECT ROUTINE_NAME, ROUTINE_CHARACTER_SET_NAME, ROUTINE_COLLATION_NAME 
FROM information_schema.ROUTINES 
WHERE ROUTINE_SCHEMA = '你的数据库名';

如果查询结果里ROUTINE_CHARACTER_SET_NAME显示为utf8，就是这个问题。

2. 沙箱重置脚本的连接会话默认字符集为utf8 #

你执行沙箱重置的客户端（比如命令行、dbForge、自动化脚本的MySQL连接）默认字符集没有改成utf8mb4，执行插入操作时，字符串字面量的字符集继承自会话的utf8配置，和表的utf8mb4字符集转换时触发警告。

3. 库级默认字符集未修改 #

你只修改了表和字段的字符集，没有修改数据库本身的默认字符集，新建存储过程、表时如果不主动指定字符集，就会继承库的旧utf8配置。
验证方法：

SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME 
FROM information_schema.SCHEMATA 
WHERE SCHEMA_NAME = '你的数据库名';

修复步骤 #

• 先修改库级默认配置：

ALTER DATABASE 你的数据库名 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;

• 所有执行SQL的客户端、自动化脚本，连接数据库后先执行以下语句设置会话字符集：

SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci;

• 重新创建所有存储过程：在确保当前会话字符集是utf8mb4的前提下，重新执行所有存储过程的创建语句，覆盖旧的元数据配置即可。

内容的提问来源于stack exchange，提问作者Floobinator