alter view 不会立即导致存储过程编译失败，而是在其首次执行时触发隐式重编译；若视图字段删除、类型不兼容或嵌套对象失效，则重编译报错，如“invalid column name”。
ALTER VIEW 本身不会让存储过程“编译失败”，但会让依赖它的存储过程在下次执行时触发隐式重编译，而重编译失败——这才是你看到“存储过程报错”的真实原因。
根本不是视图改了就立刻崩，而是存储过程调用时，SQL Server/MySQL/PostgreSQL 发现它引用的视图定义变了，于是尝试按新视图结构重新解析整个执行计划。一旦视图里有字段删了、类型不兼容、或嵌套了失效对象，这个重编译就会卡住并报错。
ALTER VIEW 后存储过程首次调用就报 “Invalid column name” 或 “Object not found”
这是最常见现象，说明存储过程体里直接用了视图的某个列（比如 SELECT user_name FROM v_users），但新视图里已把 user_name 改成 full_name，或该列被删了。
- 视图修改后，存储过程的缓存计划仍有效，但元数据已过期；首次调用时优化器会拉取视图最新定义来校验，发现列对不上，立刻中断
- MySQL 不报错但返回空结果或乱序字段，尤其当应用用
rs.getString(2)按索引取值时，极易读错列 - PostgreSQL 在执行
EXECUTE前就做PREPARE阶段校验，字段缺失直接拒掉
解决办法不是等报错再修，而是：
- 修改视图前，先查依赖：
SELECT <em> FROM pg_depend WHERE refobjid = 'v_users'::regclass</em>（PG）或sys.dm_exec_describe_first_result_set(N'SELECT FROM v_users', NULL, 0)（SQL Server） - 存储过程中所有对视图的引用，避免 SELECT *，必须显式列出字段，并和视图当前
DESCRIBE v_users输出逐项对齐
存储过程里用 SELECT * FROM v_complex，视图一改就慢得像卡死
视图不是快照，是实时展开的宏。你在存储过程中写 SELECT * FROM v_complex，等于把视图定义里的整段 SQL（含多层 CTE、JOIN、WHERE）原样塞进存储过程体里再优化。
- 如果新视图加了
GROUP BY或DISTINCT，外层WHERE条件无法下推，优化器被迫全表扫 - 视图若嵌套另一视图（
v_complex → v_base → users），字段变更可能只暴露在中间层，错误信息却只说invalid column in v_base，源头难定位 - MySQL 8.0 启用
ONLY_FULL_GROUP_BY后，原视图中SELECT id, name FROM t GROUP BY id会直接让依赖它的存储过程建不起来
建议：
- 把视图里可变的过滤条件（如
status = 'active'）抽成参数，由存储过程传入，而不是硬编码在视图里 - 真要复用逻辑，优先用 CTE 替代视图：
WITH v_base AS (SELECT ...) SELECT ... FROM v_base WHERE ...，调试路径清晰，无元数据滞后问题
为什么 sp_refreshsqlmodule 对视图依赖无效
sp_refreshsqlmodule 只刷新存储过程自身对表、函数、其他存储过程的依赖，但它不触碰视图定义的展开逻辑。视图是“SELECT 宏”，它的结构变化不会被 sp_refreshsqlmodule 扫描到。
- 运行它之后，存储过程依然会按旧视图结构去解析，遇到字段名不一致照样报错
- 真正有效的动作只有两个：
- 重建视图后，手动执行
ALTER PROCEDURE your_proc COMPILE（Oracle）或sp_recompile 'your_proc'（SQL Server）强制重编译 - MySQL 必须
DROP PROCEDURE+CREATE PROCEDURE，因为没有重编译机制
- 重建视图后，手动执行
视图和存储过程之间的耦合，本质是元数据强依赖。改视图不通知存储过程，就像改接口不更新调用方——没人自动帮你对齐。
