用 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 结果出现重复或断裂。
