根本原因是sql server未自动同步元数据引用，重命名后sys.sql_modules中存储过程definition仍含旧名，解析阶段即报错；须用sp_refreshsqlmodule刷新或手动修改定义。
重命名数据库对象（如表、视图、列）后，存储过程仍报“对象名无效”或“列名无效”，不是因为缓存了旧执行计划，而是 SQL Server 没有自动更新存储过程中对这些对象的元数据引用——sys.sql_modules 里存的仍是旧名字的文本，解析时直接报错，根本走不到执行计划缓存那步。
SQL Server 中重命名对象后存储过程不生效的根本原因
存储过程在创建/修改时，会把引用的对象名以字符串形式硬编码进 definition 字段（查 sys.sql_modules 就能看到）。重命名表或列本身不会触发任何机制去扫描并改写这些字符串。所以即使你执行了 sp_rename 'OldTable', 'NewTable'，原存储过程里写的 SELECT * FROM OldTable 还在那儿，一执行就报错。
- 这不是执行计划缓存问题，而是**元数据未同步**：错误发生在解析阶段（parse），不是优化或执行阶段
-
sp_rename只改系统表里的对象名，不改任何用户代码中的文字引用 - 哪怕你用
ALTER PROCEDURE重编译一次，只要没手动改FROM OldTable这行，照样失败
如何安全修复被重命名影响的存储过程
不能靠清缓存或重编译解决，必须显式更新定义。SQL Server 提供了 sp_refreshsqlmodule，它会重新解析过程体，自动修正对已重命名对象的引用（前提是重命名是用 sp_rename 做的，且对象仍在同一 schema 下）。
- 对单个过程：运行
EXEC sp_refreshsqlmodule 'usp_GetUserData' - 对所有含某旧名的过程：先查出它们
SELECT OBJECT_NAME(object_id) FROM sys.sql_modules WHERE definition LIKE '%OldTable%'，再批量执行sp_refreshsqlmodule - 如果过程里用了动态 SQL（
EXEC(@sql)），sp_refreshsqlmodule不起作用——字符串拼接的内容不会被解析，得手动改 - 该命令不改变过程逻辑、权限或加密状态，只刷新依赖关系
MySQL 为什么没有这个问题
MySQL 存储过程不缓存执行计划，每次执行都实时解析 + 优化。但更重要的是：sp_rename 在 MySQL 里根本不存在——它的重命名操作（RENAME TABLE、ALTER TABLE ... RENAME COLUMN）是 DDL，会直接让所有引用该表的过程在下次调用时抛出 ERROR 1146 (42S02): Table doesn't exist，错误更早、更明确，不会“静默使用旧缓存”。
- MySQL 没有等价于
sp_refreshsqlmodule的命令，必须手动DROP PROCEDURE+CREATE PROCEDURE - 别指望
ALTER PROCEDURE能自动适配表名变更；它只是替换整个定义，不解析内容 - ORM 层（如 MyBatis、Django ORM）若缓存了存储过程元数据，也要同步清理，否则可能连 CALL 都发不出
最常被忽略的一点：sp_refreshsqlmodule 只能修“对象名变更”，修不了“字段类型变更”或“约束删除”。比如你删了一个列，过程里还 SELECT deleted_col FROM...，刷新后依然报错——它不检查语义合法性，只做名称映射。真正安全的做法永远是：改完对象 → 扫描所有相关存储过程 → 人工确认逻辑是否仍成立 → 再刷新或重写。
