视图+GROUP BY比原表慢，因其不缓存结果、无法下推WHERE条件、强制每次全量聚合并常触发Using temporary/Using filesort。
视图里加 GROUP BY 不是语法问题，而是把底层表的分组压力原封不动传给了每次查询——视图不缓存、不物化，每次调用都重跑全量聚合。
为什么视图 + GROUP BY 会比原表直接 GROUP BY 还慢
视图本质是保存的 SQL 语句，不是真实表。当你在视图定义里写 GROUP BY，等于把聚合逻辑“固化”进视图结构；而调用该视图时（比如 SELECT * FROM v_user_stats），MySQL/PostgreSQL 必须先展开视图 SQL，再执行完整聚合流程——哪怕你只取其中一列，也得扫全表、建临时表、排序分组。
- 原表查询可灵活加
WHERE过滤后再分组，视图里的GROUP BY却常缺少前置过滤条件，导致每次都处理全部数据 - 视图无法利用外层
WHERE下推优化：比如SELECT * FROM v_user_stats WHERE region = 'CN'，若视图定义没包含region字段或未在GROUP BY前过滤，优化器大概率无法将region = 'CN'下推到聚合前 - MySQL 视图不支持索引，PostgreSQL 的物化视图需手动刷新且不自动更新，二者都无法靠索引加速分组过程
EXPLAIN 显示 Using temporary / Using filesort 就说明已失控
对视图执行 EXPLAIN，只要 Extra 列出现 Using temporary 或 Using filesort，就证明数据库已放弃索引直取，正在内存或磁盘上硬扛分组。这不是配置能调好的问题，而是访问路径本身失效：
- 即使原表有
(user_id, created_at)索引，视图里写GROUP BY DATE(created_at)也会让该索引完全失效 - 视图中若含
JOIN+GROUP BY，且关联字段无索引，Using temporary几乎必然出现 - PostgreSQL 中若
work_mem不足，还会额外显示Sort Method: external merge，这是磁盘排序的明确信号
替代方案：用物化中间表或 CTE 替代视图内 GROUP BY
真正可控的做法，是把“聚合动作”从视图定义里移出来，交给调用方或定时任务控制：
- 用
CREATE TEMPORARY TABLE或CREATE TABLE AS预算好高频聚合结果，比如每日凌晨跑INSERT INTO daily_stats SELECT region, COUNT(*) FROM orders GROUP BY region - 在业务查询中改用 CTE：
WITH stats AS (SELECT region, COUNT(*) c FROM orders WHERE status = 'paid' GROUP BY region) SELECT * FROM stats WHERE region = 'US'——CTE 支持下推过滤，且不会固化低效逻辑 - MySQL 8.0+ 可建不可更新视图，但务必确保视图定义中不含函数、范围条件或非等值 JOIN，否则仍无法下推
最容易被忽略的一点：视图里嵌套 GROUP BY + ORDER BY，等于双重排序开销
很多人在视图里写 GROUP BY x ORDER BY x，以为能保证输出顺序。但 MySQL 默认对 GROUP BY 结果隐式排序，再加显式 ORDER BY 会导致两次排序：一次为分组准备，一次为最终输出。更糟的是，如果视图被嵌套在子查询中，这个排序可能完全白做——外层 ORDER BY 会覆盖它，而性能代价已经产生。
