SQL查询本周数据方法：YEARWEEK函数使用案例详解
来源：互联网 2026-05-06 19:24:28SQL如何查询本周数据？YEARWEEK函数的实际案例 YEARWEEK函数返回值为什么和预期对不上？ 问题往往出在一个默认的“小动作”上：YEARWEEK() 函数默认以周日作为一周的起点（即 mode=0）。然而，我们绝大多数业务场景，无论是报表统计还是运营复盘，习惯上都是按周一来计算本周的。这
SQL如何查询本周数据？YEARWEEK函数的实际案例
YEARWEEK函数返回值为什么和预期对不上？
问题往往出在一个默认的“小动作”上：YEARWEEK() 函数默认以周日作为一周的起点（即 mode=0）。然而，我们绝大多数业务场景，无论是报表统计还是运营复盘，习惯上都是按周一来计算本周的。这个认知偏差，就是数据对不上的根源。
长期稳定更新的攒劲资源： >>>点此立即查看<<<
举个例子，2024年6月2日是个周日。如果你直接调用 YEARWEEK('2024-06-02')，它会返回 202422，因为它认为周日是上周的结束。但在你的业务逻辑里，这天很可能应该归属于以6月3日（周一）开始的第23周。
解决办法其实很直接：务必显式指定 mode 参数，明确告诉数据库你的“一周”是怎么定义的。常用的几个模式是：
mode = 1：周一为每周第一天，且第一周必须包含4个及以上周一（这是ISO国际标准）。mode = 3：周一为每周第一天，且第一周是包含当年1月4日的那一周（这个定义更常用，也更符合业务直觉）。mode = 5：周日为每周第一天，但第一周需含4个及以上周日（这个模式相对少见，一般不推荐）。
所以，日常查询“本周一到周日”的数据，优先使用 mode = 3 准没错。
如何用YEARWEEK筛选“本周”的完整记录？
知道了正确的mode，下一个坑就是查询写法。你可能会顺手写成：WHERE YEARWEEK(create_time) = YEARWEEK(NOW())。且慢，这里有两大隐患：第一，前后两个YEARWEEK的mode如果不一致，结果必然出错；第二，更重要的是，这种写法会让索引失效。
正确的姿势是：先计算出本周明确的起止时间点，然后对时间字段进行范围查询。这样既能保证逻辑准确，又能让数据库高效利用索引。
以MySQL为例，查询「本周一 00:00:00 至 本周日 23:59:59」的订单数据，可以这样写：
SELECT * FROM orders WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL WEEKDAY(CURDATE()) DAY) AND create_time < DATE_ADD(DATE_SUB(CURDATE(), INTERVAL WEEKDAY(CURDATE()) DAY), INTERVAL 7 DAY);
简单拆解一下：
WEEKDAY(CURDATE())返回当前日期是本周的第几天（注意：周一返回0，周日返回6）。DATE_SUB(CURDATE(), INTERVAL WEEKDAY(CURDATE()) DAY)这个计算，就能精准地回溯到本周一的日期。- 右边界使用
<（小于）下周一的零点，而不是<=（小于等于）本周日，这是为了避免时间戳精度问题导致的边界数据遗漏，是个很实用的细节。
YEARWEEK在WHERE子句中能走索引吗？
坦率地说，基本不能。数据库索引的工作原理，是基于字段的原始值建立有序结构。一旦你对字段使用了函数包裹，比如 YEARWEEK(create_time)，MySQL优化器就无法再直接使用 create_time 列上的普通B+Tree索引了（除非使用MySQL 8.0.13及以上版本支持的函数索引）。
如果你的数据表体积庞大，又需要频繁查询“本周”数据，那么优化策略就非常关键：
- 给
create_time建立普通索引：这是为了高效支持上面提到的范围查询。 - 避免使用
WHERE YEARWEEK(create_time) = ...这类表达式：从源头杜绝索引失效。 - 考虑函数索引（有条件使用）：如果数据库版本是MySQL 8.0.13+，且查询模式固定，可以创建函数索引：
CREATE INDEX idx_week ON orders ( (YEARWEEK(create_time, 3)) );。但要注意，这种索引只对特定函数和mode组合生效，灵活性较差，通常不如范围查询方案通用。
跨年时YEARWEEK返回202453还是202501？
年底的数据归属问题，是另一个容易引发混乱的场景。答案依然是：取决于你选择的mode。
例如，2024年12月30日是个周一。如果采用ISO标准（mode=1），它属于2025年的第1周，所以 YEARWEEK('2024-12-30', 1) 返回 202501。但如果采用 mode=3，它则仍然属于2024年的第53周。
你看，跨年周的归属并非一成不变的铁律，而是由mode参数定义的“何为一年中的第一周”这个逻辑决定的。这直接关系到线上统计报表的准确性：如果你们的BI看板按自然周（周一至周日）聚合数据，那么整个团队必须统一使用 mode = 3，否则12月底那几天的数据，很可能悄无声息地被算到了下一年的“本周”报表里，导致年终和年初的数据都对不上。
说到底，最隐蔽的风险往往不是技术难题，而是业务定义与数据库默认行为之间的隐性断层。不显式地指定mode，就等于把数据分组的逻辑拱手让给了MySQL的默认设置，而这个默认值，十有八九和你业务后台的统计逻辑是拧着的。
侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述
