最有效写法是避免对索引列使用DATEDIFF函数，改用范围查询WHERE order_created_at < DATE_SUB(CURDATE(), INTERVAL 3 DAY)，以保持索引可用性并准确计算自然日差。
DATEDIFF 函数在 WHERE 子句中怎么写才有效
直接用 DATEDIFF 计算当前时间与订单创建时间的天数差，再和阈值比较，是最常用也最稳妥的方式。注意不同数据库对 DATEDIFF 参数顺序和单位支持不一致——MySQL 和 SQL Server 都支持 DATEDIFF(day, start_date, end_date)，但 MySQL 默认单位是 day，SQL Server 必须显式指定单位（如 day、hour），而 PostgreSQL 根本没有 DATEDIFF，得用 current_date - order_date。
实操建议：
- MySQL：用
DATEDIFF(CURDATE(), order_created_at) > 3表示超期3天以上 - SQL Server：必须写成
DATEDIFF(day, order_created_at, GETDATE()) > 3，单位不能省略 - PostgreSQL：改用
CURRENT_DATE - order_created_at > 3，结果自动为整数天 - 避免用
NOW()或GETDATE()直接参与索引字段计算，否则可能使order_created_at上的索引失效
为什么用 DATEDIFF 过滤常查不到预期数据
常见错误不是函数写错，而是时间类型没对齐。比如 order_created_at 是 DATETIME 类型，但你用 CURDATE()（只含日期）做差，MySQL 会把 order_created_at 截断为当天 00:00:00 再计算，导致刚过午夜就多算1天。
更隐蔽的问题是时区：应用写入用的是 UTC 时间，但数据库服务器或会话时区设为本地时区，GETDATE() 返回的是本地时间，两者相减就失真。
实操建议：
- 统一用带时区的时间函数：SQL Server 用
SYSDATETIMEOFFSET()，PostgreSQL 用NOW() AT TIME ZONE 'UTC' - 确认字段类型：如果只要按“日”判断，把
order_created_at转为日期再比，如CAST(order_created_at AS DATE) - 测试边界值：插入一条
order_created_at = '2024-06-01 23:59:59'的记录，看是否在 6月2日00:00 后被查出
超期逻辑要区分“自然日”还是“工作日”
DATEDIFF 算出来永远是自然日，但业务上“超期3天未处理”往往指“超过3个**工作日**”。这时候硬套 DATEDIFF 会误判节假日和周末。
实操建议：
- 简单场景：加一张
calendar表标记工作日/节假日，用子查询统计两个日期间的工作日数量 - 复杂场景：不要在 SQL 层硬算，把原始数据查出来，在应用层用成熟日期库（如 Python 的
workalendar）判断 - 临时规避：用
DATEDIFF+ 安全余量，例如要求“3个工作日”就按> 5自然日过滤，再人工复核
性能差？可能是 DATEDIFF 把索引干掉了
写成 WHERE DATEDIFF(CURDATE(), order_created_at) > 3 会让优化器放弃使用 order_created_at 上的索引，因为函数作用于列本身，无法走范围扫描。
实操建议：
- 重写为范围查询：
WHERE order_created_at （MySQL）或 <code>WHERE order_created_at （SQL Server） - 确保
order_created_at字段有索引，且类型是DATETIME或TIMESTAMP，别用字符串存时间 - 如果表极大且查询频繁，考虑加一个计算列（如
is_overdue_3d AS (order_created_at ）并建索引（MySQL 5.7+ 支持）
真正麻烦的从来不是怎么写 DATEDIFF，而是“超期”这个业务定义本身是否清晰：它是否包含节假日？是否以提交时间为准，还是以系统接收时间为准？时间戳有没有被前端篡改？这些细节一旦模糊，SQL 写得再准也没用。
