CURDATE()最直接但需注意字段类型和时区；用于DATE字段可直接比较，DATETIME/TIMESTAMP应改用>=CURDATE() AND
CURDATE() 是最直接的方式，但必须注意字段类型和时区问题，否则查不到数据。
为什么用 CURDATE() 而不是 NOW() 或 SYSDATE()
CURDATE() 只返回日期部分（如 '2024-06-15'），不带时间，适合和 DATE 类型字段直接比较；而 NOW() 和 SYSDATE() 返回完整时间戳（如 '2024-06-15 14:23:05'），若字段是 DATETIME 或 TIMESTAMP，直接用 = CURDATE() 会隐式转成 '2024-06-15 00:00:00'，漏掉当天其他时间的记录。
- 推荐场景：字段类型为
DATE，且只要当天整日数据 → 直接WHERE date_col = CURDATE() - 常见误用：字段是
DATETIME，却写WHERE dt_col = CURDATE()→ 实际只匹配到 00:00:00 那一行 - 更安全的写法（对
DATETIME/TIMESTAMP）：WHERE DATE(dt_col) = CURDATE()，但注意这会让dt_col上的索引失效
DATE() 函数包裹字段的代价与替代方案
用 DATE(dt_col) = CURDATE() 看似简洁，但 MySQL 无法使用 dt_col 的 B+ 树索引，会导致全表扫描——尤其在百万级表上响应明显变慢。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 高效替代写法：
WHERE dt_col >= CURDATE() AND dt_col - 这个范围查询能命中
dt_col上的索引（前提是该列有索引） - 注意不要写成
dt_col ，容易因微秒/时区偏差漏数据 - 如果应用部署在多个时区，确认 MySQL 服务器时区（
SELECT @@time_zone）和业务期望是否一致
时区不一致导致查不到数据的典型表现
执行 SELECT CURDATE(), NOW() 发现日期比你本地时间早/晚一天，或者查出来的记录明显少于预期，大概率是时区配置问题。
- 检查当前会话时区：
SELECT @@session.time_zone - 检查全局时区：
SELECT @@global.time_zone - 临时修正（当前会话）：
SET time_zone = '+08:00' - 永久修正需修改 MySQL 配置文件
my.cnf中的default-time-zone='+08:00'并重启服务 - 应用层写入时间时若用的是 UTC，而查询用
CURDATE()（按服务器本地时区），结果必然错位
真正关键的不是函数怎么写，而是搞清字段存的是什么时区、MySQL 解释时间的上下文在哪一层——数据库、连接、会话、应用，四个地方时区只要一个没对齐，CURDATE() 就会“失准”。
