mysql如何处理存储过程中的中文乱码_mysql字符集与排序规则设置

根本原因是客户端、连接、数据库三层字符集不一致；需确保character_set_client、connection、results均为utf8mb4，建库建表指定utf8mb4，创建存储过程前执行set names utf8mb4，并显式声明变量字符集。

存储过程里中文变问号或乱码，根本原因是客户端、连接、数据库三层字符集不一致

mysql 存储过程中出现中文乱码，不是语法问题，而是字符集链路断了。从客户端发请求，到连接层解析，再到数据库默认设置，只要其中一层是 latin1 或没显式声明 utf8mb4，中文就会在某个环节被截断或错误转码。

常见现象：select 直接查表正常，但调用 CALL my_proc() 后返回字段全是问号；或者存储过程里用 CONCAT('姓名：', name) 拼出乱码；甚至建过程时就报 Incorrect String value 错误。

• 确认当前连接字符集：SHOW VARIABLES LIKE 'character_set%'; 重点看 character_set_client、character_set_connection、character_set_results 是否都是 utf8mb4
• 建库时必须指定：CREATE database db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
• 建表时别偷懒，默认继承库级设置即可，但字段若为 TEXT 或 VARCHAR，确保没被显式写成 CHARACTER SET latin1

创建存储过程前必须显式设置连接字符集，不能依赖全局配置

即使服务器 my.cnf 里写了 character-set-server = utf8mb4，客户端（比如 navicat、MySQL Workbench、Python 的 pymysql）连上来时仍可能用默认 latin1 发起握手。而存储过程的定义语句（CREATE PROCEDURE）是一次性编译保存的，它会固化当时连接的字符集上下文。

实操建议：

• 执行 SET NAMES utf8mb4; 再建过程——这是最简单有效的兜底方式
• 如果用命令行客户端，启动时加参数：mysql --default-character-set=utf8mb4 -u root -p
• 在 JDBC 连接字符串中加上：?useUnicode=true&characterEncoding=utf8mb4
• 避免在过程体里用 SET character_set_results = latin1; 这类临时切换，容易污染后续结果

存储过程内部拼接中文字符串时，注意 CONCAT 和变量声明的隐式转换

CONCAT() 函数本身不决定字符集，它按参数中「最高优先级」的字符集来输出。如果其中一个参数是 latin1 字段或变量，整个结果会被转成 latin1，再塞进 utf8mb4 字段就会出错。

典型翻车点：

• 声明变量时没指定字符集：DECLARE v_name VARCHAR(50); → 默认继承连接字符集，但不可靠；应写成 DECLARE v_name VARCHAR(50) CHARACTER SET utf8mb4;
• 从 latin1 表查出数据赋给变量，再参与 CONCAT，结果仍是乱码
• 用 SELECT ... INTO 赋值时，目标变量字符集与源字段不匹配，MySQL 不报错但静默转码

示例对比：

-- ❌ 危险写法（v_msg 未声明字符集，依赖连接上下文） DECLARE v_msg VARCHAR(100); SET v_msg = CONCAT('用户：', user_name); <p>-- ✅ 显式声明，杜绝歧义 DECLARE v_msg VARCHAR(100) CHARACTER SET utf8mb4; SET v_msg = CONCAT('用户：', CONVERT(user_name USING utf8mb4));

排查乱码要分层验证，别只盯着存储过程代码本身

很多同学反复检查 CREATE PROCEDURE 里的中文字符串，却漏掉更上游的环节。真正的问题往往藏在连接建立那一刻，或调用方传参时的编码处理上。

• 用 SELECT CHARSET(@@character_set_client), CHARSET(@@character_set_connection), CHARSET(@@character_set_results); 确认三者一致
• 检查调用方是否做了 URL 编码或 Base64 处理，比如 PHP 的 mysqli::query() 前没调 set_charset('utf8mb4')
• 如果过程返回结果集，客户端显示乱码，先试 SELECT '测试中文' AS test; 看是否同样乱码——能定位是连接层问题还是过程逻辑问题
• SHOW CREATE PROCEDURE proc_name; 查看实际保存的定义，里面中文是否已变成问号？如果是，说明建过程时连接就是错的

字符集问题从来不是单点故障，它像一条流水线，中间任意一环卡住，下游全废。最常被忽略的是连接初始化那一下，而不是过程里写了什么。