视图中使用GROUP BY会导致查询变慢，因为视图不存储数据，每次查询都需重新执行含聚合的SQL，扫描全表并生成中间结果；嵌套调用或JOIN时更易引发性能雪崩，EXPLAIN常显示Using temporary、Using filesort或type=ALL。

视图里用GROUP BY为什么一查就慢

因为视图本身不存数据，每次查询都得重跑整个SELECT——如果里面带GROUP BY、SUM、COUNT，数据库就得扫描所有原始行再聚合，中间结果集可能比原表还大。尤其当视图被嵌套调用或JOIN多次时，性能雪崩是常态。

常见错误现象：EXPLAIN看到Using temporary和Using filesort，rows值远超预期，甚至出现type = ALL（全表扫描）。

• 别在视图定义里直接写GROUP BY orders.user_id，除非你确认每次调用都只查最近7天数据且user_id上有高效索引
• 避免视图中包含未过滤的聚合，比如SELECT user_id, COUNT(*) FROM orders GROUP BY user_id——这等于强制全表扫描
• PostgreSQL视图默认不物化，MySQL视图在含聚合时自动退化为TEMPTABLE算法，性能损耗不可忽略

用CTE替代视图做预聚合更可控

把“视图里聚合”改成“查询前先聚合”，用WITH子句显式控制数据范围和分组粒度，避免隐式膨胀。

使用场景：报表类查询、BI工具拖拽生成的SQL、需要复用聚合逻辑但又不想维护物化表。

• WITH order_summary AS (SELECT user_id, COUNT(*) AS cnt, SUM(amount) AS total FROM orders WHERE created_at >= CURRENT_DATE - INTERVAL '30 days' GROUP BY user_id)——先筛时间再分组，数据量压到最低
• 确保GROUP BY字段和后续JOIN字段类型完全一致，比如都是BIGINT，别让数据库偷偷做CAST
• 如果主表要LEFT JOIN这个预聚合结果，记得用COALESCE(os.cnt, 0)补零，否则缺记录的用户会直接消失
• 不要依赖CTE自动优化：PostgreSQL会下推谓词，MySQL 8.0+才支持，老版本可能仍全量计算CTE

什么时候该建物化视图而不是改写SQL

只有当同一聚合逻辑被高频、并发、多端重复调用，且对实时性要求不高（分钟/小时级延迟可接受）时，才考虑物化视图。

性能影响：物化视图把计算成本从查询时转移到刷新时，读取速度接近普通表；但写入链路变长，需额外维护刷新任务和失败重试逻辑。

• PostgreSQL可用CREATE MATERIALIZED VIEW ... REFRESH CONCURRENTLY，支持增量刷新，锁表时间短
• MySQL不原生支持，得用CREATE TABLE AS SELECT + 定时EVENT或外部脚本，注意TRUNCATE + INSERT期间查询会中断
• 物化视图字段必须包含完整关联键（如user_id），不能只存非空记录，否则LEFT JOIN失效
• 刷新频率要匹配业务SLA：订单汇总每小时刷一次够用，用户活跃度统计可能需10分钟级

最容易被忽略的三个细节

预聚合能省90%扫描量，但漏掉下面任意一点，性能提升就归零。

• JOIN字段类型不一致：主表user_id INT，预聚合子查询输出user_id VARCHAR → 索引失效，回退全表扫描
• 复合索引顺序错位：预聚合表按(status, user_id)建索引，但JOIN条件是ON u.id = os.user_id AND os.status = 'paid' → 只能用上user_id单列索引
• NULL值没兜底：LEFT JOIN后直接用os.total，没包COALESCE(os.total, 0) → 结果少行，报表数字对不上