视图导出慢的根本原因是基表未命中索引、条件未下推或中间结果膨胀，而非视图本身；EXPLAIN显示ALL/Seq Scan即表明全表扫描，必须立即优化索引与查询结构。
视图导出大数据量时性能线性衰减，根本不是视图“本身慢”，而是查询逻辑没被数据库高效执行——多数情况是索引没用上、条件没下推、或结果集膨胀失控。
为什么 EXPLAIN 显示 Seq Scan 或 ALL 就必须停手？
这是最直接的信号：数据库正在全表扫描基表，而不是走索引。视图只是封装了 SELECT，执行计划完全取决于底层表结构和 WHERE 条件是否命中索引。
-
EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=JSON（MySQL 8.0+）必须在加了导出条件后运行，例如SELECT * FROM my_view WHERE tenant_id = 123 AND created_at >= '2024-01-01' - 重点看
type（MySQL）或Node Type（PG）字段：出现ALL/Seq Scan且Rows Removed by Filter占比高，说明过滤发生在扫描之后，而非索引层 - 检查视图定义中
WHERE、JOIN ON、ORDER BY涉及的字段，是否都有索引；组合索引顺序是否匹配过滤优先级（如(tenant_id, created_at)比(created_at, tenant_id)更利于WHERE tenant_id = ? AND created_at > ?）
WHERE 条件加了却没生效？大概率是视图定义拦住了下推
视图一旦包含 GROUP BY、DISTINCT、窗口函数、多层子查询或 CTE，外部传入的 WHERE 很可能无法下推到基表，只能等整个视图结果产出后再过滤——数据量越大，中间结果越臃肿，性能越差。
- 执行
EXPLAIN对比：SELECT * FROM base_table WHERE ...vsSELECT * FROM my_view WHERE ...，如果后者多了Merge Join、Materialize或临时表节点，就是下推失败 - 避免在视图里写
SELECT *，只选导出真正需要的字段，减少中间结果集大小 - 高频筛选字段（如
tenant_id、org_id、日期范围）应直接固化进视图定义，而不是依赖导出时传参
MySQL 导出卡在 Sending data 状态，其实是结果集太大
这个状态不代表查询没跑完，而是 MySQL 已完成计算，正把巨大结果集逐行发给客户端——网络慢、客户端内存小、或 JDBC 默认缓存整结果集，都会拖垮体验。
- 启用流式查询：JDBC 连接串加
&useServerPrepStmts=false&defaultFetchSize=0，Java 侧调用statement.setFetchSize(Integer.MIN_VALUE) - 流式前提：不能有
ORDER BY（除非排序字段有覆盖索引且能索引扫描），不能中途commit或closeConnection - 如果必须分页导出，禁用
LIMIT OFFSET；改用基于主键/时间戳的游标分片，例如WHERE id > 1000000 ORDER BY id LIMIT 5000
别迷信物化视图，先确认刷新机制是否可控
PostgreSQL 的 MATERIALIZED VIEW 或 SQL Server 的索引视图看似能提速，但它们引入了新的复杂点：刷新时机、锁表风险、数据一致性延迟。
- PG 的
REFRESH MATERIALIZED VIEW CONCURRENTLY不锁读，但要求唯一索引且刷新期间无法并发写源表 - SQL Server 索引视图要求
SCHEMABINDING、严格 SET 选项，且INSERT/UPDATE/DELETE会触发维护开销，大表写入压力反而上升 - 更轻量的替代：用定时任务把高频导出逻辑结果写入临时表或分区表，导出时直查该表，并控制其生命周期
真正卡住的点，往往藏在“视图看起来干净，但执行计划层层嵌套”和“导出语句加了条件，数据库却假装没看见”这两处。优化不是改视图语法，而是让每一条过滤、每一次 JOIN，都落在索引的刀刃上。
