mysql取最近7天应使用where date_col >= date_sub(curdate(), interval 7 day)，因curdate()返回纯日期，与date类型字段对齐更可靠，避免now()带时分秒导致的边界问题。
MySQL里用DATE_SUB和CURDATE取最近7天
MySQL没有直接的“7天前”字面量，得靠函数组合。最稳的方式是WHERE date_col >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)，注意是>=不是>，否则会漏掉今天零点的数据。
常见错误是写成DATE_SUB(NOW(), INTERVAL 7 DAY)——NOW()带时分秒，可能导致边界数据不稳定；而CURDATE()返回纯日期（如2024-06-10），跟日期类型字段对齐更可靠。
- 如果字段是
DATETIME类型且你希望包含今天全天，用>= DATE_SUB(CURDATE(), INTERVAL 7 DAY)即可 - 如果必须精确到秒、且字段含时间，可改用
>= DATE_SUB(NOW(), INTERVAL 7 DAY)，但要注意索引是否能走全 - 别用
BETWEEN写成BETWEEN ... AND CURDATE()，它默认闭区间，容易多包一天
PostgreSQL用CURRENT_DATE减整数天
PostgreSQL支持直接用-操作符减日期：WHERE date_col >= CURRENT_DATE - INTERVAL '7 days'，或者更简洁地写成CURRENT_DATE - 7——它会自动把整数解释为天数。
注意：这个语法只对DATE类型安全；若字段是TIMESTAMP，推荐显式写INTERVAL '7 days'，避免隐式转换歧义。
一款AI工具，主要用于管理 OpenClaw 所使用的来自 OpenRouter 的免费 AI 模型。自动按质量对模型进行排序，配置回退机制以应对速率限制，并更新 opencla...，适合需要提升相关任务效率的用户。
-
CURRENT_DATE不带时区，适合大多数场景；需要时区感知时改用CURRENT_DATE AT TIME ZONE 'Asia/Shanghai' - 用
generate_series做补全或对比时，记得CAST统一类型，比如generate_series(CURRENT_DATE - 7, CURRENT_DATE, '1 day')::DATE - 别混用
NOW()::DATE - 7，虽然结果一样，但NOW()触发函数执行开销略高
SQL Server里DATEADD和GETDATE配合要小心时区
SQL Server常用WHERE date_col >= DATEADD(day, -7, GETDATE())，但这里有个坑：GETDATE()返回本地服务器时区时间，如果业务按UTC存时间，查询就会偏移。
更稳妥的是先转UTC：WHERE date_col >= DATEADD(day, -7, GETUTCDATE())，尤其在跨时区部署或日志表中时间字段为UTC时必须这么做。
- 字段类型是
DATE时，GETDATE()返回值会被截断，但建议仍用CONVERT(DATE, GETDATE())显式转换，避免隐式行为 - SQL Server 2016+ 可用
SYSDATETIMEOFFSET()获取带偏移的时间，再用AT TIME ZONE转换，但日常查7天没必要这么重 - 别用
DATEDIFF(day, date_col, GETDATE()) ，它无法走索引，性能差
通用陷阱：索引失效和时区错位比语法错误更难排查
写对函数只是第一步。真正卡住人的是：明明语句能跑，但慢得像卡住，或者数据少了一天——八成是索引没命中，或者时区/类型隐式转换在捣鬼。
检查方法很简单：在WHERE条件里别对字段做函数操作（比如DATE(date_col) >= ...），也别让字段被隐式转成字符串或浮点。优先让字段单独出现在比较左侧。
- 日期字段建索引时，确认类型和查询中一致（
DATEvsDATETIME） - 应用层传入时间范围时，统一用ISO 8601格式字符串（如
'2024-06-03'），避免数据库解析歧义 - 跨数据库迁移SQL时，
INTERVAL语法几乎全不兼容，别指望复制粘贴就能用
