LEFT JOIN更可靠是因为它确保日期维度表（左表）所有日期均保留，右表无匹配时填NULL，便于COALESCE填充0；若误用RIGHT JOIN且日期表在右侧，逻辑即失效，导致缺失日期无法补全。
为什么LEFT JOIN比RIGHT JOIN更可靠地补全日期
因为日期维度表通常作为“主表”提供完整时间序列，而业务数据表可能缺失某些日期的记录。用 LEFT JOIN 保证左侧日期表所有行都保留，右侧业务表匹配不到就填 NULL，后续 COALESCE 或 IFNULL 才能安全填充默认值。用 RIGHT JOIN 容易把日期表写在右边，一旦写反，补全逻辑就失效。
常见错误现象：GROUP BY date_col 后只有 5 行结果，但实际需要覆盖最近 30 天 —— 这说明没先用日期表左连，而是直接对原始业务表分组。
- 日期表必须是独立生成的（如递归 CTE、
generate_series或预建日历表），不能依赖业务表里的MIN(date)/MAX(date)拼范围，否则仍会漏掉无数据的中间日期 - JOIN 条件必须严格对齐日期粒度：如果业务表是
DATETIME类型，要先用DATE(order_time)转成日期再关联，否则等值匹配失败 - MySQL 8.0+ 可用
WITH RECURSIVE，PostgreSQL 推荐generate_series('2024-01-01'::date, '2024-01-30'::date, '1 day')
如何写一个不依赖日历表的动态日期序列（MySQL 8.0+）
不用建物理日历表，靠 CTE 生成连续日期最灵活。关键点是：起止日期必须可参数化，且递归深度不能超限（MySQL 默认 1000，可通过 cte_max_recursion_depth 调整）。
WITH RECURSIVE dates AS ( SELECT '2024-01-01' AS dt UNION ALL SELECT DATE_ADD(dt, INTERVAL 1 DAY) FROM dates WHERE dt < '2024-01-30' ) SELECT d.dt, COALESCE(SUM(o.amount), 0) AS total FROM dates d LEFT JOIN orders o ON DATE(o.created_at) = d.dt GROUP BY d.dt ORDER BY d.dt;
注意：DATE(o.created_at) 在 JOIN 条件里会导致索引失效（除非有函数索引）。生产环境建议在 orders 表上加生成列 order_date DATE AS (DATE(created_at)) STORED 并建索引。
PostgreSQL 中 generate_series 的三个典型坑
generate_series 是最简方案，但类型不匹配、时区、边界行为容易出错。
- 错误写法：
generate_series('2024-01-01', '2024-01-30')→ 返回timestamp without time zone，与DATE列比较会隐式转换，可能跨时区偏移；应显式转：generate_series('2024-01-01'::date, '2024-01-30'::date, '1 day')::date - 如果业务表日期带时区（如
timestamptz），用o.created_at::date比DATE(o.created_at)更明确，避免会话时区干扰 - 边界包含逻辑：
generate_series默认包含终点，但若终点早于起点，返回空集 —— 不报错，容易被忽略
GROUP BY 后补零值时 COUNT(*) 和 COUNT(col) 的区别
补全日期后，统计指标是否为 0 很关键。用 COUNT(*) 会把 NULL 行也算作 1（因为 * 统计行数），而 COUNT(amount) 只统计非 NULL 值，这才是你真正想要的“当天订单数”。
示例场景：某天无订单，LEFT JOIN 后 amount 为 NULL：
-
COUNT(*)→ 返回 1（错） -
COUNT(amount)→ 返回 0（对） -
SUM(amount)自动忽略NULL，但需搭配COALESCE(SUM(amount), 0)避免结果为NULL
最容易被忽略的是：即使写了 COALESCE(SUM(...), 0)，如果忘了把 COUNT(*) 改成 COUNT(业务字段)，日活、订单数这类指标依然会虚高。
