真正卡顿的根源是视图中“先join再group by”的执行路径，导致数据库加载大量冗余中间数据；应将聚合提前固化、视图仅作轻量关联，并用临时表或预聚合表优化数据流动路径。
视图里先JOIN再GROUP BY，就是性能杀手
真正卡顿的根源不是视图本身，而是定义里写了SELECT ... FROM a JOIN b ON ... GROUP BY ...这种结构——数据库被迫先把所有匹配行全拉出来，再聚合。比如users和orders各10万行，JOIN后中间结果可能暴涨到百万级，但GROUP BY user_id后只剩几百行。EXPLAIN里rows字段爆高、filtered低于5%，基本就是这个病。
别指望加索引能救回来：索引再快，也是在给那几百万行中间结果加速排序，治标不治本。
- 把聚合逻辑拆出视图：先用
SELECT user_id, SUM(amount) FROM orders WHERE created_at >= '2026-07-01' GROUP BY user_id算好，再让视图只做JOIN轻量关联 - 视图定义里禁用
SELECT *、ORDER BY、DISTINCT，只留必要字段和简单表达式（如COALESCE(o.total, 0)） - 如果视图被多个报表复用，直接建物理预聚合表（如
orders_7d_summary），比每次展开更稳
超过5张表的JOIN，临时表比硬写SQL更可控
当视图里堆了5张以上表，尤其含大事实表时，直接改SQL往往收效甚微。临时表能提前固化过滤结果，后续所有JOIN都基于小数据集跑，执行计划更稳定。
关键不是“建临时表”，而是建得准：只保留后续JOIN和WHERE里真用到的列，避开大文本字段（如VARCHAR(200)），否则体积暴增反拖慢扫描。
- 用
CREATE TEMPORARY TABLE tmp_orders AS SELECT user_id, SUM(amount) AS total FROM orders WHERE status = 'paid' GROUP BY user_id一步到位 - 立刻加索引：
ALTER TABLE tmp_orders ADD INDEX idx_user_id (user_id)——没这步等于裸奔 - JOIN顺序决定索引设计：如果后续是
JOIN tmp_orders ON u.id = t.user_id，索引必须是(user_id)，不是(id) - 字段类型要显式对齐：
user_id在原表是BIGINT，临时表里也得是BIGINT，否则隐式转换让索引失效
LEFT JOIN的WHERE条件写错位置，语义就悄悄变了
这是最常踩的坑：LEFT JOIN users u ON o.user_id = u.id WHERE u.status = 'active'会让MySQL先全量JOIN（包括u.status为NULL的行），再过滤。结果是LEFT JOIN实际退化成INNER JOIN，业务逻辑已偏离预期。
正确写法必须把过滤条件塞进ON子句：LEFT JOIN users u ON o.user_id = u.id AND u.status = 'active'，这样优化器才能在JOIN阶段就剪枝。
-
WHERE u.col IS NOT NULL同理，会强制LEFT JOIN变INNER JOIN，查前务必确认业务是否允许丢弃NULL关联行 - 如果右表本身行数少（比如状态字典表），且不需要过滤，可不加
AND条件；但一旦涉及筛选，就必须进ON
EXPLAIN不看清楚，优化就是蒙眼走路
写完视图或改完SQL，第一件事不是跑查询，而是加EXPLAIN FORMAT=TREE（MySQL 8.0+）或EXPLAIN（旧版本）。盯紧三列：rows、type、filtered。
rows跳高说明某次JOIN后数据失控；type为ALL或index表示右表没走索引；filtered低于5%提示WHERE条件几乎没剪枝——这类条件大概率该挪进ON子句下推。
- 特别注意
Extra列：出现Using temporary或Using filesort，说明触发了临时表或外部排序，得检查是否用了SELECT *、ORDER BY或GROUP BY非索引字段 - SQL Server用户重点看执行计划里有没有
Convert节点或LOB Logical Reads飙升，前者指向数据类型不一致，后者暴露大字段拖累
