视图查询执行计划抖动根本不是视图本身的问题，而是底层优化器因参数值分布差异或统计信息失真导致代价估算错误，复用为特殊值生成的低效计划；需通过局部变量绕过参数嗅探、及时更新统计信息、使用索引视图或应用层缓存来稳定性能。
视图查询执行计划抖动，根本不是视图本身的问题，而是底层优化器面对不同参数值时“猜错了代价”——它复用了为某个特殊值生成的计划，去处理另一个分布完全不同的值。
为什么视图调用会复用错误的执行计划
视图没有独立的执行计划缓存。每次查询视图，实际是把视图定义展开成原始 SQL，再走一遍优化器。如果外层查询用了参数（如 WHERE status = @p），而该参数值在首次执行时是高频值（比如 'Active' 占 95%），优化器就可能选索引扫描；后续传入低频值（如 'Cancelled' 仅占 0.1%），却仍复用扫描计划，导致读取几十万行才返回几条。
- SQL Server 的
OPTION (RECOMPILE)能解决，但代价是每次都要硬解析，CPU 上升明显 - Oracle 的绑定变量窥探（
bind peeking）默认只看第一个值，且若没直方图，ACS（Adaptive Cursor Sharing）根本不会触发 - MySQL 根本不缓存计划，每次都要重解析，但 CBO 能力弱，反而抖动不明显；真抖起来，往往是统计信息过期或函数导致索引失效
如何绕过参数嗅探干扰执行计划
不靠改数据库配置，而是从写法上切断“首次值决定一切”的链路：
- SQL Server：把输入参数赋给局部变量再使用，例如
DECLARE @status_local VARCHAR(20) = @status; SELECT * FROM my_view WHERE status = @status_local;—— 这样优化器无法窥探原始参数，会按“未知选择率”走更保守、更通用的计划 - PostgreSQL：用
PREPARE+EXECUTE组合不如直接拆成两个命名查询，对'All'和'SingleID'场景分别建视图或存储过程 - MySQL：避免在视图定义里写
WHERE status IN (@p1, @p2)，改用外层SELECT ... FROM my_view USE INDEX (idx_status)显式控制，Hint 必须写在外层，视图 DDL 里加无效
哪些统计信息信号必须立刻响应
别等慢了再查，盯住这几个硬指标：
-
SHOW TABLE STATUS LIKE 'orders'中的Rows和SELECT COUNT(*) FROM orders相差 >30%，说明统计信息严重失真 -
EXPLAIN结果中key_len是NULL或远小于索引定义长度，意味着本该走索引却没走 - 同一
sql_id在sys.dm_exec_query_stats（SQL Server）或v$sql（Oracle）里出现多个plan_handle/plan_hash_value，且平均逻辑读差异超 5 倍 - 基表刚执行过大批量
INSERT或DELETE（>10% 总行数），必须立刻UPDATE STATISTICS或ANALYZE TABLE
索引视图和应用层缓存比调 MAXDOP 有效得多
把 MAXDOP 从 0 改成 1 对视图抖动毫无作用——它只控制单条查询并行线程数，不解决计划误判、基数失真或排序争抢。
- SQL Server：对高频只读视图，加
WITH SCHEMABINDING后建唯一聚集索引，让结果物理化，彻底避开每次展开计算 - 所有数据库：在应用层用 Redis 缓存结果，key 为
view_name:md5(filter_params)，TTL 设 30 秒，能挡掉 80% 重复请求，见效比 DB 内调优快一个数量级 - 跨链接服务器的视图（如四部分命名
LS.db.sch.vw_orders），优化器固定按 10000 行估算，极易选错连接算法；直接查基表LS.db.sch.orders并加 Hint，往往更快
真正卡住性能的，从来不是语法糖或并发度设置，而是优化器看到的“数据画像”是否准确、外层调用是否无意中固化了偏差。计划抖动问题越复杂，越要回归到统计信息、参数传递方式、缓存层级这三个可验证、可干预的点上。
