GROUP BY视图强制MySQL物化临时表，导致WHERE条件无法下推、索引失效、全表扫描；应改用预聚合表、临时表或CTE提前过滤聚合。

视图里写GROUP BY会让MySQL强制物化临时表

MySQL无法把含GROUP BY的视图合并进外层查询，只能走TEMPTABLE算法：先完整执行视图SQL、生成中间结果集（内存或磁盘临时表），再对外层WHERE过滤。这意味着哪怕你只查最近1天的数据，它也会先把全量订单按用户聚合一遍。

常见错误现象包括：EXPLAIN中出现Using temporary和Using filesort；SHOW STATUS LIKE 'Created_tmp_tables'值飙升；并发稍高时tmp_table_size频繁被突破。

• MySQL 5.7/8.0对含GROUP BY的视图默认不MERGE，连索引下推（ICP）都会被禁用——EXPLAIN里Extra字段从Using index condition变成Using where
• 视图定义里只要带SELECT *、ORDER BY或跨表关联，物化开销会进一步放大
• 嵌套两层以上视图时，可能触发多个DERIVED节点，执行计划彻底失控

GROUP BY视图让WHERE条件无法下推到基表

外层加的WHERE created_at > '2026-10-25'根本进不了orders表扫描环节——因为视图已定义为SELECT user_id, SUM(amount) FROM orders GROUP BY user_id，优化器看不到原始created_at字段，更没法把它下推到InnoDB引擎层用索引过滤。

结果就是：全表扫描几十万行订单，分组后只剩几百行，但99%的数据白跑了。

• 联合索引(region, created_at)在视图上完全失效，哪怕外层WHERE region = 'CN'也触发不了ICP
• 如果视图SELECT列表没包含created_at，外层直接报错Unknown column 'created_at' in 'where clause'
• PostgreSQL虽支持在GROUP BY视图上建索引，但那只是加速视图自身查询，不恢复基表的索引能力

嵌套视图+GROUP BY会让优化器放弃代价估算

视图嵌套超过3层时，MySQL优化器直接退化为“猜策略”：不评估成本、不选择驱动表、不尝试谓词下推。你看到的EXPLAIN预估行数可能是100，实际扫描却是80万行——差3个数量级就是典型信号。

这种失控不是配置能救的。调大tmp_table_size或加索引，只是让“慢得更稳”，而不是变快。

• 检查执行计划是否出现多个DERIVED节点，或Materialize（PG）、Table Spool（SQL Server）
• EstimatedRows和ActualRows差距过大，说明优化器完全误判了数据分布
• CTE展平视图链时，禁止在中间CTE里写SELECT *或ORDER BY，否则同样触发全物化

真正有效的替代方案不是改写视图，而是重构数据流动路径

性能问题从来不是“视图写得不够巧”，而是数据在不该膨胀的时候膨胀了。先让中间结果变少，再让它连得快。

比如高频查询“各地区近7天订单总额”，不要写CREATE VIEW v_orders_by_region AS SELECT region, SUM(amount) FROM orders GROUP BY region，而应：

• 建预聚合表：CREATE TABLE orders_7d_summary AS SELECT region, SUM(amount) AS total FROM orders WHERE created_at >= '2026-10-27' GROUP BY region，并在region上建主键
• 用临时表接管中间结果：CREATE TEMPORARY TABLE tmp_orders_7d AS SELECT ...，显式定义字段类型（避免隐式转换导致索引失效）
• 用CTE把聚合提前：WITH recent_orders AS (SELECT * FROM orders WHERE created_at >= '2026-10-27'), grouped AS (SELECT region, SUM(amount) FROM recent_orders GROUP BY region) SELECT * FROM grouped JOIN regions USING(region)

最容易被忽略的一点：物化不是目的，可控才是。预聚合表要能增量更新，临时表要明确生命周期，CTE要确保中间结果粒度合理——否则只是把性能问题从视图层转移到了应用层。