视图查询慢本质是基表缺失索引或条件未命中索引，需用EXPLAIN分析执行计划，重点检查全表扫描、索引顺序、函数导致索引失效等问题，并优化CTE嵌套与条件下推。

视图查询慢，本质是底层表没走索引

SQL 视图本身不存数据，只是保存了 SELECT 语句。导出慢，90% 是因为视图里涉及的基表缺少合适索引，或者查询条件没落到索引字段上。

先用 EXPLAIN（MySQL）或 EXPLAIN ANALYZE（PostgreSQL）看执行计划，重点盯 type（MySQL）或 Node Type（PG）字段：如果出现 ALL 或 Seq Scan，基本就是全表扫描了。

• 检查视图定义中 WHERE、JOIN、ORDER BY 涉及的字段，是否都有单列索引或组合索引
• 注意索引顺序：比如 WHERE status = 'active' AND created_at > '2024-01-01'，(status, created_at) 比 (created_at, status) 更有效
• 避免在索引字段上用函数，例如 WHERE DATE(created_at) = '2024-05-01' 会跳过索引，改用 WHERE created_at >= '2024-05-01' AND created_at

导出时加 WHERE 条件但没生效？检查视图定义是否固化了逻辑

有些视图用了 GROUP BY、DISTINCT、子查询或窗口函数，会导致外部加的 WHERE 条件无法下推到基表，只能等视图结果产出后再过滤——数据量一大就卡死。

执行 SELECT * FROM your_view WHERE ... 后再看执行计划，对比直接查基表的计划，如果多了一层临时表或 Materialize 节点，大概率是下推失败。

• 优先把高频筛选字段（如 tenant_id、date_range）提前写进视图定义里，而不是靠导出时传参
• 避免在视图里用 SELECT *，只选真正需要的字段，减少中间结果集大小
• PostgreSQL 用户可尝试用 MATERIALIZED VIEW，但要注意刷新时机和锁表现

MySQL 导出大视图卡在 Sending data 状态

这个状态不是卡在磁盘 IO，而是 MySQL 正在构造结果集并逐行发送给客户端——说明查询本身已跑完，但结果集太大或网络/客户端处理慢。

典型诱因是视图里有 ORDER BY 但没 LIMIT，MySQL 必须把全部结果排序完才开始发；或者客户端（比如 Navicat、DBeaver）默认拉取全部结果再渲染。

• 导出前加 LIMIT 测试：比如 SELECT * FROM your_view LIMIT 1000，看是否秒出。如果快，说明是结果集膨胀问题
• 用命令行导出更可控：mysql -u user -p -e "SELECT * FROM your_view WHERE ..." db_name > output.csv
• 禁用客户端自动格式化，关闭“获取全部结果”选项，改成分页拉取

PostgreSQL 视图嵌套深导致性能断崖

PG 对视图展开较激进，但嵌套超过 3 层后，查询重写可能失效，优化器容易选错执行路径，尤其遇到 CTE（WITH 子句）时，默认行为是物化中间结果，哪怕你只想要前 10 行。

用 EXPLAIN (ANALYZE, BUFFERS) 对比带 WITH 和不带 WITH 的执行计划，注意 CTE Scan 节点的 Actual Rows 是否远超预期。

• 把关键过滤条件尽量提到最外层 WHERE，不要藏在内层 CTE 里
• 对确定要复用的 CTE，显式加 MATERIALIZED；对简单逻辑，直接展开成子查询，避免 PG 自动物化
• 检查是否有 UNION ALL 类视图，没加 WHERE 就导出，等于合并多个大表

视图不是魔法，它只是 SQL 的别名。慢的时候，别急着调优视图本身，先看它背后那几条 SELECT 在真实表上跑得怎样——尤其是索引覆盖和条件下推这两个点，漏一个，优化就白做。