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要确保中间结果粒度合理——否则只是把性能问题从视图层转移到了应用层。
