mysql存储过程中的表名不会自动更新，需手动查找、修改并重建；执行rename table后，所有引用旧表名的存储过程仍含旧名，运行时报错“table 'db.old_name' doesn't exist”。
存储过程里用到的表名不会自动更新
MySQL 不像某些数据库（如 SQL Server）会自动追踪对象依赖关系。你执行 RENAME TABLE old_name TO new_name 或 ALTER TABLE old_name RENAME TO new_name 后，所有引用 old_name 的存储过程、函数、视图、触发器里的 SQL 字符串都还是旧名——运行时直接报错：Table 'db.old_name' doesn't exist。
必须手动查找并修改存储过程定义
MySQL 没有内置的“重命名并级联更新”功能，得靠自己定位、提取、替换、重建。关键步骤如下：
- 查出所有可能引用该表的存储过程：
SELECT ROUTINE_NAME, ROUTINE_DEFINITION FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA = 'your_db' AND ROUTINE_DEFINITION LIKE '%old_name%'; - 注意
ROUTINE_DEFINITION是 TEXT 类型，可能被截断（默认 64KB 限制），建议加SHOW CREATE PROCEDURE proc_name看完整定义 - 不能只靠字符串匹配——比如
user_old和old_name都会被LIKE '%old%'错杀，要结合上下文判断是否真在操作目标表 - 修改时优先用
CREATE OR REPLACE PROCEDURE（MySQL 8.0.23+ 支持），否则得先DROP PROCEDURE再CREATE，注意权限和调用链中断风险
替换时小心别破坏 SQL 结构和权限上下文
直接全局替换 old_name → new_name 很危险。常见翻车点：
- 表名带数据库前缀（如
mydb.old_name），只换后半段会导致跨库误引用 - 字段名或别名恰好同名（如
SELECT id FROM old_name AS old_name），盲目替换会让别名失效 - 存储过程中有动态拼接 SQL（
CONCAT('SELECT * FROM ', @tbl)），这种根本没法静态替换，得人工确认变量赋值逻辑 - 过程里用了
DEFINER = 'user'@'host'，重建后若没显式指定，会变成当前用户，可能引发权限不足
上线前必须验证调用链和事务行为
改完一个存储过程不等于万事大吉。真实环境里常有隐式依赖：
- 检查是否有其他存储过程、事件或应用代码通过
CALL调用它——名字没变，但内部表变了，语义可能已偏移 - 如果原表有外键约束，而新表没同步建（或引擎/字符集不同），过程里执行
INSERT会突然失败，错误不在过程本身而在 DDL 不一致 - 涉及事务的存储过程，表名变更后若没重测回滚路径，可能留下部分写入的脏数据
- 测试时别只跑 SELECT，重点覆盖 INSERT/UPDATE/DELETE + 异常分支（比如 WHERE 条件不命中时的处理）
最麻烦的不是改代码，是确认“哪些地方用了它”——尤其老系统里没人维护的定时事件或离线脚本，往往在你改完一周后才第一次跑，然后爆出来。
