MySQL存储过程中文乱码主因是数据库默认字符集为latin1，需重建库并设utf8mb4；动态SQL拼接须用CONVERT转码；应用连接需显式指定utf8mb4编码；创建过程前应执行SET NAMES utf8mb4。
MySQL 存储过程里中文变问号或乱码，先查 character_set_database 和 collation_database
存储过程本身不单独存字符集，它继承所在数据库的默认字符集。如果建库时没指定，很可能用的是 latin1，哪怕你客户端连的是 utf8mb4，过程里 DECLARE 的变量、SELECT 返回的字符串照样会丢字节。
实操建议：
- 执行
SHOW CREATE DATABASE your_db_name;确认当前库字符集，不是看character_set_client那些会话级变量 - 如果输出里是
DEFAULT CHARACTER SET latin1，别改过程，直接重建库（导出 SQL → 修改 CREATE DATABASE 语句 → 导入） - 新建库务必显式写全：
CREATE DATABASE mydb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
存储过程中拼接 SQL 字符串（CONCAT + PREPARE）时中文失效
这是高发场景：用 CONCAT('SELECT * FROM t WHERE name = ''', @name, '''') 拼动态 SQL，@name 是中文，结果查不到——因为 CONCAT 默认按连接字符集拼，而会话的 character_set_connection 可能是 latin1，导致中间转换成乱码。
实操建议：
- 强制转码：把变量包进
CONVERT(@name USING utf8mb4)再拼接 - 更稳写法：用
CONCAT(CHAR(0xEF,0xBB,0xBF) USING utf8mb4, @name)这类方式不推荐，优先走CONVERT - 避免拼接：能用参数化就用
EXECUTE stmt USING @name，PREPARE本身支持二进制安全传参
从存储过程返回中文结果，但应用层拿到仍是乱码
问题常不在过程本身，而在调用链路断点：MySQL 驱动、连接 URL、甚至 ORM 的编码配置没对齐。比如 JDBC 连接串漏了 useUnicode=true&characterEncoding=utf8mb4，或者 Python 的 pymysql.connect() 少传 charset='utf8mb4'。
实操建议：
- 在 MySQL 客户端里直接调用过程，确认
SELECT结果正常 → 排除过程逻辑问题 - 检查应用连接串是否含
characterEncoding=utf8mb4（JDBC）、charset参数（pymysql / mysqlclient）、或options里指定了charset（Node.js mysql2） - PHP 用户注意：
mysqli_set_charset($conn, 'utf8mb4')必须在mysqli_connect()之后立即调用，不能等进过程再设
SHOW CREATE PROCEDURE 显示的定义里中文注释变乱码
这说明创建过程时，客户端发送的 SQL 文本本身就被 MySQL 当作 latin1 解析了。即使库是 utf8mb4，如果连接初始字符集不对，DDL 语句里的中文注释一入库就损坏，后续 SHOW 出来自然不可逆。
实操建议：
- 建过程前先执行
SET NAMES utf8mb4;（等价于同时设character_set_client/connection/results） - 用命令行客户端时加参数：
mysql --default-character-set=utf8mb4 -u user -p - Navicat / DBeaver 等工具需在连接属性里明确勾选「使用 UTF8MB4」，不能只信“自动检测”
字符集问题最麻烦的不是修复，而是污染路径长——一个环节漏设，后面所有环节都在补救。尤其注意 character_set_client 和 character_set_connection 这两个容易被忽略的会话变量，它们管着 SQL 文本怎么进 MySQL，比库表字符集还早一步起效。
