mysql用date_sub(now(), interval 7 day)获取最近7天，postgresql用current_date - interval '7 days'或now() - interval '7 days'，sql server推荐dateadd(day, -7, getdate())；三者均需注意时区、索引及字段类型匹配。
MySQL 中用 DATE_SUB(NOW(), INTERVAL 7 DAY) 获取最近7天
MySQL 没有直接叫“最近7天”的函数，得靠时间计算组合实现。最常用也最稳妥的是 DATE_SUB(NOW(), INTERVAL 7 DAY)，它返回当前时间往前推7天的日期（不含时分秒），适合配合 WHERE created_at >= ... 使用。
注意：NOW() 包含时分秒，而 DATE_SUB(NOW(), INTERVAL 7 DAY) 会截断到日级；如果你的字段是 DATETIME 类型且数据精确到秒，建议统一用 DATE_SUB(NOW(), INTERVAL 7 DAY) 而不是 DATE_SUB(CURDATE(), INTERVAL 7 DAY)，后者在跨时区或凌晨执行时可能少查1小时数据。
常见错误：写成 created_at > NOW() - INTERVAL 7 DAY —— 这语法虽能运行，但隐式类型转换容易出错，尤其当 created_at 是字符串或索引失效时；明确用 DATE_SUB 更安全、可读性更强。
示例：
SELECT * FROM orders WHERE created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY);
PostgreSQL 里必须用 CURRENT_DATE - INTERVAL '7 days'
PostgreSQL 对时间运算更严格，不支持 MySQL 那种 NOW() - INTERVAL 的简写。必须显式写 CURRENT_DATE - INTERVAL '7 days' 或 NOW() - INTERVAL '7 days'，区别在于前者只比对日期部分（忽略时间），后者保留时间精度。
使用场景决定选哪个：
- 日报类统计（如“近7天订单数”）用 CURRENT_DATE - INTERVAL '7 days' 更直观；
- 实时监控（如“过去7×24小时内日志”）则必须用 NOW() - INTERVAL '7 days'，否则会漏掉今天早上的记录。
容易踩的坑：
- 忘记加单引号：写成 INTERVAL 7 days 会报错，必须是 INTERVAL '7 days'；
- 混用 now() 和 current_date 导致时区偏差，尤其当数据库 timezone 设为 UTC 而应用在东八区时，CURRENT_DATE 返回的是 UTC 的“今天”，不是你本地的“今天”。
SQL Server 怎么写？别用 GETDATE() - 7
SQL Server 支持直接用 GETDATE() - 7，但这只是历史遗留行为，本质是把 datetime 当浮点数减，语义模糊且不可移植。正确做法是用 DATEADD(day, -7, GETDATE())。
理由很实际：
- GETDATE() - 7 在 datetime2 类型上会报错；
- 它无法表达“往前推7个自然日”还是“往前推7×24小时”，遇到夏令时切换可能偏移1小时；
- 所有官方文档和执行计划都推荐 DATEADD，SQL Server 查询优化器对它识别更好，更容易命中索引。
示例（带索引友好写法）：
SELECT * FROM logs WHERE event_time >= DATEADD(day, -7, GETDATE());
通用陷阱：时区、索引、字段类型三连击
无论哪种数据库，“最近7天”查询慢或结果不对，90% 出在以下三点：
-
created_at字段没建索引，或者索引被隐式转换干掉了（比如字段是varchar存时间，查询时却用STR_TO_DATE转） - 数据库服务器时区和业务时区不一致，比如 DB 设的是
UTC，但你要查“北京时间最近7天”，直接套NOW()就会少算8小时 - 字段类型是
TIMESTAMP（MySQL）或timestamptz（PostgreSQL），但没意识到它们自动转时区，WHERE t > '2024-06-01'这种字面量比较可能被悄悄转换
最保险的做法：先确认字段类型和时区设置，再用数据库原生函数做计算，避免在 WHERE 条件里调用函数处理字段本身（例如 DATE(created_at) >= ... 会强制全表扫描）。
