报表性能优化关键在于按场景选技术：嵌套子查询需加别名且难优化，视图仅提升可读性不加速，物化视图才是提速核心，但需权衡刷新频率与实时性要求。
报表场景下，嵌套子查询和视图不是“选哪个更好”，而是“用错地方就拖慢整张报表”。真正关键的判断点是：这个查询是否被重复调用、是否需要预计算、是否对实时性有硬性要求。
嵌套子查询在FROM里必须加别名，否则直接报错
几乎所有主流数据库（PostgreSQL、MySQL 5.7+、SQL Server）都强制要求：子查询出现在FROM子句时，必须用AS alias显式命名。不加会立刻失败——比如 MySQL 报 ERROR 1248 (42000): Every derived table must have its own alias。
- 别名必须紧贴子查询右括号后写，
(SELECT 1) t合法，(SELECT 1)非法 - 别名若和外层字段名冲突（如外层有
id，内嵌视图也叫id），可能引发列解析歧义 - 三层以上嵌套时，优化器往往无法把
WHERE条件下推到最内层表，导致全量扫描后再过滤
普通视图只是查询定义，不解决性能问题
视图本质是保存在数据字典里的 SQL 文本，每次查询都会展开成等价的嵌套子查询。它能提升可读性和复用性，但不会加速执行——SELECT * FROM sales_summary_view 和直接执行视图背后的长 SQL，性能完全一样。
- 视图嵌套越深，优化器越难做条件下推，
EXPLAIN里常看到rows值远高于预期 - 如果视图底层用了
GROUP BY+ 多表JOIN，而你只查其中一两个字段，照样要算完整聚合 - 适合场景：简化开发、统一口径、权限隔离；不适合场景：高频访问、大数据量聚合报表
物化视图才是报表提速的关键落点
PostgreSQL 的 MATERIALIZED VIEW 是唯一能把复杂报表查询固化为物理表的方案。它把结果存下来，后续查询直接走索引或顺序扫描，响应时间从秒级降到毫秒级。
- 必须手动刷新：
REFRESH MATERIALIZED VIEW sales_monthly_summary，不能自动同步 - 适合“准实时”报表：比如每小时/每天刷新一次，用户查的是最新快照，不是严格实时数据
- 注意磁盘空间：物化视图占用实际存储，大宽表 + 高频刷新会快速吃掉空间
- 别忘了建索引：
CREATE INDEX ON sales_monthly_summary (department, year, month)，否则跟普通表一样慢
真正容易被忽略的点是：很多团队花大力气优化嵌套子查询的写法，却没意识到——只要报表逻辑不变、容忍分钟级延迟，用物化视图加定时刷新，比调优一百行 SQL 更有效。而一旦业务要求“数据必须随事务实时更新”，那连物化视图都不该用，得换流式计算或应用层缓存。
