跨表聚合报表慢的核心在于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，而索引未覆盖该情况，可能退化为全表扫描