SQL 复合报表生成 SQL 实战

用 union all 替代 or 可避免索引失效，确保各子查询命中索引；group by 多字段时需将非聚合列全加入 group by 或用聚合函数包裹；left join 的从表过滤条件应写在 on 中而非 where；日期范围查询宜用 >= 与

WHERE 条件里用 OR 会导致索引失效，改用 UNION ALL 更稳

复合报表常要拼多个业务维度的数据，比如“订单数 + 退货数 + 售后工单数”，有人习惯写 WHERE status = 'paid' OR status = 'refunded'。但 MySQL/PostgreSQL 在多数情况下不会走联合索引，尤其是 OR 两边字段不同或涉及函数时，执行计划里容易看到 type: ALL 或 Extra: Using filesort。

实操建议：

• 拆成两个独立查询，用 UNION ALL 合并（注意不是 UNION，避免去重开销）
• 每个子查询确保能命中索引：比如 WHERE status = 'paid' AND created_at >= '2024-01-01' 比 WHERE status IN ('paid','refunded') AND DATE(created_at) = '2024-01-01' 更可靠
• 如果必须用 OR，检查执行计划——用 EXPLAIN FORMAT=TREE（MySQL 8.0+）或 EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）确认是否走了索引扫描

GROUP BY 多字段时，SELECT 列必须严格受函数包裹或出现在 GROUP BY 中

写复合报表时经常要按日期+渠道+地区分组聚合，一不留神就报错 ERROR 1055 (42000): Expression #3 of SELECT list is not in GROUP BY clause（MySQL 5.7+ 默认 SQL_MODE 严格模式）。这不是语法错误，是语义保护机制——数据库拒绝返回“不确定值”。

实操建议：

• 要么把所有非聚合列都加进 GROUP BY，比如 GROUP BY DATE(created_at), channel, region
• 要么对非分组字段显式用聚合函数包裹，比如 MAX(customer_level) 或 ANY_VALUE(sales_rep)（MySQL），MIN(order_id)（通用）
• 别依赖 sql_mode 关掉严格模式来绕过——上线后可能因版本升级或配置漂移突然报错

LEFT JOIN 多张表时，ON 条件写错位置会漏数据

做销售漏斗报表（线索→报价→合同→回款），常连 4–5 张表。新手容易把过滤条件全堆在 WHERE，结果把左表的空关联行也干掉了，比如想查“所有线索+对应合同金额”，但 WHERE contract.amount > 0 实际让没合同的线索直接消失。

实操建议：

• 业务主表放最左，用 LEFT JOIN 接从表
• 从表的关联条件写在 ON 里，比如 LEFT JOIN contract ON lead.id = contract.lead_id
• 从表的过滤条件也尽量写进 ON，比如 LEFT JOIN contract ON lead.id = contract.lead_id AND contract.status = 'signed'；只有主表过滤才放 WHERE
• 不确定时，先跑一遍 SELECT COUNT(*) FROM lead LEFT JOIN contract ... 对比 SELECT COUNT(*) FROM lead，看数量是否一致

日期范围查询用 BETWEEN 容易少算边界，用 >= +

报表常要查“2024年Q1数据”，写成 WHERE created_at BETWEEN '2024-01-01' AND '2024-03-31' 看似合理，但如果 created_at 是 DATETIME 类型，且最后一条记录是 '2024-03-31 23:59:59.999'，不同数据库对毫秒截断策略不同，可能被漏掉。

实操建议：

• 统一用半开区间：WHERE created_at >= '2024-01-01' AND created_at
• 避免用 DATE(created_at) = '2024-01-01' 这类函数包装字段——它会让索引失效
• 如果字段带时区（如 TIMESTAMP WITH TIME ZONE），先确认数据库时区和应用层传入时间是否对齐，否则 可能跨天

复杂点在于，复合报表往往要同时满足多套时间逻辑（创建时间、审核时间、生效时间），每套都得单独校验边界。最容易被忽略的是：同一个字段在不同子查询里用了不同格式化方式，导致最终 UNION 结果出现重复或断裂。