优先用 >= AND < 而非 BETWEEN 或函数操作，避免索引失效；入库统一转 UTC 或使用带时区类型；查时用 UTC 范围或 AT TIME ZONE 转换，确保时区一致。
WHERE 子句里用 BETWEEN 还是 >= AND
用 >= AND 更安全。虽然 <code>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不转——选类型时就得想好要不要时区逻辑
时间范围查询最麻烦的从来不是语法，而是你根本不知道字段到底存的是什么、数据库以为它是什么、以及你的应用又当它是什么
