最直接的方式是用 where date_column >= date_sub(current_date, interval 7 day)，因 current_date 返回纯日期，与 date 类型字段对齐更安全；若用 now() 可能漏掉今天凌晨数据。
WHERE条件里用DATE_SUB()还是CURRENT_DATE？
MySQL里查最近7天，最直接的方式是用 WHERE date_column >= DATE_SUB(CURRENT_DATE, INTERVAL 7 DAY)。注意别写成 DATE_SUB(NOW(), INTERVAL 7 DAY)——NOW()带时间部分，如果字段是 DATE 类型，可能漏掉今天凌晨的数据；而 CURRENT_DATE 返回纯日期，和 DATE 字段对齐更安全。
常见错误：WHERE date_column > DATE_SUB(CURRENT_DATE, INTERVAL 7 DAY) 会漏掉第7天当天的全部数据（因为是“大于”，不是“大于等于”）。
- 字段类型是
DATETIME且想包含时间精度？用NOW()更合适，但要确认时区一致 - PostgreSQL 用户请换用
WHERE date_column >= CURRENT_DATE - INTERVAL '7 days' - SQL Server 用
WHERE date_column >= DATEADD(day, -7, GETDATE())，但注意GETDATE()包含时间，建议搭配CAST(GETDATE() AS DATE)截断
时间字段没索引，查询慢得离谱怎么办？
加了 WHERE date_column >= ... 却依然扫描全表？大概率是 date_column 没建索引。尤其当表数据量超过几万行，没索引的范围查询基本不可用。
执行 EXPLAIN SELECT ... 看 type 是不是 ALL（全表扫描），key 列是否为空。如果是，立刻建索引：
CREATE INDEX idx_date ON your_table (date_column);
如果经常按日期+其他字段联合过滤（比如 WHERE date_column >= ... AND status = 'active'），考虑联合索引：CREATE INDEX idx_date_status ON your_table (date_column, status);。顺序很重要：范围查询字段（date_column）必须放前面。
时区不一致导致“查不到昨天的数据”
数据库服务器、应用连接、甚至客户端设置的时区不统一，会让 CURRENT_DATE 返回值出人意料。比如数据库设为 UTC，而你本地是东八区，那 CURRENT_DATE 比你预期的“今天”晚8小时。
验证方式：运行 SELECT CURRENT_TIME, @@time_zone; 看当前会话时区；再查 SELECT @@global.time_zone, @@session.time_zone;。
- 临时修复：连接时显式指定时区，如 MySQL JDBC URL 加
?serverTimezone=Asia/Shanghai - 长期方案：统一数据库时区为
+08:00或Asia/Shanghai，并确保所有应用层不自行转换时间 - 避免在 SQL 里硬编码时区偏移（如
DATE_SUB(CURRENT_DATE, INTERVAL 7 HOUR)），极易出错
业务上“最近7天”到底指哪7天？
技术上能算出时间范围，但业务含义常有歧义：是“从今天往前推7×24小时”，还是“包含今天在内的最近7个自然日”？前者用 CURRENT_DATE - INTERVAL 6 DAY 到 CURRENT_DATE；后者才是真正的“最近7天”，即 WHERE date_column BETWEEN DATE_SUB(CURRENT_DATE, INTERVAL 6 DAY) AND CURRENT_DATE。
容易被忽略的是周末或节假日是否计入——如果业务要求“最近7个工作日”，SQL 就无法直接解决，得靠预生成的日期维表或应用层过滤。
还有个坑：某些系统把“最近7天”理解为“过去7天内产生的数据”，但记录时间字段（如 created_at）可能因延迟写入、批量导入等原因，实际时间戳早于业务发生时间。
