视图查询慢本质是基表缺失索引或条件未命中索引，需用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 在真实表上跑得怎样——尤其是索引覆盖和条件下推这两个点，漏一个，优化就白做。
