真正卡顿的根源是视图中“先JOIN再GROUP BY”的执行顺序，导致数据库在聚合前加载大量冗余数据；应将聚合提前固化、视图仅作轻量关联，或用临时表/预聚合表优化数据流动路径。
直接改视图定义几乎没用——真正卡住的是“先JOIN再GROUP BY”这个执行顺序，数据库被迫把几十万行中间结果全拉出来才开始聚合。
为什么视图里写GROUP BY就慢
视图不存数据，每次查询都展开成原始SQL。如果视图定义是 SELECT u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id GROUP BY u.id，MySQL 就得先把所有用户和订单的匹配组合生成一遍，哪怕你只查最近3天的数据。
-
EXPLAIN里rows显示 287641，但GROUP BY后只剩 321 行 → 白跑 99.9% 的数据 - 视图里用了
SELECT *或跨表ORDER BY，会强制回表、建临时表、文件排序 - MySQL 5.7 不会把外部
WHERE created_at > '2026-05-25'下推到 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），比每次展开更稳
临时表替代复杂视图的实操路径
当视图涉及 5 张以上表、且无法重构时，临时表是最可控的降级方案。
- 先
CREATE TEMPORARY TABLE tmp_user_orders AS SELECT user_id, SUM(amount) AS total FROM orders WHERE created_at >= '2026-05-25' GROUP BY user_id - 立刻加索引：
ALTER TABLE tmp_user_orders ADD INDEX idx_user_id (user_id)，注意字段类型显式对齐（比如user_id是BIGINT，别让它隐式转成INT） - 后续查询改走临时表：
SELECT u.name, t.total FROM users u JOIN tmp_user_orders t ON u.id = t.user_id
最常被忽略的一点：视图性能问题从来不是“加个索引就能好”，而是数据流动路径设计错了——你得先让数据变少，再让它连得快。否则索引再好，也是在给百万行中间结果加速排序。
