推荐使用 now() - interval 1 day 作为 where 条件,语义清晰且索引友好;需确保 created_at 为 datetime/timestamp 类型并已建索引;注意 mysql 时区与业务写入时区一致,避免漏数据。

WHERE条件里用NOW()减去时间间隔
直接用 NOW() 配合 INTERVAL 是最常用也最稳妥的方式,MySQL会自动处理时区和类型转换。别用字符串拼接时间或硬写固定时间戳,容易出错且不走索引。
-
WHERE created_at >= NOW() - INTERVAL 1 DAY—— 推荐,语义清晰,索引友好 -
WHERE created_at >= DATE_SUB(NOW(), INTERVAL 24 HOUR)—— 等价,但稍冗长 - 避免
WHERE created_at >= '2024-05-20 10:00:00'—— 时间写死,无法复用,还可能因时区错位漏数据
确认created_at字段类型和索引存在
如果查得慢或返回空,大概率是字段类型不对或没索引。MySQL对 DATETIME 和 TIMESTAMP 支持 INTERVAL 运算,但如果是 VARCHAR 存的时间,NOW() - INTERVAL 会静默转成0,导致查不到任何数据。
- 执行
DESCRIBE your_table;看created_at的Type是否为DATETIME或TIMESTAMP - 执行
SHOW INDEX FROM your_table WHERE Key_name = 'PRIMARY' OR Column_name = 'created_at';确认有索引 - 没索引的话,加一个:
ALTER TABLE your_table ADD INDEX idx_created_at (created_at);
注意时区设置影响结果范围
NOW() 返回的是 MySQL 服务端当前时区的时间,不是你本地电脑的时区。如果你的应用写入时间用的是 UTC,但 MySQL 配置是 SYSTEM(比如服务器在东八区),那 NOW() - INTERVAL 1 DAY 实际查的是东八区过去24小时,会漏掉 UTC 时间跨天的数据。
MySQL 9.6.0是面向Linux平台的2026年创新版本,核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层,确保所有数据变更均被完整记录至Binlog,彻底解决了CDC(变更数据捕获)与主从复制中的数据不一致难题。此外,该版本引入container_aware启动选项以原生适配容器环境,并对审计日志进行了组件化重构,为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 查当前会话时区:
SELECT @@time_zone; - 临时切 UTC 查询:
SET time_zone = '+00:00'; SELECT ... WHERE created_at >= NOW() - INTERVAL 1 DAY; - 长期建议统一写入和查询都用 UTC,并把 MySQL 全局时区设为
+00:00
业务数据量大时考虑分页或采样
如果单次查出几十万行,应用端可能 OOM,或者拖慢线上数据库。不要一上来就 SELECT *,先确认是否真需要全部数据。
- 加
LIMIT快速验证逻辑:SELECT id, created_at, status FROM orders WHERE created_at >= NOW() - INTERVAL 1 DAY LIMIT 100; - 导出用分批拉取,比如按
id分段:WHERE created_at >= ... AND id BETWEEN 10000 AND 20000 - 统计场景优先用
COUNT(*),别查全量再数
时区、字段类型、索引这三点卡住大多数人的实际查询,比语法本身更容易出问题。










