mysql用weekday()（周一0至周日6），postgresql用extract(isodow from date_col)-1对齐；避免硬编码，统一按周一=0、周日=6逻辑判断工作日。
用 WEEKDAY 判断工作日/周末时，注意 MySQL 和 PostgreSQL 的起始日不同
MySQL 的 WEEKDAY() 返回 0（周一）到 6（周日），而 DAYOFWEEK() 返回 1（周日）到 7（周六）——容易混淆。PostgreSQL 没有原生 WEEKDAY，得用 EXTRACT(DOW FROM ...)，它也把周日算作 0，和 MySQL 的 DAYOFWEEK 冲突。
实操建议：
- 统一用「周一=0，周日=6」逻辑：MySQL 选
WEEKDAY(date_col)；PostgreSQL 用EXTRACT(ISODOW FROM date_col) - 1（ISODOW周一=1，减1后对齐） - 避免硬写
WEEKDAY(date_col) IN (0,1,2,3,4)，改用表达式判断更清晰：WEEKDAY(date_col) - 如果表里有 timezone 信息，先用
CONVERT_TZ或AT TIME ZONE标准化时间，否则跨时区统计可能把同一天判成不同星期几
SQL Server 里用 DATEPART 分组要小心 DATEFIRST 设置
DATEPART(weekday, date_col) 的返回值依赖会话级的 DATEFIRST（默认为 7，即周日为第一天）。这意味着同一句 SQL 在不同服务器或连接下可能分组错乱。
实操建议：
- 显式设置
SET DATEFIRST 1（周一为第一天），再执行分组查询，确保行为一致 - 更稳妥的做法是绕过
DATEPART(weekday, ...)，改用(DATEPART(dw, date_col) + @@DATEFIRST - 2) % 7折算成 ISO 标准（周一=0） - 若只是简单区分工作日/周末，直接用：
CASE WHEN DATEPART(weekday, date_col) IN (2,3,4,5,6) THEN 'workday' ELSE 'weekend' END——但必须确认当前DATEFIRST是 7（默认）
分组统计时，别忘了处理 NULL 日期和跨年边界
真实数据里常有 NULL 的日期字段，直接 GROUP BY WEEKDAY(date_col) 会让整行被丢弃；另外，12 月 31 日可能是周一，但属于下一年的第 1 周，用 YEAR() + WEEK() 混合分组会出错。
实操建议：
- 加
WHERE date_col IS NOT NULL显式过滤，或在CASE中单独归类：WHEN date_col IS NULL THEN 'unknown' - 如果业务定义“工作日”包含节假日，仅靠
WEEKDAY不够，得关联节假日表，用LEFT JOIN+COALESCE(holiday.flag, 0)补充判断 - 跨年问题：用
YEARWEEK(date_col, 1)（MySQL）或TO_CHAR(date_col, 'IYYY-IW')（PostgreSQL）替代YEAR()+WEEK()，它们遵循 ISO 周标准
性能关键：给日期字段建函数索引前先看执行计划
对 WEEKDAY(created_at) 建索引看似合理，但多数数据库不支持直接对函数结果建普通索引（MySQL 5.7+ 支持函数索引，SQL Server 需计算列，PostgreSQL 要表达式索引），盲目添加反而拖慢写入。
实操建议：
- 先跑
EXPLAIN或执行计划，确认是否真走索引扫描；如果只是按天/月聚合后再分工作日，优先考虑在created_at上建普通 B-tree 索引 - 高频按工作日过滤的场景，可新增一个持久化计算列：
is_workday TINYINT AS (CASE WHEN WEEKDAY(created_at) ，再对它建索引 - 分区表场景下，按周分区比按工作日分区实用得多——毕竟数据是按时间连续写入的，不是按星期几离散分布的
最常被忽略的一点：不同数据库对同名函数的实现细节差异极大，比如 SQL Server 的 DATEPART(week, ...) 和 MySQL 的 WEEK(...) 对一年第一周的定义就完全不同。上线前务必用真实日期范围验证分组结果，别只测 2023-01-01 这种典型日期。
