视图查询慢的本质是外层WHERE条件未下推至基表扫描，导致中间结果物化；常见原因包括视图含GROUP BY/DISTINCT/UNION/窗口函数、嵌套过深、字段使用函数或MySQL设为TEMPTABLE算法。
视图查询慢，不是因为“视图语法有开销”，而是外层条件没下推、执行计划变差、中间结果被物化——本质是数据库优化器没把你的 WHERE 条件送到基表扫描那一步。
为什么加了 WHERE 的视图查询仍全表扫描
执行计划里出现 Table Spool（SQL Server）、Materialize（PostgreSQL）或 Using temporary（MySQL），基本可断定：视图被当成了独立中间结果集，而非逻辑展开。常见诱因包括：
- 视图定义含
GROUP BY、DISTINCT、UNION、窗口函数或标量子查询，强制优化器走物化路径 - 嵌套三层以上（如
v1 → v2 → v3），外层WHERE在第二层就失效 - 视图字段用了表达式（如
UPPER(name)）或函数（如YEAR(create_time)），导致基表索引无法命中 - MySQL 视图设为
ALGORITHM = TEMPTABLE（查SHOW CREATE VIEW可确认），直接绕过所有索引
如何验证谓词是否下推成功
别猜，要看实际执行计划里过滤动作落在哪一层：
- 在 SQL Server 中运行
SET STATISTICS XML ON，查<relop></relop>节点中EstimateRows和ActualRows是否接近；重点看Filter操作符是否出现在最底层的Clustered Index Scan或Index Seek之后 - 在 PostgreSQL 中用
EXPLAIN (ANALYZE, BUFFERS)，观察Rows Removed by Filter占比——如果高达 99%，说明过滤发生在物化后，而非扫描时 - 手动展开视图：用
sp_helptext 'view_name'（SQL Server）或pg_get_viewdef('view_name')（PG）拿到定义，拼成完整 SQL 再跑一次EXPLAIN，对比执行计划差异
跨服务器查视图为何比查基表慢一个数量级
根本原因是 SQL Server 对远程 VIEW 的基数估计硬编码为 10000 行，而对远程基表（如 LS1.DB.Sales.SalesOrderDetail）能通过 MSOLEDBSQL 驱动读取真实统计信息。结果就是：
- 查视图时优化器误选
Nested Loops，反复远程调用 - 查基表时能生成
Hash Join或合理Seek，且WHERE条件可下推 - 即使你控制不了远程库，也应避免写
SELECT * FROM LS1.DB.dbo.v_orders JOIN LS1.DB.dbo.v_customers——这会触发多次全量拉取，改用四部分命名直查基表 + 远程聚合
哪些优化手段容易被忽略但见效最快
很多团队花时间调参数、换驱动，却漏掉最基础的三点：
- 视图定义里删掉
SELECT *，只保留业务真正需要的字段——减少网络传输和内存占用，尤其跨服务器场景 - 检查基表索引字段顺序是否严格匹配高频
WHERE组合（如常查tenant_id = ? AND status = ?，索引必须是(tenant_id, status)，反过来可能只用上第一个字段） - MySQL 用户务必确认
ALGORITHM = MERGE（默认），一旦变成TEMPTABLE，哪怕加了WHERE user_id = 123也白搭
复杂点在于：视图本身不存数据、不建索引、不缓存执行计划——它只是个 SQL 模板。你看到的“慢”，其实是模板展开后生成的那个实际查询，在当前上下文里跑歪了。定位时盯住展开后的完整语句和执行计划，而不是视图定义本身。
