根本原因是客户端、连接、数据库三层字符集不一致；需确保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;查看实际保存的定义，里面中文是否已变成问号？如果是，说明建过程时连接就是错的
字符集问题从来不是单点故障，它像一条流水线，中间任意一环卡住，下游全废。最常被忽略的是连接初始化那一下，而不是过程里写了什么。
