mysql存储过程注释乱码通常由编码不一致引起，解决方法包括统一字符集、重新编译存储过程和确保导出导入时的编码正确。一、确认数据库及连接字符集：检查服务器、数据库、表和客户端的字符集是否均为utf8mb4，并进行必要的修改。二、修改并重新编译存储过程：在正确字符集下导出、修改注释（如有需要）、删除并重新创建存储过程。三、处理导出/导入时的乱码：导出和导入时均指定utf8mb4字符集，并确保sql文件保存为utf-8格式。四、验证修复效果：通过show create procedure查看注释是否正常显示，并在客户端调用存储过程以确认无异常。只要各层级字符集保持一致，乱码问题即可有效解决。
mysql存储过程中如果出现注释乱码，通常是因为编码设置不一致导致的。这种问题在跨平台迁移、导出导入或者不同字符集环境下尤为常见。解决这类问题的关键在于统一编码格式和重新编译存储过程。
下面是一些实用的方法，帮助你排查并修复存储过程中的注释乱码问题。
一、确认数据库和连接的字符集设置
乱码的根本原因通常是字符集不匹配。你需要检查以下几个层面的字符集配置：
- 服务器字符集：SHOW VARIABLES LIKE ‘character_set_server’;
- 数据库字符集：SHOW CREATE database your_db;
- 表和存储过程的字符集：可以通过 SHOW CREATE PROCEDURE proc_name; 查看
- 客户端连接字符集：确保连接时使用的是正确的字符集，比如在连接命令中加上 –default-character-set=utf8mb4
常见的正确组合是：
- 数据库、表、存储过程使用 utf8mb4
- 连接使用 utf8mb4
如果你发现某个层级不是 utf8mb4，就需要进行修改。比如修改数据库默认字符集：
ALTER DATABASE your_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
二、修改存储过程定义并重新编译
如果已经确认字符集没问题，但注释还是乱码，说明存储过程本身可能是在错误字符集下创建的，需要重新编译。
步骤如下：
- 导出原始存储过程定义（注意使用正确的字符集导出）
- 修改源代码中的注释部分（如有必要）
- 使用正确的字符集连接数据库
- 删除原有存储过程
- 重新执行创建语句
举个例子：
DROP PROCEDURE IF EXISTS your_proc; DELIMITER // CREATE PROCEDURE your_proc() BEGIN -- 这是中文注释 SELECT * FROM users; END // DELIMITER ;
注意：在执行这段代码前，确保你的客户端工具（如navicat、MySQL Workbench等）使用的也是 utf8mb4 字符集，否则注释依然可能显示为乱码。
三、处理导出/导入时的乱码问题
很多时候乱码出现在导出 SQL 文件再导入的时候。这时候要注意以下几点：
-
导出时指定字符集：
mysqldump -u user -p --default-character-set=utf8mb4 db_name > dump.sql
-
导入时也指定字符集：
mysql -u user -p --default-character-set=utf8mb4 db_name < dump.sql
-
检查 SQL 文件本身的编码格式，推荐使用 UTF-8（无 bom）或 UTF-8 with BOM（根据具体工具决定）
如果你用文本编辑器打开 SQL 文件看到的是乱码，那很可能文件本身的保存格式不对，可以用 notepad++ 或 vscode 转换编码后再导入。
四、验证是否修复成功
执行完上述操作后，可以使用以下方式验证：
- 执行 SHOW CREATE PROCEDURE proc_name; 看注释是否正常显示
- 在客户端调用存储过程，观察是否有警告或异常输出
- 如果使用了客户端工具（如 Navicat），刷新查看存储过程内容
基本上就这些方法了。MySQL存储过程的注释乱码虽然看起来小，但如果不注意编码一致性，很容易反复出现。关键是把各个层面的字符集统一起来，并在创建或导入时保持编码一致。
