应根据数据完整性需求选择：需保留主表所有维度时用LEFT JOIN，仅关注匹配事实时用INNER JOIN；注意ON条件字段类型一致、NULL处理及索引优化，避免行数膨胀。
用 LEFT JOIN 还是 INNER JOIN 合并报表？看数据完整性需求
合并多维度报表时，JOIN 类型选错，结果直接少行、丢维度。比如销售报表要展示「所有区域」+「对应销售额」，但用了 INNER JOIN，那没成交记录的区域就彻底消失了。
- 如果主表是维度表（如
regions、products），且必须保留所有维度项，一律用LEFT JOIN，右表（事实表）字段为NULL是正常现象 - 如果只关心有匹配的事实数据（如「有订单的客户」+「其会员等级」），
INNER JOIN更快，也更安全——避免隐式笛卡尔积风险 - 别在
WHERE里对左连接右表字段加非空条件（如WHERE sales.amount > 100），这会把LEFT JOIN变成INNER JOIN效果，悄悄过滤掉空值行
ON 条件写错导致重复或漏匹配：字段类型和 NULL 处理是关键
ON 不只是写两个字段相等，类型不一致或忽略 NULL 就会出问题。常见表现是某条记录出现 2–5 倍重复，或者明明有数据却连不上。
- 检查连接字段是否同类型：
region_id是INT，别拿VARCHAR的region_code直接连，隐式转换可能全表扫描 - 字符串字段连接前先
TRIM()，尤其从 Excel 导入的数据常带空格 -
NULL值永远不等于NULL，所以如果连接字段可能为空，得显式处理，比如：ON (a.product_id = b.product_id OR (a.product_id IS NULL AND b.product_id IS NULL))—— 但更推荐提前清洗掉 NULL
多表 JOIN 性能崩了？先看驱动表和索引覆盖
三张表以上 JOIN，执行时间从毫秒变分钟，通常不是 SQL 写得“复杂”，而是优化器选错了驱动顺序，或缺关键索引。
- 把记录数最少、过滤条件最强的表放最左（即
FROM后第一个表），它作为驱动表，能尽早减少中间结果集 - 每个
ON字段、每个WHERE过滤字段、每个GROUP BY字段，都应有单列或组合索引支撑；特别注意复合索引字段顺序必须匹配JOIN和WHERE的使用顺序 - 用
EXPLAIN看type是否为ref或eq_ref，如果是ALL或index，基本说明没走索引
汇总后 COUNT 和 SUM 对不上？警惕 JOIN 引起的行数膨胀
加了 JOIN 再 COUNT(*) 或 SUM(sales)，数字突然翻倍，大概率是「一对多」关系没处理。比如一个订单有 3 行明细，连上订单表后，订单主信息就被复制了 3 次。
- 先确认连接关系：是 1:1、1:N 还是 N:N？N 端表（如订单明细）不能直接参与聚合，否则会放大
- 解法一：子查询预聚合，比如先
SELECT order_id, SUM(amount) FROM order_items GROUP BY order_id，再跟订单主表连 - 解法二：用
DISTINCT限定计数范围，如COUNT(DISTINCT orders.order_id)，但注意这不能用于SUM类指标 - 别依赖
GROUP BY字段数量来“猜”聚合粒度，务必核对业务含义——报表维度到底是按「订单」还是按「订单行」统计
实际写这类报表，最耗时间的往往不是写 SQL，而是反复验证「某区域销售额是不是真比上月少了，还是只是 JOIN 漏掉了几条记录」。只要 ON 条件、NULL 处理、聚合层级这三点没踩准，后面所有优化都是白忙。
