跨表聚合报表慢的核心在于 join 顺序不合理或子查询写法不当。应小表驱动大表，优先 join 带强过滤条件的表，避免笛卡尔积；用预聚合、cte 替代相关子查询；聚合下推至数据源，善用覆盖索引并注意 null 影响。
跨表聚合报表慢，核心往往不在数据量，而在 JOIN 顺序不合理或子查询写法拖累了执行计划。优化关键不是加索引，而是让 SQL 更贴近数据库的执行逻辑。
JOIN 顺序：小表驱动大表是基础原则
数据库（如 MySQL、PostgreSQL）大多采用嵌套循环（Nested Loop）或哈希连接（Hash Join）策略。若先 JOIN 两个大表，中间结果集会急剧膨胀，后续过滤和聚合成本飙升。
- 优先把带强过滤条件（如WHERE status = ‘done’ AND create_time > ‘2024-01-01’）的表放在 JOIN 链前端，尽早缩小数据集
- 用 EXPLAIN 确认实际驱动表——MySQL 中 type=ref/eq_ref 且rows值小的表通常是驱动表；PostgreSQL 看 Rows Removed by Filter 比例
- 避免写成 A JOIN B JOIN C 却不加任何 ON 条件约束，尤其当 B 表无主外键关联时，易触发笛卡尔积
子查询能提前聚合，就别留到最外层
常见陷阱：在 SELECT 中写 (SELECT SUM(amount) FROM orders o WHERE o.user_id = u.id)，对用户表每行都执行一次子查询，O(N×M) 复杂度。
- 改用 LEFT JOIN 预聚合：LEFT JOIN (SELECT user_id, SUM(amount) AS total_amt FROM orders GROUP BY user_id) o ON u.id = o.user_id
- 若子查询含多层嵌套 +ORDER BY/LIMIT，考虑提取为 CTE（WITH 子句），让优化器有机会复用中间结果
- 警惕相关子查询中的非 SARGable 条件（如DATE(create_time) = ‘2024-01-01’），它会让索引失效，也阻碍上拉优化
聚合下推：让 GROUP BY 尽量靠近数据源
不要等所有 JOIN 完成再 SUM、COUNT——中间冗余字段越多，内存和 CPU 开销越大。
- 对明细表先分组汇总，再 JOIN 维度表。例如统计各品类销售额，应先 GROUP BY category_id 算出金额，再 JOIN 品类名称表
- 用 DISTINCT 前先确认是否真需要去重。有时用 GROUP BY 替代SELECT DISTINCT + 多表 JOIN，执行计划更可控
- 聚合字段若来自 JOIN 后的计算（如o.qty * p.price），确保该计算不阻塞下推——可建生成列或物化表达式索引（视数据库版本支持）
用覆盖索引减少回表，尤其在 JOIN+GROUP BY 场景
当聚合涉及 JOIN 后字段，数据库常需回表取数据。覆盖索引能把 JOIN 键、过滤字段、聚合字段全包含进来，跳过主键查找。
- 例如 orders JOIN users ON orders.user_id = users.id GROUP BY users.city，在orders 表上建索引 (user_id, status, create_time) 不够，应扩展为(user_id, status, create_time, amount)（若聚合用到 amount）
- 联合索引顺序按“等值过滤 → JOIN 键 → 排序 / 聚合字段”排列，避免范围查询（如>）打断索引利用
- 注意 NULL 值影响：若 JOIN 字段允许 NULL，而索引未覆盖该情况，可能退化为全表扫描
