如何快速查询最近七天数据：SQL日期加减运算方法-SQL-PHP中文网

MySQL查询最近七天最稳妥写法是DATE_SUB(NOW(), INTERVAL 7 DAY)，需注意单位小写单数、避免DATEDIFF误用、优先CURDATE()处理日期边界，并确保时区与索引友好。

如何快速查询最近七天数据：sql日期加减运算方法

用 `DATE_SUB(NOW(), INTERVAL 7 DAY)` 直接算起点

查最近七天，本质是构造一个“从今天往前推7天”的时间点作为筛选下限。MySQL 最稳、最直白的写法就是 DATE_SUB(NOW(), INTERVAL 7 DAY) —— 它明确表达“减”，且不会因时区或字段类型隐式转换出错。

常见错误现象：
• 写成 DATE_ADD(NOW(), INTERVAL -7 DAY) 虽然结果对，但可读性差，新人容易看反符号；
• 用 NOW() - INTERVAL 7 DAY（省略函数），在部分 MySQL 模式下会报错或静默失败；
• 把单位写成 '7 days' 或 'DAY'（大写）——INTERVAL 后单位必须是小写单数，否则返回 NULL，查不到数据还找不到原因。

实操建议：
• 始终用 DATE_SUB(NOW(), INTERVAL 7 DAY)，别省函数名；
• 如果要包含今天（即 2026-03-26 00:00:00 到 2026-03-26 23:59:59），WHERE 条件写成：
create_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)（用 CURDATE() 避免时间部分干扰）；
• 若字段是 TIMESTAMP 且数据库时区不统一，优先在应用层做时区对齐，别依赖连接级 SET time_zone。

别用 `DATEDIFF` 做范围查询

DATEDIFF 是计算“两个日期之间整数天差”的函数，不是用来生成时间点的。拿它写 DATEDIFF(NOW(), create_time) 表面能跑通，但实际隐患很大。

常见错误现象：
• DATEDIFF 会截断时间部分，'2026-03-19 23:59:59' 和 '2026-03-20 00:00:01' 都算作“相差 1 天”，导致边界数据漏掉或误入；
• WHERE 中对字段调用函数（如 DATEDIFF(NOW(), create_time)），会让 create_time 字段无法走索引，大数据量时直接变慢查询。

实操建议：
• 范围查询永远用“字段 >= 起点 AND 字段 • 终点用 NOW() 或 CURDATE()，起点用 DATE_SUB(...) 算出来；
• 需要小时级精度（比如“最近168小时”），改用 TIMESTAMPDIFF(HOUR, create_time, NOW()) ，但注意参数顺序是 (unit, start, end)，和 DATEDIFF 相反。

跨月/跨年时，`INTERVAL 7 DAY` 比 `INTERVAL 1 WEEK` 更可靠

看起来 INTERVAL 1 WEEK 更语义化，但 MySQL 实际把它当成 INTERVAL 7 DAY 处理，两者等价。真正要注意的是：别误用 MONTH 或 YEAR 单位来代替“7天”——它们不是固定秒数，受月份天数、闰年影响。

常见错误现象：
• 写 DATE_SUB(NOW(), INTERVAL 1 MONTH) 想查“最近30天”，结果2月只有28天，查出来的范围变成32天；
• 用 INTERVAL 1 YEAR 处理生日提醒，遇到2月29日出生的人，可能返回 NULL 或错误日期。

实操建议：
• “最近七天”就是字面意义的 7 × 24 小时，只用 DAY 单位；
• 如果业务真要“近一个月”（比如账单周期），明确约定是“自然月”还是“30天滚动”，再选 MONTH 或 DAY；
• 对 DATE 类型字段，用 CURDATE() 配合 DATE_SUB；对 DATETIME/TIMESTAMP，用 NOW() 更准。

WHERE 条件里别对时间字段加函数

这是性能杀手。像 WHERE DATE(create_time) >= '2026-03-19' 或 WHERE YEAR(create_time) = 2026，都会让数据库放弃索引，全表扫描。

实操建议：
• 把函数移到右边常量侧，左边保持字段裸露：create_time >= '2026-03-19 00:00:00'；
• 动态起点用 DATE_SUB(CURDATE(), INTERVAL 7 DAY) 计算后拼进 SQL，或通过参数绑定传入预计算值；
• 如果必须按日期分组（如统计每天订单量），GROUP BY DATE(create_time) 无法避免，但至少确保 WHERE 子句没毁掉索引。

时间算术本身不难，难的是把“人想的逻辑”准确翻译成数据库能高效执行的表达式。单位大小写、函数位置、字段是否索引友好——这些细节一错，查七天可能变成查七分钟，也可能查七秒却漏掉三天数据。