搞数据库的朋友可能都遇过这样的困惑：为什么我的视图，明明逻辑上写了过滤条件，执行计划却没法像存储过程那样，针对不同的查询条件做到参数化重用？这不是你操作失误，而是两个对象在数据库内部的执行机制，从根上就是两码事。今天就来把这个理儿彻底说清楚。

一句话总结：视图本身压根儿就不支持参数。你没法给它传个 @dept_id 之类的东西，所以执行计划根本就没法按参数值去差异化缓存。它每次都是“无参展开”，而存储过程天然就带着参数签名，优化器能根据参数统计信息生成并复用最适配的计划。这两者的工作流，完全不同。

视图没有参数签名，根本不存在“参数化重用”概念

视图说到底，不过是一个保存起来的 SELECT 语句文本。数据库在查询时，会直接把这个文本“内联”（inline）到你外部写的 SQL 里面，然后整体去编译。整个过程压根不走“参数绑定 → 计划缓存查找 → 复用或重编译”这套流程。我们常说的“执行计划重用”，那是针对带参数的对象（比如存储过程，或者参数化的 Ad-hoc 查询）而设计的机制，视图根本不在这个体系里。

举个例子就明白了：

• 你写 SELECT * FROM user_active_view WHERE dept_id = 5，SQL Server 实际编译的是整条展开后的 SQL，根本不是“调用视图 + 传参”。
• 退一步说，哪怕你反复执行 WHERE dept_id = 5 和 WHERE dept_id = 999，只要外部查询的文本不同（也就是字面量不一样），那就有可能触发两次独立的编译——除非数据库开启了自动参数化，并且正好满足条件，但这属于另外的机制了。
• 最关键的一点：视图定义里，语法上就不允许你声明 @dept_id 这类参数。这条路一开始就是堵死的。

存储过程有明确的参数契约，计划缓存可按签名匹配

再看存储过程。它从创建的那一刻起，就固化了参数名、类型和顺序，比如 CREATE PROC get_users_by_dept @dept_id INT。这等于给优化器签了个合同：@dept_id 就是一个变量占位符。优化器会基于这个占位符，编译一次计划。之后，所有对这个过程的调用，只要传的参数类型一致，数据库就会尝试去复用那个已编译好的计划——即使你传的实际值差异很大（这也是参数嗅探，parameter sniffing，问题的根源所在）。

这里有几个关键点：

• 计划缓存的键，包含的是过程名、参数类型、兼容级别等信息，它不依赖于你传的具体数值。
• 你还可以通过 WITH RECOMPILE 或者在调用时加 OPTION(RECOMPILE)，来精确控制何时需要重新编译。
• 而视图呢？它连“调用”这个动作本身都没有——它只是被展开，根本不存在一个独立的执行上下文。

想让视图行为接近参数化？得换载体

所以，如果你的业务逻辑真的需要参数驱动的复用与优化，那就必须跳出视图这个载体，改用真正支持参数的对象：

• SQL Server：用内联表值函数（CREATE FUNCTION dbo.users_by_dept(@dept_id INT) RETURNS TABLE）。这东西可以像视图一样嵌入 FROM 子句用，而且它确实支持计划缓存。
• PostgreSQL：用 RETURNS TABLE 的 SQL 函数，配合 STABLE 声明，优化器能够下推谓词并复用计划。
• MySQL：原生没什么好方案，要么靠应用层拼 SQL，要么升级到 8.0+ 后，用 PREPARE/EXECUTE 来模拟参数化效果。

还有一点需要警惕：千万别在视图定义里硬塞 WHERE 字句，试图“模拟参数化”。这种做法只会让你外层的过滤条件失效，最终引发全表扫描，得不偿失。

最后总结一下，也是最容易被忽略的一点：视图的“复用”，本质上是SQL逻辑的复用——你省了重复写JOIN语句的功夫。但这不是执行计划的复用，你依然没省掉数据库的计算开销。每次查询，数据库都得重新跑一遍底层的 SELECT。如果基表很大、JOIN很多、计算很重，性能瓶颈往往就藏在这里，而不是“参数没缓存”的问题。