真正卡顿的根源是JOIN生成的中间结果集太大，而GROUP BY被迫在几十万行上执行；应先通过CTE或子查询将高选择性条件（如时间）下推至JOIN前过滤，再确保GROUP BY字段有合适索引或来自驱动表。
直接改视图或加索引通常没用，真正卡顿的根源是JOIN生成的中间结果集太大，而GROUP BY被迫在几十万行上执行——你得先让数据变少，再让它连得快。
为什么EXPLAIN里rows暴增但GROUP BY后只剩几百行
这是最典型的信号：JOIN先膨胀、GROUP BY后收缩。比如orders和order_items两表JOIN后才按user_id分组，但业务只要最近7天数据——数据库却先把全部历史订单连完，再筛时间。
- 用
EXPLAIN FORMAT=TRADITIONAL确认rows字段：如果JOIN输出行数远超最终分组数（如100万→1千），说明大量冗余数据参与了聚合 - 检查
Extra列是否含Using temporary或Using filesort，这代表MySQL正在磁盘临时表里硬排序分组 - WHERE条件没下推到JOIN子查询里，而是写在外层，导致过滤动作被挪到了GROUP BY之后
怎么把过滤提前到JOIN之前
别让数据库先连再筛。高选择性条件（如时间、状态）必须压进子查询或CTE，而不是留在外层WHERE。
- 用CTE显式拆解：先
WITH recent_orders AS (SELECT user_id, amount FROM orders WHERE created_at >= '2026-08-20' GROUP BY user_id, amount)，再和users表JOIN - 避免在FROM里直接嵌套子查询却不显式SELECT关键JOIN字段——
ON u.id = o.user_id会报错“column not found”，因为子查询没暴露user_id - 如果必须用子查询，确保它带
GROUP BY且不带ORDER BY（MySQL 5.7不优化子查询里的ORDER BY）
GROUP BY字段没走索引？先看JOIN顺序和覆盖索引
MySQL/PostgreSQL对GROUP BY的优化依赖排序能力。如果分组字段无法利用索引天然有序，引擎就得额外做Sort操作，性能差一个数量级。
- 确保
GROUP BY字段全部来自驱动表（LEFT JOIN的左表），且该表上有联合索引，如(user_id, status, order_id) - 如果必须按从表字段分组（如
products.category_name），给从表建索引时把JOIN键前置：CREATE INDEX idx_cat_on_prod ON products(category_name, id) - 别在
GROUP BY里用函数：GROUP BY DATE(created_at)会让整个索引失效；改用冗余日期字段或范围查询替代
临时表比硬扛视图更可控
当视图涉及5张以上表、且无法重构时，临时表是最快落地的降级方案——它把“每次展开+重算”变成“一次固化+快速关联”。
- 先
CREATE TEMPORARY TABLE tmp_user_summary AS SELECT user_id, SUM(amount) AS total FROM orders WHERE created_at >= '2026-08-20' GROUP BY user_id - 立刻加索引：
ALTER TABLE tmp_user_summary ADD INDEX idx_user_id (user_id)，注意字段类型要显式对齐（如BIGINT别隐式转成INT） - 后续查询改走这个临时表：
SELECT u.name, t.total FROM users u JOIN tmp_user_summary t ON u.id = t.user_id
最容易被忽略的一点：GROUP BY慢，往往不是因为没索引，而是数据流动路径设计错了——你在给百万行中间结果加速，而不是让百万行根本不出现在内存里。
