不能直接用 DATEPART 或 WEEKDAY 判断工作日，因为法定节假日每年不同且存在调休，必须依赖预置并人工校对的日历维表关联判断；核心是 JOIN dim_calendar 后按 is_workday 或 holiday_name 分组统计，并用 LEFT JOIN + COALESCE 处理日期缺失。
为什么不能直接用 DATEPART 或 WEEKDAY 判断工作日？
因为法定节假日每年不同，且存在调休（比如周末上班、工作日放假），单纯靠周几或固定日期范围会统计错误。例如 2024 年 2 月 10 日是春节初一（法定假日），但它是星期六；而 2 月 12 日（周一）因调休也放假——这些都必须查日历维表才能准确识别。
核心逻辑是：把业务事实表的日期字段，关联到预置好的日历维表，再按维表里的 is_workday 或 holiday_type 字段分组。
- 日历维表至少需包含：
date_key（如 '2024-01-01'）、is_workday（BIT / TINYINT / BOOLEAN）、holiday_name（NULL 或 '春节'） - 务必提前生成 3–5 年的日历数据，并人工校对调休安排（国务院每年发布通知）
- 避免在 SQL 里硬编码节假日，否则每年都要改代码
如何写 JOIN + GROUP BY 实现分组统计？
假设你有订单表 orders（含 order_date），和日历维表 dim_calendar（主键 date_key），目标是统计「工作日订单数」和「节假日订单数」：
SELECT c.is_workday, COUNT(*) AS order_cnt FROM orders o JOIN dim_calendar c ON CAST(o.order_date AS DATE) = c.date_key GROUP BY c.is_workday;
如果想进一步区分类型（如工作日/周末/法定假日），可改用：
SELECT
CASE
WHEN c.holiday_name IS NOT NULL THEN 'holiday'
WHEN c.is_workday = 0 THEN 'weekend'
ELSE 'workday'
END AS day_type,
COUNT(*) AS order_cnt
FROM orders o
JOIN dim_calendar c ON CAST(o.order_date AS DATE) = c.date_key
GROUP BY
CASE
WHEN c.holiday_name IS NOT NULL THEN 'holiday'
WHEN c.is_workday = 0 THEN 'weekend'
ELSE 'workday'
END;
-
CAST(o.order_date AS DATE)是关键：确保时间戳（如 '2024-02-10 14:22:03'）能正确匹配日历表的纯日期 - 不要在
ON条件里用函数包裹维表字段（如CAST(c.date_key AS DATE)），否则无法走索引 - 若
dim_calendar.date_key是字符串类型（如 '20240101'），则 JOIN 条件要统一格式：CONVERT(CHAR(8), o.order_date, 112)
遇到 NULL 或跨年数据时怎么处理？
如果订单日期超出日历维表范围（比如查 2025 年数据但维表只到 2024-12-31），JOIN 会导致记录丢失。此时应改用 LEFT JOIN 并显式处理缺失：
SELECT
COALESCE(
CASE
WHEN c.holiday_name IS NOT NULL THEN 'holiday'
WHEN c.is_workday = 0 THEN 'weekend'
WHEN c.is_workday = 1 THEN 'workday'
ELSE 'unknown_date'
END,
'missing_in_calendar'
) AS day_type,
COUNT(*) AS order_cnt
FROM orders o
LEFT JOIN dim_calendar c ON CAST(o.order_date AS DATE) = c.date_key
GROUP BY
COALESCE(
CASE
WHEN c.holiday_name IS NOT NULL THEN 'holiday'
WHEN c.is_workday = 0 THEN 'weekend'
WHEN c.is_workday = 1 THEN 'workday'
ELSE 'unknown_date'
END,
'missing_in_calendar'
);
-
LEFT JOIN保证所有订单都参与统计，哪怕日历缺失 -
COALESCE(..., 'missing_in_calendar')把c为 NULL 的情况归入单独分组，便于发现维表覆盖问题 - 生产环境建议加监控：定期查
WHERE c.date_key IS NULL的订单量，预警日历更新滞后
性能慢？检查这三点
关联日历维表后查询变慢，大概率不是 SQL 写法问题，而是基础配置没到位：
-
dim_calendar.date_key必须建 聚集索引（SQL Server）或 主键 + 唯一索引（MySQL/PostgreSQL），且类型与事实表日期字段一致（避免隐式转换） - 事实表的日期字段（如
order_date）建议增加非聚集索引，包含常用筛选字段：CREATE INDEX IX_orders_order_date ON orders(order_date) INCLUDE (order_id, amount); - 如果日历维表超大（比如含小时粒度），确认你用的是日期粒度表（每天一行），而非「日历+时间」混合表——后者会极大拖慢 JOIN 效率
真正麻烦的从来不是写 SQL，而是日历维表的数据准确性、时效性，以及团队是否共识“节假日逻辑只从这张表取”。一旦有人绕过它写 WHERE order_date IN ('2024-01-28', '2024-01-29')，整个统计体系就不可信了。
