用 CURRENT_DATE 筛选当天记录时，字段为 DATE 类型可直接 WHERE date_col = CURRENT_DATE；若为 TIMESTAMP/DATETIME，则需用 DATE() 函数或范围查询（如 created_at >= CURRENT_DATE AND created_at < CURRENT_DATE + INTERVAL '1 day'）。
用 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 函数，返回当前日期（无时间），但实际值取决于数据库所在服务器的时区设置，不是客户端时区。
- 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 查询是否还能命中
