dayofweek() 返回 1 表示星期日，因 mysql 以周日为一周起点，对应 1～7；weekday() 则以周一为起点，返回 0～6，更符合程序员习惯。
DAYOFWEEK() 返回值为什么是 1= 星期日？
MySQL 的 DAYOFWEEK() 遵循“周日为一周起点”的传统，返回 1～7，对应星期日到星期六。这和很多业务系统里“周一为第一天”的直觉冲突，容易导致条件判断出错——比如你想查“所有周一的数据”，写成 DAYOFWEEK(date_col) = 1 实际查出来的是周日。
- 常见错误现象：
WHERE DAYOFWEEK(create_time) = 2意图取周一，结果取对了；但换成= 1就悄悄混入周日数据 - 使用场景：报表按“自然周”分组、定时任务判断是否为周末（
IN (1,7)） - 注意：该函数受
default_week_format影响极小，行为稳定，但和语言层（如 PHP 的date('w')）不一致
WEEKDAY() 更贴近程序员日常习惯
WEEKDAY() 返回 0～6，对应周一到周日，和 Python 的 .weekday()、JavaScript 的 getDay()（稍作调整）、以及多数后端开发者认知一致。如果你在写调度逻辑或做日期偏移计算，它更少烧脑。
- 常见错误现象：把
WEEKDAY()和DAYOFWEEK()混用，比如在同一个 WHERE 条件里交替出现，结果逻辑翻车 - 参数差异：两者都只接受一个
DATE或DATETIME类型参数，不支持格式化字符串直接输入 - 性能影响：无差别，底层都是常量时间计算，索引无法加速这类函数调用
跨数据库移植时别硬套 MySQL 函数名
PostgreSQL 没有 DAYOFWEEK()，得用 EXTRACT(DOW FROM date_col)，它也返回 0= 周日；而 SQLite 的 strftime('%w', date_col) 同样是 0= 周日。也就是说：MySQL 的 WEEKDAY()（0= 周一）其实是特例。
- 使用场景：项目要从 MySQL 迁移到其他数据库，或写兼容多库的 DAO 层 SQL
- 建议做法：封装一层视图或函数抽象掉差异，或者干脆在应用层解析日期，避免 SQL 层强依赖特定方言
- 容易踩的坑：用
WEEKDAY()写的条件，在 pgsql 里直接报错，不是语法错，而是函数不存在
用 CASE 隐藏差异比硬记数字更可靠
与其反复确认“今天到底是 1 还是 0”，不如用可读性更强的表达。尤其当逻辑涉及多个工作日 / 节假日判断时，显式写出星期名称能大幅降低维护成本。
- 示例：
CASE WEEKDAY(date_col) WHEN 0 THEN 'Mon' WHEN 1 THEN 'Tue' ELSE 'Weekend' END - 优势：语义清晰，改需求时不用翻文档查映射表；团队协作时新人一眼看懂
- 注意点：
CASE表达式本身不提升性能，但能减少人为误判——这才是真实瓶颈
实际用哪个，取决于你手上的数据库、团队习惯、以及要不要跨库。但只要开始写 WHERE DAYOFWEEK(x) = 1，就得立刻问自己一句：我真想选周日吗？
