克隆存储过程本质是重写而非复制，需用SHOW CREATE PROCEDURE导出定义，手动替换库名、调整DEFINER、处理依赖对象后重新创建。
克隆存储过程本质是重写，不是复制
MySQL 没有 CLONE PROCEDURE 或类似语法，所谓“克隆”只能靠导出定义 + 手动修改 + 重新创建。直接 CREATE PROCEDURE 语句不能跨库自动适配，必须显式替换数据库名、调整权限上下文、处理依赖对象（如表、函数）。
用 SHOW CREATE PROCEDURE 提取原始定义
这是最可靠的第一步。它返回带完整 CREATE PROCEDURE 语句的字符串，包含参数、逻辑、分隔符设置等细节：
SHOW CREATE PROCEDURE old_db.pro_findById;
注意返回结果中可能含以下关键信息：
-
DEFINER=`user`@`host`—— 若新库用户不存在或权限不同，必须删掉或改写成DEFINER=CURRENT_USER -
old_db.table_name这类带库名的表引用 —— 不改会导致在新库执行时报Table 'old_db.xxx' doesn't exist -
DELIMITER设置（如$$）—— 复制时若没同步改分隔符，会导致语法错误
手动修改并执行到目标库的三处必改点
拿到 SHOW CREATE PROCEDURE 输出后，至少做这三件事才能让过程在新库可用：
- 把所有
old_db.前缀替换成new_db.，包括SELECT、INSERT、UPDATE中的表名；如果过程里用了视图或函数，也得一并检查是否存在于新库 - 删掉或重写
DEFINER子句：直接删掉整段（MySQL 会默认用当前用户），或改成DEFINER=CURRENT_USER，避免因用户不存在报错Access denied; you need (at least one of) the SUPER privilege(s) - 确保新库已存在同名过程：先执行
DROP PROCEDURE IF EXISTS new_db.pro_findById;，再执行修改后的CREATE PROCEDURE；否则会报ERROR 1304 (42000): PROCEDURE pro_findById already exists
容易被忽略的权限与上下文问题
即使语法完全正确，克隆后调用仍可能失败，常见原因有：
- 新库用户缺少对目标表的
SELECT/INSERT权限 ——CREATE PROCEDURE成功不代表能执行，需单独授权：GRANT SELECT, INSERT ON new_db.employee TO 'user'@'%'; - 过程体里用了
SELECT ... INTO @var或SET @x = ...等用户变量 —— 这些变量作用域是会话级，跨库不影响，但若原过程依赖旧库的会话变量初始化逻辑，就得补上SET @x = DEFAULT_VALUE; - 过程里调用了其他存储过程或函数，而它们未在新库中重建 —— 错误信息通常是
PROCEDURE new_db.other_proc does not exist，得按依赖顺序逐个克隆
真正麻烦的从来不是语法，而是过程内部隐含的库依赖、权限链和变量生命周期 —— 这些不会出现在 SHOW CREATE 输出里，只能靠读逻辑+试运行暴露。
