优先用 >= AND

WHERE子句里用BETWEEN还是>= AND

用 >= AND 更安全。虽然 BETWEEN '2023-01-01' AND '2023-12-31' 看起来简洁，但它会包含右边界（即 '2023-12-31 23:59:59' 会被收进来），而你真正想查的往往是「2023整年」——也就是从 '2023-01-01 00:00:00' 到 '2024-01-01 00:00:00' 之前的所有记录。

常见错误现象：BETWEEN 查不到当天最后几秒的数据，或意外多出下一天的零点记录（尤其字段是 DATETIME 或 TIMESTAMP 类型）

• 推荐写法：WHERE created_at >= '2023-01-01' AND created_at
• 如果时间字段带时分秒，别用字符串直接比对，比如 '2023-01-01' 在 MySQL 中等价于 '2023-01-01 00:00:00'，但 PostgreSQL 里可能被当作日期类型处理，隐式转换容易出错
• 显式转类型更稳：MySQL 用 CAST('2023-01-01' AS DATETIME)，PostgreSQL 用 '2023-01-01'::TIMESTAMP

时间字段是字符串类型（VARCHAR）怎么办？

必须先转成时间类型再比较，否则会按字典序比，'2023-12-01' 会小于 '2023-2-01'（因为字符 '2' '1'）

使用场景：老系统导出数据没建正确类型，或日志表里时间存成 '20230101142305' 这种格式

• MySQL：用 STR_TO_DATE(time_str, '%Y%m%d%H%i%s') 或 FROM_UNIXTIME(UNIX_TIMESTAMP(time_str))
• PostgreSQL：用 TO_TIMESTAMP(time_str, 'YYYYMMDDHH24MISS')
• 性能影响大：这类转换无法走索引，查询一慢就明显。真要高频查，得加函数索引（MySQL 8.0+ 支持，PostgreSQL 从 8.3 就支持）

时区问题让WHERE查不到数据？

数据库服务器、客户端连接、字段存储值三者时区不一致，是最隐蔽的时间范围漏查原因

常见错误现象：应用写入的是北京时间（UTC+8），但数据库 timezone 设为 UTC，结果 WHERE created_at >= '2023-01-01' 实际查的是 UTC 时间的 2023-01-01，相当于少了 8 小时

• 先确认字段真实存储值：SELECT created_at, EXTRACT(TIMEZONE_HOUR FROM created_at) FROM logs LIMIT 1（PostgreSQL）；MySQL 可用 SELECT @@time_zone, @@system_time_zone
• 统一策略优先：入库前全转成 UTC 存，查的时候也用 UTC 范围；或者全用带时区类型（如 PostgreSQL 的 TIMESTAMPTZ）
• 临时补救：MySQL 用 CONVERT_TZ(created_at, '+08:00', '+00:00')；PostgreSQL 用 created_at AT TIME ZONE 'Asia/Shanghai'

为什么加了索引还是慢？

时间字段上了索引，但 WHERE 条件里用了函数或表达式，索引就失效了

比如 WHERE DATE(created_at) = '2023-01-01' 或 WHERE YEAR(created_at) = 2023，MySQL 和 PostgreSQL 都不会走 created_at 索引

• 正确写法永远是把函数挪到右边常量侧：WHERE created_at >= '2023-01-01' AND created_at
• 如果必须按天聚合再过滤，先用子查询或 CTE 提前过滤时间范围，再对结果做 DATE() 计算
• 注意 TIMESTAMP 字段在 MySQL 中自动转时区，而 DATETIME 不转——选类型时就得想好要不要时区逻辑

时间范围查询最麻烦的从来不是语法，而是你根本不知道字段到底存的是什么、数据库以为它是什么、以及你的应用又当它是什么