sql server 存储过程不会自动感知表结构变更，新增字段需手动执行 sp_refreshsqlmodule 刷新元数据；sp_recompile 仅重编译执行计划，不更新元数据；mysql 无等价命令，必须重建存储过程；临时表作用域限制需注意。
SQL Server 存储过程编译后不会自动感知表结构变更，新增字段在 SP 里直接引用会报 Invalid column name，这不是语法错误，是元数据没刷新——必须手动触发重新绑定。
sp_refreshsqlmodule 是第一反应
存储过程创建或 CREATE OR ALTER PROC 后，SQL Server 把它依赖的列名、类型等信息固化在 sys.sql_modules 和依赖图里；后续对基表执行 ALTER TABLE ... ADD COLUMN 不会触发自动重校验。
- 执行
EXEC sp_refreshsqlmodule N'dbo.usp_GetOrderDetail'强制重新解析 SP 体，检查所有列是否存在、拼写是否正确、类型是否兼容，并更新内部元数据 - 必须用三段式名称（
schema.object_name），只传usp_GetOrderDetail会报 “找不到对象” - 不改变执行计划、不清缓存、不开销，适合生产环境快速修复
- 适用于 DBA 先改表、开发后改 SP 的协作断点，或忘记在
CREATE OR ALTER后手动刷新
sp_recompile 解决的是另一类问题
字段存在、拼写也对，但查询性能突然变差（比如该走索引却全表扫描），说明旧执行计划过期了——这时 sp_refreshsqlmodule 无效，得换思路。
-
sp_recompile只是标记“下次执行前强制重编译”，不碰元数据，适合统计信息更新、新索引上线后的计划优化 - 更可控的方式是在调用语句末尾加
OPTION (RECOMPILE)，或在 SP 定义里加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 在 SP 中不可见
这不是字段识别问题，而是作用域陷阱：本地临时表 #temp 只在当前批处理内可见，而存储过程是独立编译单元，SQL Server 编译时根本看不到它。
- 在 SP 内部
CREATE TABLE #temp后直接SELECT * FROM #temp是合法的 - 但如果试图在 SP 外部先建
#temp，再调用 SP 并在 SP 里引用它，保存就报Invalid object name '#temp' - 应改用表变量
@temp_table或全局临时表##temp（注意并发安全）
最容易被忽略的不是命令怎么写，而是刷新动作本身需要完整限定名、且不能跨数据库上下文执行；另外，任何涉及 SELECT * 的 SP 或视图，都埋着字段错位或漏显的隐患——显式列出字段才是防错底线。
