DATEPART/WEEKDAY无法区分工作日和节假日，因仅识别周末而不感知法定节假日；需依赖含date、is_workday、holiday_name三字段的万年历表，并通过JOIN+GROUP BY按is_workday分组统计。
为什么直接用 DATEPART 或 WEEKDAY 无法区分工作日和节假日
因为数据库原生日期函数只识别周末（如周六、周日），完全不感知法定节假日——比如春节调休上班的周一，系统仍判为“周一”，但实际是工作日；而国庆假期中的周三，系统也判为“周三”，实则是节假日。必须依赖外部日历表才能准确归类。
万年历表需要哪些关键字段才够用
一个最小可用的万年历表 calendar_dim 至少得有三列：date（DATE 类型主键）、is_workday（BIT 或 TINYINT，1=工作日，0=非工作日）、holiday_name（VARCHAR，可为空，如‘春节’‘国庆节’）。别省略 is_workday 字段——它比靠 holiday_name IS NOT NULL 推断更可靠，能覆盖调休日场景。
常见错误是只存节日名称，结果遇到调休日（如2024年2月4日周日上班）就漏统计。正确做法是人工或脚本预先填好每一天的 is_workday 值，哪怕只是 Excel 导入一次。
-
date必须是 DATE 类型，避免 DATETIME 带时分秒导致 JOIN 失败 - 确保覆盖你要统计的全部时间范围，比如要查 2023–2025 年数据，表里就得有这三年每天的记录
- SQL Server 用户注意：别用
GETDATE()直接 JOIN，先CAST(GETDATE() AS DATE)对齐类型
如何写 JOIN + GROUP BY 实现按工作日/节假日分组统计
核心是把业务表（如 order）和万年历表 calendar_dim 按日期字段关联，再用 is_workday 分组。假设订单表有 order_date 和 amount：
SELECT c.is_workday, COUNT(*) AS cnt, SUM(o.amount) AS total_amount FROM order o INNER JOIN calendar_dim c ON CAST(o.order_date AS DATE) = c.date WHERE o.order_date >= '2024-01-01' GROUP BY c.is_workday;
返回两行：一行 is_workday = 1（工作日统计），一行 is_workday = 0（节假日+周末统计）。如果想进一步拆解，可以加 CASE WHEN c.holiday_name IS NOT NULL THEN c.holiday_name ELSE '周末' END 作为分组维度，但要注意调休日的 holiday_name 可能为空，而 is_workday 仍是 1。
- 务必用
CAST(... AS DATE)或CONVERT(DATE, ...)统一日期精度，否则 datetime 和 date 类型 JOIN 可能静默失败 - WHERE 条件里的日期范围，建议写在主表（
order）上，而不是日历表上，避免索引失效 - MySQL 用户注意：
is_workday别用 TINYINT(1) 存布尔值，某些驱动会转成字符串，改用 BOOLEAN 或显式CAST(is_workday AS SIGNED)
性能差？给万年历表加索引和分区的实际效果
calendar_dim.date 字段必须建聚集索引（SQL Server）或主键（MySQL），这是 JOIN 性能的底线。如果日历表超 10 年（约 3650 行），基本无压力；但若你硬要塞进 100 年数据，又频繁 JOIN，可以考虑按年分区（SQL Server 的 PARTITION BY RANGE，或 MySQL 的 PARTITION BY LIST(YEAR(date))）。
真正卡顿往往来自没走索引——比如写了 ON YEAR(o.order_date) = YEAR(c.date) 这种表达式，导致全表扫描。永远让 JOIN 条件保持 SARGable（可搜索参数化）：左边是字段，右边是常量或类型一致的字段。
还有一个容易被忽略的点：业务表的 order_date 字段如果没有索引，即使日历表优化再好，整体查询也会慢。别只盯着万年历表。
