先看执行计划再优化sql：10表join慢主因是驱动表错误或索引失效；需通过explain盯type、rows、extra三列；分层子查询收窄结果集；严查null、重复值及隐式转换；join无法削减时考虑宽表或json冗余存储。
先看执行计划，别急着改SQL
10张表JOIN慢，90%的情况不是语法写错，而是驱动表选错了或索引没生效。直接重写JOIN顺序大概率白干——MySQL优化器会按EXPLAIN里type和rows估算重新排序。你手动写的LEFT JOIN链，在优化器眼里可能被转成RIGHT JOIN+嵌套循环，甚至退化成全表扫描。
必须先跑EXPLAIN FORMAT=TRADITIONAL（或FORMAT=JSON），重点盯三列：
-
type：出现ALL或index的表，优先加索引，而不是砍表 -
rows：某张表预估扫描行数远超实际主键数（比如users表rows=50000但只有2000条用户），说明关联字段没走索引或存在隐式类型转换 -
Extra：含Using temporary或Using filesort，意味着中间结果集已失控，此时重构JOIN不如先拆聚合
用子查询提前收口，不是所有JOIN都得平铺
报表里常见“查每个客户最近3单+对应商品+所属区域+优惠券使用情况”，看似要7张表连起来，其实逻辑是分层的：客户→订单（限3条）→订单明细→商品→区域→优惠券记录。强行一气呵成JOIN，中间订单明细一对多会把客户行数撑大几十倍。
更稳的做法是分步收窄：
- 第一层：用
(SELECT ... FROM orders WHERE ... ORDER BY create_time DESC LIMIT 3) AS recent_orders先锁定每客户最多3条订单ID - 第二层：拿这些ID去JOIN商品、区域等维度表，避免明细表参与早期连接
- 第三层：优惠券这类可能一对多的表，改用
EXISTS或LATERAL（PostgreSQL）/APPLY（SQL Server）控制膨胀
关键点：ORDER BY + LIMIT必须在子查询里完成，不能靠外层GROUP BY后取MAX()来模拟——后者会让优化器放弃提前剪枝。
警惕NULL和重复值，它们比语法错误更致命
很多“重构后数据变少”或“行数爆炸”的问题，根源不在JOIN类型，而在关联字段本身。比如：
- 订单表
user_id允许NULL，而用户表id是主键——INNER JOIN会直接丢掉这些订单，但业务上可能要统计“匿名下单量” - 历史迁移导致
orders.user_id有重复值（如两个不同系统的用户ID撞了），和users.id一对多，JOIN后自动乘法膨胀 -
ON a.code = b.code但其中一端存了带空格的字符串，或大小写混用，导致匹配失败又不报错
上线前必做两件事：
- 对每个JOIN条件字段，跑
SELECT COUNT(*) FROM t1 WHERE join_col IS NULL和SELECT join_col, COUNT(*) FROM t1 GROUP BY join_col HAVING COUNT(*) > 1 - 用
COLLATE utf8mb4_bin显式指定比较规则，避免隐式转换
当JOIN真没法减，就换存储形态
如果报表核心指标必须依赖7张以上实时表拼接，且业务方拒绝接受T+1延迟，硬扛JOIN只会让DBA半夜被call醒。这时该考虑的不是SQL怎么写，而是数据要不要动。
- 建宽表：用物化视图（PostgreSQL）或实时ETL（Flink CDC + Doris）把7张表预关联成一张
report_customer_order_summary，查询时只扫这一张 - 用JSON字段存轻量维度：比如把用户所在区域的名称、层级、负责人打包成
region_info JSON存在订单表里，省掉一次JOIN - 分区裁剪：如果报表总按时间范围过滤，确保每张参与JOIN的表都按
create_time做了范围分区，让优化器能跳过90%的数据文件
最常被忽略的一点：宽表不是银弹。一旦源表结构变更（比如加了个新字段），宽表同步链路若没覆盖到，报表数据就静默出错——所以宽表必须配自动化schema校验，不能只靠人工核对。
