视图中使用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)→ 结果少行，报表数字对不上
