导出或导入含中文的mysql存储过程乱码，根源在于character_set_client、connection、results三者未全程统一为utf8mb4；需在创建时set names utf8mb4、导出时mysqldump加--default-character-set=utf8mb4、导入时mysql客户端也指定该参数，并确认.sql文件为utf-8编码。
导出或导入含中文的 MySQL 存储过程时出现乱码，不是过程本身写错了，而是字符集在「创建—导出—再导入」链路中至少断了一环。核心必须保证 character_set_client、character_set_connection、character_set_results 三者全程为 utf8mb4，缺一不可。
导出前必须确认会话字符集已对齐
用 mysqldump 导出存储过程时，它读取的是 mysql.proc 表里的内容——而这张表里的中文早已在创建时被解析并存入。如果当初建过程时 character_set_client 是 latin1，那“你好”两个字就已变成损坏的字节，导出再怎么指定编码也救不回来。
- 导出前先连进数据库，执行
SET NAMES utf8mb4; - 立刻验证：
SHOW VARIABLES LIKE 'character\_set%';，确保character_set_client、character_set_connection、character_set_results全是utf8mb4 - 如果发现不是，说明连接初始化就错了，得回退到配置文件或客户端参数去修
mysqldump 命令必须带 --default-character-set=utf8mb4
mysqldump 默认按 latin1 解析服务端返回的数据流，即使你 SET NAMES 了也没用——它不读会话变量，只看自己命令行参数。
- 正确导出命令：
mysqldump -u root -p --routines --no-create-info --skip-triggers --default-character-set=utf8mb4 mydb > proc.sql - 务必加
--default-character-set=utf8mb4，漏掉就会把原本正常的utf8mb4内容强行当latin1转成乱码写入文件 - 老版本 MySQL（如 5.7）若不支持
utf8mb4，可临时改用utf8，但要注意 emoji 和四字节 Unicode 会丢
导入时文件编码和连接参数必须双重保障
导出的 .sql 文件本身有编码，MySQL 客户端读它时又有一次解码，两层错位就直接乱码。
- 用
file -i proc.sql（Linux）或 Notepad++ 的“编码 → 转为 UTF-8 无 BOM”确认文件实际是 UTF-8 编码 - 导入命令必须显式指定字符集：
mysql -u root -p --default-character-set=utf8mb4 mydb - 如果用 Navicat 或其他 GUI 工具导入，要在连接属性里勾选“使用 UTF8MB4 字符集”，不能只靠工具默认设置
- 导入脚本开头第一行建议加上
SET NAMES utf8mb4;，防万一
最容易被忽略的是：存储过程体内的中文（比如注释、SELECT '测试'）一旦在创建时就被错误解析，后续所有导出导入都只是在搬运损坏数据。所以修复永远要从源头开始——不是改 dump 命令，而是确保第一次 CREATE PROCEDURE 时，character_set_client 就是 utf8mb4。
