视图执行耗时波动源于优化器每次选择不同执行计划；SQL Server用局部变量阻断参数嗅探，MySQL需在外层查询加USE INDEX，PostgreSQL应拆分高频过滤为独立查询并监控统计信息准确性。
视图执行耗时波动大，根本不是视图本身在“变慢”，而是它背后展开的 SQL 每次被优化器编译时，选了不同的执行计划——有的快，有的慢，抖动就来了。固化执行计划不是给视图“打补丁”，而是绕过优化器的误判机制，让关键查询始终走同一条高效路径。
SQL Server：用局部变量切断参数嗅探
当视图被 WHERE status = @p 这类带参数的外层查询调用时，SQL Server 会“偷看”第一次传入的值（比如 @p = 'Active'），据此生成一个适合高频值的计划（如索引扫描）；后续传入低频值（@p = 'Cancelled'）却复用该计划，导致读几十万行才出几条结果。
- 不改应用代码的前提下，在调用视图前把参数赋给局部变量：
DECLARE @status_local VARCHAR(20) = @status; SELECT * FROM my_view WHERE status = @status_local; - 这样优化器无法窥探原始参数值，会按“未知选择率”估算，倾向选择更通用、更稳定的计划（如索引查找 + 嵌套循环）
- 慎用
OPTION (RECOMPILE)：虽能强制重编译，但每次执行都硬解析，CPU 上升明显，仅适用于极低频、参数差异极大的场景
MySQL：靠 Hint 显式控制索引，别信视图 DDL
MySQL 不缓存执行计划，每次都要重解析，所以“抖动”往往不是计划复用问题，而是 CBO（基于成本的优化器）能力弱 + 统计信息失真导致反复选错。视图定义里加 USE INDEX 或 FORCE INDEX 是无效的——Hint 必须写在外层查询中。
- 正确写法：
SELECT * FROM my_view USE INDEX (idx_status_created) WHERE status = ? AND created_at > ?; - 避免在视图定义里对索引列用函数，例如
WHERE DATE(created_at) = '2026-09-01'，这会让所有 Hint 失效 - 导出前先跑
EXPLAIN FORMAT=TREE，确认key和key_len是否符合预期；若key_len是NULL或远小于索引定义长度，说明根本没走索引
PostgreSQL：用 PREPARE + EXECUTE 不如拆成专用查询
PostgreSQL 的绑定变量窥探比 Oracle 弱，ACS（自适应游标共享）也不存在，所以“首次值决定一切”的问题不突出；但它对视图嵌套和 CTE 展开非常激进，超过 3 层后容易物化中间结果，导致计划失控。
- 不要依赖
PREPARE v AS 'SELECT * FROM my_view WHERE status = $1'; EXECUTE v('Cancelled');来稳定计划——这不能阻止查询重写，反而可能加剧嵌套膨胀 - 高频过滤场景（如
status IN ('Active', 'Pending')和status = 'Cancelled'）应拆成两个独立视图或存储过程，让优化器为每种模式单独生成计划 - 用
pg_get_viewdef('my_view')拿到原始定义，手动展开最内层基表查询，加EXPLAIN (ANALYZE, BUFFERS)对比真实耗时，才能定位是哪一层引入了 Materialize 节点
真正难处理的不是“怎么固化”，而是“什么时候该放弃固化”——当基表数据分布剧烈变化（比如某字段从均匀分布变成 99% 都是同一值）、或统计信息长期未更新时，任何固化手段都会变成性能枷锁。盯住 SHOW TABLE STATUS 的 Rows 和 COUNT(*) 差异是否超 30%，比死磕 Hint 更有效。
