如何解决MySQL存储过程中的中文乱码问题_利用CHARACTER SET utf8mb4定义

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，过程体里的中文就可能在“出生”那一刻便已损坏。这不是运行时的编码转换问题，而是定义阶段的根本性错误。解决它，钥匙就在创建语句的那一行声明里。