用 current_date 筛选当天记录时，字段为 date 类型可直接 where date_col = current_date；若为 timestamp/datetime，则需用 date() 函数或范围查询（如 created_at >= current_date and created_at

用 CURRENT_DATE 筛选当天记录时，日期字段类型决定写法

直接用 WHERE date_col = CURRENT_DATE 只在字段是 DATE 类型时才安全。如果字段是 TIMESTAMP 或 DATETIME（比如 MySQL 的 DATETIME、PostgreSQL 的 TIMESTAMP WITHOUT TIME ZONE），因为带时间部分，= 几乎永远不成立。

• MySQL 中 created_at DATETIME 字段：用 DATE(created_at) = CURRENT_DATE 或 created_at >= CURRENT_DATE AND created_at
• PostgreSQL 中推荐后者（索引友好）：created_at >= CURRENT_DATE AND created_at
• SQLite 用 date(created_at) = date('now')，但注意 date() 函数会阻止索引使用

CURRENT_DATE 在不同数据库里的行为差异

CURRENT_DATE 本身是标准 SQL 函数，返回当前日期（无时间），但实际值取决于数据库所在服务器的时区设置，不是客户端时区。

秒哒

秒哒 是一款百度推出的零代码 AI 应用生成平台。

下载

• PostgreSQL：默认按服务器 timezone 配置返回，可通过 SET timezone = 'Asia/Shanghai' 临时调整
• MySQL：受 time_zone 系统变量影响，SELECT @@time_zone 可查当前值；若设为 SYSTEM，则依赖系统时钟
• SQL Server 没有 CURRENT_DATE，得用 CAST(GETDATE() AS DATE)

为什么用范围查询比 DATE() 函数更推荐

对带时间的列做函数包装（如 DATE(created_at) = CURRENT_DATE）会让数据库无法使用 created_at 上的索引，全表扫描风险高，尤其数据量大时延迟明显。

• 正确姿势是把函数移到右边：created_at >= CURRENT_DATE AND created_at
• 这个写法在 MySQL / PostgreSQL / Oracle 中都支持索引下推（Index Seek）
• SQL Server 对应写法：created_at >= CAST(GETDATE() AS DATE) AND created_at

容易忽略的时区陷阱和测试建议

线上数据库很可能运行在 UTC 时区，而业务要求的是「北京时间当日」，这时直接用 CURRENT_DATE 会少查或错查数据。

• 先确认数据库时区：SHOW VARIABLES LIKE '%time_zone%'（MySQL）、SHOW TIMEZONE（PostgreSQL）
• 如果服务器是 UTC，要查北京时间当日，得用偏移：CURRENT_DATE AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai'（PostgreSQL），MySQL 需配合 CONVERT_TZ(NOW(), '+00:00', '+08:00')
• 上线前务必用真实数据+跨零点时间测试，比如在 23:59 插入一条记录，看次日 00:01 查询是否还能命中