<p>应使用DATE()函数提取日期部分再比较，如SELECT * FROM orders WHERE DATE(created_at) >= '2024-01-01'，避免隐式转换导致时区偏差或索引失效。</p>

WHERE子句中用DATE()提取日期部分再比较

MySQL里DATETIME或TIMESTAMP字段存的是带时分秒的完整时间，直接用>= '2024-01-01'会隐式转换，可能因时区或索引失效导致查不到预期结果。稳妥做法是用DATE()函数剥离时间部分：

SELECT * FROM orders WHERE DATE(created_at) >= '2024-01-01' AND DATE(created_at) <= '2024-01-31';

但要注意：DATE()会让created_at上的索引失效，大数据量时性能明显下降。

更高效：用范围比较避开函数包裹列

把条件改写成对原始列的闭区间比较，让数据库能走索引：

SELECT * FROM orders WHERE created_at >= '2024-01-01 00:00:00' AND created_at < '2024-02-01 00:00:00';

关键点：
• 左闭右开（）比<code>更安全，避免毫秒截断误差<br>• 不依赖函数，<code>created_at有索引就能命中
• PostgreSQL/SQL Server也适用，只是时间字面量格式略有差异（如PostgreSQL支持'2024-01-01'::date）

不同数据库的DATE()行为差异

不是所有数据库都支持DATE()函数，且语义不统一：
• MySQL：返回DATE类型，可直接和字符串比较
• PostgreSQL：没有DATE()函数，得用created_at::date或CAST(created_at AS DATE)
• SQL Server：用CAST(created_at AS DATE)，CONVERT(DATE, created_at)也可
• SQLite：用DATE(created_at)，但只对ISO8601格式（如'2024-01-01 12:34:56'）可靠，自定义格式需先strftime()

时区问题常被忽略

如果数据库服务器、应用连接、字段值本身跨不同时区，DATE(created_at)返回的可能是错的日期。例如UTC存储的'2024-01-01 23:00:00'在东八区DATE()出来是'2024-01-02'。
• 查前先确认created_at存的是本地时间还是UTC
• 连接层设置时区（如MySQL加?serverTimezone=Asia/Shanghai）
• 必要时用CONVERT_TZ()（MySQL）或AT TIME ZONE（PostgreSQL/SQL Server）做显式转换