推荐用时间范围查询替代DATE()函数以走索引：WHERE create_time >= 'YYYY-MM-DD 00:00:00' AND create_time

用 DATE_SUB(NOW(), INTERVAL 1 DAY) 获取标准日期范围

直接用 NOW() 减去一天，再配合 DATE() 截断时间部分，是最稳妥的起点。很多人写成 NOW() - INTERVAL 1 DAY 看似一样，但若字段是 DATETIME 类型且带时分秒，不显式截断会导致漏掉当天 00:00:00–23:59:59 的全部记录。

推荐写法：

SELECT * FROM orders 
WHERE DATE(create_time) = DATE(DATE_SUB(NOW(), INTERVAL 1 DAY));

注意：DATE() 会忽略索引，大数据量下性能差——这是最容易被忽略的点。

用时间范围查询避免函数包裹字段

真正想提速，就得让数据库走索引。把函数从字段上挪开，改用两个边界值做比较：

SELECT * FROM orders 
WHERE create_time >= '2024-06-14 00:00:00' 
  AND create_time < '2024-06-15 00:00:00';

实际使用中，用变量动态生成更安全：

• DATE_SUB(CURDATE(), INTERVAL 1 DAY) 得到昨天日期（如 2024-06-14）
• 拼出起始时间：CONCAT(DATE_SUB(CURDATE(), INTERVAL 1 DAY), ' 00:00:00')
• 拼出结束时间：CONCAT(CURDATE(), ' 00:00:00')

这样 create_time 字段可命中 B+ 树索引，查询速度通常提升数倍到数十倍。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

注意时区和字段类型差异

如果 MySQL 服务时区不是你本地时区（比如服务器设为 UTC，而业务按北京时间统计），CURDATE() 返回的就不是你想要的“昨天”。此时必须统一转换：

• 查当前会话时区：SELECT @@time_zone;
• 强制按东八区算昨天：CONVERT_TZ(NOW(), '+00:00', '+08:00')
• 字段是 TIMESTAMP 类型时，它自动按会话时区存储/读取，行为和 DATETIME 不同，别混用

另外，如果字段允许 NULL，WHERE create_time >= ... 自动过滤掉 NULL 值，这点要心里有数。

临时表或分区表场景下不要硬套通用写法

如果表按天做了分区（比如 PARTITION BY RANGE (TO_DAYS(create_time))），那用 DATE(create_time) = ... 反而能触发分区裁剪，比范围查询还快；但前提是分区键和查询条件严格对齐。

如果数据量极大又没分区，光靠 SQL 优化已不够，得考虑归档策略或加覆盖索引（如 INDEX idx_date_status (create_time, status)）。

最常被跳过的细节：凌晨执行定时任务时，刚过 00:00 就跑“查昨天”，但前一秒写入的记录可能还没刷盘或主从延迟未同步——这时候查不到，不是 SQL 写错了，是数据本身还没就位。