视图查询慢的根源是谓词未下推至基表扫描，导致物化中间结果集；典型表现为执行计划出现materialize/table spool/using temporary，诱因包括group by、distinct、union、窗口函数等破坏下推能力的结构。
视图查询比原表慢，不是因为“视图本身慢”，而是外层条件没落到基表扫描上——优化器没把 WHERE 推下去，结果先算完再过滤。
执行计划里出现 Materialize 或 Temp Table 就是铁证
PostgreSQL 里看到 Materialize 节点，SQL Server 里看到 Table Spool 或 Compute Scalar 后接大 Filter，MySQL 里 type = ALL 且 Extra 含 Using temporary，基本可断定：视图被当成了独立中间结果集，而非逻辑展开。
- 典型诱因：视图定义含
GROUP BY、DISTINCT、UNION、子查询或窗口函数，强制优化器走物化路径 - MySQL 尤其敏感：
ALGORITHM = TEMPTABLE会彻底绕过基表索引，哪怕你加了WHERE user_id = 123也无济于事 - 验证方式：运行
EXPLAIN (ANALYZE, BUFFERS)（PG）或SET STATISTICS XML ON（SQL Server），对比直接查基表的计划，看过滤是否出现在最底层扫描节点上
嵌套三层以上，谓词下推大概率失效
视图 A → B → C 嵌套时，优化器对中间结果集大小估算偏差极大，尤其某层用了 LIMIT、OFFSET 或聚合，会导致连接顺序错乱、驱动表选反，甚至放弃下推所有外层 WHERE 条件。
- 常见错误现象：外层加
WHERE status = 'active'，但执行计划里基表扫描节点仍显示rows = 1000000，而最后才有个Filter操作符筛出 10 行 - 根本原因：内层视图用了
SELECT *或含标量函数（如UPPER(name)），破坏了列的可下推性 - 快速验证：用
pg_get_viewdef('view_name')（PG）或sp_helptext 'view_name'（SQL Server）展开所有层级，手动拼出最终 SQL 再跑一次EXPLAIN
基表索引没配对，视图再简洁也白搭
视图不存数据，也不建索引——所谓“视图走索引”，本质是基表索引能否被复用。字段顺序错一位，下推就失败。
- 索引字段顺序必须严格匹配高频查询的
WHERE组合，例如常查WHERE tenant_id = 123 AND status = 'active'，索引就得建为(tenant_id, status)，反过来就可能只用上第一个字段 - 避免在视图字段中用表达式：
WHERE UPPER(name) = 'ABC'无法命中name索引；PG 可建函数索引CREATE INDEX idx_name_upper ON users (UPPER(name))，SQL Server 得用计算列 + 索引 - MySQL 8.0+ 支持隐藏索引，但前提是视图
ALGORITHM = MERGE（默认），一旦变成TEMPTABLE，索引完全失效
导出大结果集卡在 Sending data？不是磁盘问题，是结果集膨胀
MySQL 的 Sending data 状态常被误读为 IO 卡住，实际是服务端已算完，正把巨量结果逐行发给客户端——说明视图产出的数据远超预期。
- 典型诱因：视图里有
ORDER BY但没LIMIT，MySQL 必须全量排序后才开始发送；或客户端（Navicat/DBeaver）默认拉取全部结果再渲染 - 快速定位：执行
SELECT * FROM your_view LIMIT 1000，秒出则证明是结果集问题，不是查询慢 - 实操建议：命令行导出更可控 ——
mysql -u user -p -e "SELECT * FROM your_view WHERE ..." db_name > output.csv；禁用客户端“获取全部结果”选项，改成分页拉取
最易被忽略的一点：你以为在优化视图，其实是在调试优化器的下推逻辑。它是否下推，不取决于你写了什么，而取决于视图定义是否“干净”——有没有 SELECT *、有没有不可下推的函数、有没有破坏基数估算的聚合。每次改视图，都得重新看执行计划，不能凭经验猜。
