视图上直接 GROUP BY 几乎必然导致性能断崖，因数据库会展开视图并执行“先 JOIN、后聚合”的低效路径，造成大量中间行白加载、白排序、白分组，且 WHERE 条件无法下推、索引易失效；应将聚合提前至 JOIN 前，用 CTE、预聚合表或临时表优化。
视图上直接 GROUP BY 几乎必然导致性能断崖——不是因为视图本身慢，而是数据库每次都会把整个视图定义展开成原始 SQL，再执行“先 JOIN、后聚合”的低效路径。
视图不存数据，GROUP BY 却被迫处理全量中间结果
视图只是保存的 SQL 语句模板，不缓存结果。当你写 SELECT name, COUNT(*) FROM user_orders_view GROUP BY name，MySQL 实际执行的是视图定义里完整的 JOIN + SELECT *，哪怕你只想要最近 1 天的数据。
- EXPLAIN 显示
rows是 287641，但GROUP BY后只剩 321 行 → 99.9% 的中间行白加载、白排序、白分组 - 如果视图里有
ORDER BY或SELECT *，还会强制回表、建临时表、触发Using filesort - MySQL 5.7 不会把外部
WHERE created_at > '2026-05-25'下推到视图内部的JOIN前过滤，条件全堆在最后
GROUP BY 字段顺序和索引不匹配，索引完全失效
即使你在底层表上建了索引，只要视图展开后的实际查询字段顺序与索引最左前缀不一致，优化器就无法利用索引避免排序和临时表。
- 错误示例：视图定义含
GROUP BY status, user_id，但索引是(user_id, status)→ 索引对分组无效 - 正确索引必须是
(status, user_id)，且若还有WHERE shop_id = 123，则应为(shop_id, status, user_id) - 一旦出现
EXTRA: Using temporary; Using filesort，说明 MySQL 已放弃有序扫描，改用磁盘临时表
替代方案：把聚合提前，视图只做轻量拼接
真正有效的解法不是给视图加索引，而是重构数据流动路径——让聚合发生在 JOIN 之前，而不是之后。
- 用 CTE 或派生表把聚合单独拎出：
SELECT user_id, SUM(amount) FROM orders WHERE created_at >= '2026-05-25' GROUP BY user_id - 视图定义只保留简单关联：
SELECT u.name, u.level, COALESCE(o.sum_amount, 0)，禁用DISTINCT、ORDER BY、函数表达式 - 高频复用场景优先建物理预聚合表（如
orders_7d_summary），字段类型显式对齐（BIGINT别隐式转INT） - 临时表是兜底方案：
CREATE TEMPORARY TABLE tmp_user_orders AS ...，立刻加INDEX idx_user_id (user_id)
最容易被忽略的一点：问题从来不在“要不要加索引”，而在于“数据是不是在聚合前就已经膨胀到百万行”。索引再好，也只是加速对垃圾数据的排序——先让数据变少，再让它连得快。
