MySQL迁移后存储过程异常，通常不是语法错误，而是环境差异导致的权限、SQL模式、字符集或系统变量不一致。重点检查这四类问题，多数能快速定位。
权限不足导致过程无法执行
迁移后用户可能缺少EXECUTE权限，或对涉及的表缺少SELECT/INSERT/UPDATE/DELETE权限。即使原库有权限，新库需重新授权。
登录新库，执行SHOW GRANTS FOR '用户名'@'主机';确认权限是否完整 补充授权：GRANT EXECUTE ON PROCEDURE db_name.proc_name TO 'user'@'host'; 若过程内操作多张表，逐个检查对应表的DML权限是否到位SQL模式（sql_mode）不兼容
旧库可能关闭了严格模式（如禁用STRICT_TRANS_TABLES），而新库默认启用，导致INSERT INTO ... SELECT或隐式类型转换失败。
对比两库：SELECT @@sql_mode; 临时调试可临时放宽：SET sql_mode = 'NO_ENGINE_SUBSTITUTION'; 长期建议修改过程逻辑，避免依赖宽松模式（如显式处理NULL、补全字段列表）字符集与排序规则不一致
过程内含中文参数、临时表或字符串拼接时，若数据库/连接/过程体的字符集不统一（如utf8mb4 vs utf8），易出现乱码或比较异常。
检查过程创建时的连接字符集：SHOW CREATE PROCEDURE proc_name;观察CHARACTER SET声明 确保新库默认字符集为utf8mb4：SHOW VARIABLES LIKE 'character_set_database'; 创建过程前显式指定：SET NAMES utf8mb4;再执行CREATE PROCEDURE系统变量或函数行为变化
高版本MySQL（如8.0+）废弃或调整了部分函数（如PASSWORD()）、变量（如sql_log_bin默认值），或新增安全限制（如log_bin_trust_function_creators）。
检查是否报This function has none of DETERMINISTIC...：需设置SET GLOBAL log_bin_trust_function_creators = 1; 替换已弃用函数，例如用SHA2('str',256)替代PASSWORD() 确认过程内调用的系统变量在新版本中是否仍有效（如@@hostname在某些托管环境受限）
