视图查询慢的本质是外层where未下推至基表扫描层，导致先全量计算再过滤；常见诱因包括select*、group by、union、标量函数、多层嵌套及temptable算法，验证需依赖explain中materialize/using temporary等提示。
视图查询慢不是因为“用了视图”，而是WHERE没推到基表扫描层
视图本身不存数据、不建索引，也不额外耗资源——它只是保存了一段SQL。真正变慢的，是优化器没把外层WHERE条件下推到最底层的FROM表扫描上。结果变成：先全量算出视图结果（比如扫描千万行），再过滤，中间还可能物化成临时结果集。
典型铁证：EXPLAIN里看到Materialize（PostgreSQL）、Using temporary（MySQL）或Table Spool（SQL Server），就说明视图被当成独立中间结果处理了。
- 触发下推失败的常见写法：
SELECT *、GROUP BY、DISTINCT、UNION、窗口函数、标量函数（如UPPER(name)） - 嵌套两层以上视图时，下推成功率断崖式下降；三层嵌套基本等于放弃优化
- MySQL 的
ALGORITHM = TEMPTABLE（尤其含聚合时）会彻底绕过基表索引，哪怕加了WHERE id = 123也无效
跨链接服务器查视图，基数估计固定为100或1000，不是真实统计
对链接服务器上的视图执行SELECT * FROM [LS].db.schema.view WHERE x = 1，SQL Server 不会用远程表的真实统计信息估算行数，而是硬编码一个常量值：兼容级别 ≥ 120 时估 100 行，≤ 110 时估 1000 行。而查基表时能用直方图精准估算。
后果是：驱动表选错、连接顺序颠倒、本该走索引嵌套循环的地方强行哈希匹配，甚至生成巨大中间结果。
- 验证方式：
SET STATISTICS XML ON后看执行计划里的EstimateRows，对比查同名基表的值 - 临时解法：把视图定义复制出来，手动拼成远程基表查询（如
SELECT * FROM [LS].db.schema.table WHERE ...） - 长期规避：少用链接服务器上的视图，改用远程存储过程或定期同步本地表
临时表比视图快，但前提是建完立刻加索引
临时表真正快的关键不是“临时”，而是你能控制它的物理结构。视图没法建索引，临时表可以——而且必须建，否则后续JOIN或WHERE照样全表扫描，可能比视图还慢。
- MySQL：
CREATE TEMPORARY TABLE tmp AS SELECT ...后，立刻CREATE INDEX idx_col ON tmp(col) - PostgreSQL：推荐加
ON COMMIT DROP显式生命周期，避免会话异常中断后残留 - SQL Server：
SELECT * INTO #t FROM ...快但类型不精确；需严格控制时，改用CREATE TABLE #t (...); INSERT INTO #t SELECT ... - 注意引擎降级：MySQL
TEMPORARY TABLE默认用MEMORY引擎，但字段含TEXT/BLOB或单行超max_heap_table_size就自动落盘，IO 暴增
嵌套视图越深，执行计划越不可控
当出现 v_user_daily → v_user_weekly → v_user_monthly 这种链式依赖，优化器对中间结果集大小的估算偏差极大。某层用了 LIMIT 或聚合，会导致外层 WHERE 完全失效，基表扫描节点仍显示 rows=1000000，最后靠顶层 Filter 筛出 10 行。
更麻烦的是排查成本：你查 v_user_monthly 慢，SHOW CREATE VIEW 只给你当前层定义，看不到它依赖的 v_user_weekly 是怎么写的，链路断裂。
- 快速验证：用
pg_get_viewdef('v_user_monthly')（PG）或sp_helptext 'v_user_monthly'（SQL Server）逐层展开，拼出最终 SQL 再跑一次EXPLAIN - 替代方案：高频复杂逻辑优先用 CTE（多数引擎默认可内联），或拆成带命名的临时表步骤
- 根本原则：视图只适合单层、字段明确、无聚合、无函数的逻辑封装；一旦需要参数、强一致性或复用中间结果，就该换思路
真正卡住性能的，从来不是“视图语法”本身，而是你没验证过谓词是否下推、没检查过执行计划里有没有Materialize、也没意识到嵌套层级正在悄悄破坏优化器的估算能力。
