如何解决MySQL存储过程中的中文乱码问题
遇到MySQL存储过程里的中文乱码，很多人的第一反应是检查连接、核对表结构。但折腾一圈下来，问题依旧。其实，症结往往不在别处，而在于创建存储过程时，少了一句关键的声明。
问题的根源非常明确：如果CREATE PROCEDURE语句没有显式声明CHARACTER SET utf8mb4，那么过程体里的所有字符串字面量（包括中文注释、提示文本）都会按照MySQL的默认字符集（通常是latin1或旧版的utf8）来解析。结果就是，中文在编译阶段就被截断或转成了问号，哪怕你的数据库、表甚至客户端连接都设置得“完美无缺”。
为什么 utf8mb4 是硬性要求，而不是 utf8
这里有个关键认知需要刷新：MySQL里的utf8，其实是个“阉割版”。它最多只支持3字节的Unicode编码，像Emoji表情、部分生僻汉字（比如「?」「?」），以及许多扩展字符，它都无法表示。真正能完整支持4字节Unicode的，是utf8mb4。
这意味着什么呢？如果你的存储过程里包含了中文，而目标字段或变量用的是utf8mb4，但过程体却默认用utf8去解析，那么字节丢失几乎是必然的。这就像试图用一个小一号的容器去装水，水（数据）在倒入的瞬间就洒了。
- 记住：MySQL中的
utf8等价于utf8mb3utf8mb4才是官方推荐、能应对所有现代文本需求的字符集。- 即使你在连接时使用了
SET NAMES utf8，那也仅仅影响了客户端通信层，对存储过程定义时的内部解析规则毫无作用。
CREATE PROCEDURE 必须显式加 CHARACTER SET utf8mb4
省略这一句，MySQL就会去查找数据库级别的默认字符集（character_set_database）来解析过程体。而这个默认值，尤其是在一些从老版本迁移过来的数据库中，很可能就是错误的latin1。
正确的写法，必须把声明加在正确的位置：
CREATE DEFINER=`root`@`%` PROCEDURE `sp_log_user_action`(IN p_user_id INT, IN p_action VARCHAR(100))
COMMENT '记录用户操作日志'
LANGUAGE SQL
NOT DETERMINISTIC
CONTAINS SQL
SQL SECURITY DEFINER
CHARACTER SET utf8mb4 -- ← 这行是灵魂，绝对不能省！
COLLATE utf8mb4_unicode_ci -- ← 建议同步指定校对规则
BEGIN
INSERT INTO user_log (user_id, action_desc, created_at)
VALUES (p_user_id, CONCAT('用户执行了：', p_action), NOW());
END
- 语法顺序敏感：
CHARACTER SET必须放在COMMENT和LANGUAGE SQL等属性之后，但在BEGIN之前。 COLLATE虽然不是强制项，但建议指定，以确保与表字段的校对规则一致，避免产生隐式转换的警告。- 这个过程内部创建的临时表或局部变量，其字符集也会继承这个
CHARACTER SET声明。
验证过程体是否真按 utf8mb4 加载
创建完了，怎么确认真的生效了呢？光用SHOW CREATE PROCEDURE查看定义语句是不够的，它只显示源代码，不反映实际解析结果。你需要深入验证过程体内部的编码行为：
- 检查元数据：执行
SELECT body FROM mysql.proc WHERE name = '你的过程名';，直接查看存储的系统源码。如果里面的中文显示为问号或乱码，那就说明创建时字符集声明没起作用。 - 运行时测试：在过程体内加入一句测试，比如
SELECT LENGTH('中文') AS len_utf8mb4;然后调用这个过程。在utf8mb4下，两个中文字符的长度应该是6（每个汉字3字节）。如果返回2，那基本可以断定它被当成latin1处理了。 - 一旦发现验证失败，最直接的办法就是删除并重建存储过程，确保
CHARACTER SET utf8mb4写在正确位置，且语句没有语法错误。
最后，必须警惕一个最容易被忽略的陷阱：即便你把整个MySQL实例、所有数据库、所有表，乃至每个客户端连接都设置成了utf8mb4，只要在定义存储过程时漏掉了那行CHARACTER SET utf8mb4，过程体里的中文就可能在“出生”那一刻便已损坏。这不是运行时的编码转换问题，而是定义阶段的根本性错误。解决它，钥匙就在创建语句的那一行声明里。
