SQL Server存储过程不会自动感知表结构变更，需用sp_refreshsqlmodule刷新元数据；字段存在但性能差则需sp_recompile或OPTION(RECOMPILE)；MySQL无等价命令，须重创SP；临时表#temp在SP中不可见，应改用表变量。
SQL Server 存储过程不会自动感知表结构变更，新列加完后直接在 SELECT 或 INSERT 里引用，大概率报“列名无效”——这不是语法错，是元数据没刷新。
为什么 sp_refreshsqlmodule 是第一反应
存储过程创建后，SQL Server 把它依赖的表、列、类型等信息固化在 sys.sql_modules 和依赖图里，后续改表（增/删/改列）不会触发自动重绑定。调用时发现字段不存在，就直接报错，不给你运行机会。
-
sp_refreshsqlmodule强制重新解析存储过程体，校验所有引用对象是否存在、列名是否拼对、类型是否兼容，并更新内部元数据 - 它不改变执行计划，也不影响缓存，开销极小，适合生产环境快速修复
- 必须用完整三段式名称：比如
EXEC sp_refreshsqlmodule N'dbo.usp_GetUserDetail'；只写usp_GetUserDetail会报“找不到对象” - 适用于
CREATE OR ALTER PROC后忘了刷新，或 DBA 先改了表、开发再改 SP 的典型协作断点
什么时候不能靠刷新，得重编译
如果字段确实存在、拼写也对，但查询性能突然暴跌（比如该走索引却全表扫描），说明旧执行计划过期了，这时 sp_refreshsqlmodule 无效，要换思路：
-
sp_recompile只是标记“下次执行前强制重编译”，不碰元数据，适合统计信息更新、索引新增后的计划优化 - 更可控的方式是在调用处加
OPTION (RECOMPILE)，或在存储过程定义里加WITH RECOMPILE - 批量处理慎用游标遍历
sys.procedures调sp_recompile，高并发下可能引发编译风暴
MySQL 用户注意：没有等价命令
MySQL 完全不提供元数据刷新机制。存储过程定义一旦落库，就和建表那一刻的结构锁死：
- 字段新增后直接在 SP 里用，必然报
Unknown column 'xxx' in 'field list' - 必须显式执行
DROP PROCEDURE IF EXISTS xxx+CREATE PROCEDURE xxx - 如果用 ORM（如 MyBatis、Laravel Eloquent），还要确认连接池是否缓存了预编译语句；部分驱动首次解析
CALL时会固化参数元信息，改完 SP 后需清空连接池或重启应用
最容易被忽略的一点：临时表和本地 #temp 的作用域陷阱
如果你在存储过程中试图引用一个前面刚 CREATE TABLE #temp 的本地临时表，保存就报“对象名无效”，这不是列名问题，是作用域根本不对：
- #temp 只在当前批处理内可见，而存储过程是独立编译单元，SQL Server 编译时压根看不到它
- 别指望把
CREATE TABLE #temp和SELECT * FROM #temp塞进同一个存储过程里——这在语法检查阶段就失败 - 真要用临时结构，优先选表变量（
@temp_table）或INSERT INTO @t EXEC proc_name；非用临时表不可，才考虑带@@SPID的##temp，但得手动加IF OBJECT_ID('tempdb..##temp') IS NOT NULL DROP TABLE ##temp
