MySQL用WEEKDAY()（0=周一）判周末需IN(5,6)，PostgreSQL用EXTRACT(DOW)（0=周日）需IN(0,6)，SQL Server须SET DATEFIRST 1再查；分组须重复表达式；节假日应建calendar_dim维表而非硬编码。
用 WEEKDAY 判断工作日/周末时，注意 MySQL 和 PostgreSQL 的起始日不同
MySQL 的 WEEKDAY() 返回 0（周一）到 6（周日），而 DAYOFWEEK() 是 1（周日）到 7（周六）——容易混淆导致周日被错归为工作日。PostgreSQL 没有原生 WEEKDAY，得用 EXTRACT(DOW FROM date)，它和 MySQL 的 DAYOFWEEK() 一样：0 表示周日。
实操建议：
- 统一用「是否为周六或周日」逻辑判断，比依赖数字含义更可靠
- MySQL 中推荐：
CASE WHEN WEEKDAY(date_col) IN (5,6) THEN '周末' ELSE '工作日' END - PostgreSQL 中对应写法：
CASE WHEN EXTRACT(DOW FROM date_col) IN (0,6) THEN '周末' ELSE '工作日' END（因为 0=周日，6=周六） - SQL Server 用户请用
DATEPART(WEEKDAY, date_col)，但要注意DATEFIRST设置会影响结果，建议先执行SET DATEFIRST 1（让周一为每周第一天）再查
SQL Server 的 DATEPART(WEEKDAY, ...) 默认返回值受 DATEFIRST 影响
不显式设置 DATEFIRST 时，SQL Server 会按登录用户的语言环境决定每周第一天。比如美国英语默认 DATEFIRST = 7（周日为第 1 天），此时 DATEPART(WEEKDAY, '2024-06-01')（周六）返回 7，DATEPART(WEEKDAY, '2024-06-02')（周日）返回 1——这意味着周末是 1 和 7，而不是直观的 6 和 7。
安全做法：
- 在查询开头加
SET DATEFIRST 1，确保周一为第 1 天，周末固定为 6 和 7 - 或绕过依赖：
CASE WHEN DATEPART(WEEKDAY, date_col) IN (6,7) THEN '周末' ELSE '工作日' END配合前面的SET - 生产环境避免在视图或函数中隐式依赖
DATEFIRST，否则迁移或跨库执行可能出错
分组汇总时，别把字符串别名直接塞进 GROUP BY（尤其在旧版 MySQL）
像 SELECT CASE WHEN ... THEN '周末' ELSE '工作日' END AS period, COUNT(*) FROM t GROUP BY period 在 MySQL 5.7 严格模式下会报错：Expression #1 of SELECT list is not in GROUP BY clause，因为 period 是别名，不是原始表达式。
正确写法必须重复表达式或改用序号：
- 重复表达式（推荐，语义清晰）：
GROUP BY CASE WHEN WEEKDAY(date_col) IN (5,6) THEN '周末' ELSE '工作日' END - 用位置序号（仅限 SELECT 同级，可读性差）：
GROUP BY 1（假设该 CASE 是 SELECT 第一个字段） - 别名方式只在 PostgreSQL / SQL Server 等支持标准 SQL 的引擎里较稳妥，MySQL 仍建议写全
需要排除节假日？纯 SQL 很难维护，优先考虑关联维表
用 WEEKDAY 或 DATEPART 只能识别周六日，没法处理调休、法定假日等场景。硬编码 CASE WHEN date_col IN ('2024-01-28','2024-02-04') THEN '工作日' 会导致 SQL 越来越长、难以测试和更新。
更可持续的做法：
- 建一张
calendar_dim表，含date、is_workday（布尔）、holiday_name等字段，每日一条记录 - 查询时
JOIN calendar_dim ON t.date_col = calendar_dim.date，再按calendar_dim.is_workday分组 - 这张表可由脚本每月初生成，或接入公司统一的假期服务 API 同步
临时应急可以加子查询过滤，但长期看，把日期逻辑从 SQL 里抽出来才是少踩坑的关键。
