跨天统计出错主因是时区未对齐，需按字段语义选类型：TIMESTAMP/TIMESTAMPTZ适配带时区时间点，DATETIME/TIMESTAMP WITHOUT TIME ZONE仅适用于无时区含义的本地时间，DATE类型最适“当日”统计；避免用HOUR()、DATE()函数分组或过滤，应统一转换至目标时区后按字符串格式截取或用范围查询。
跨天统计出错，八成是因为时区没对齐——不是SQL写错了，是时间字段的语义和数据库/连接层的时区设置打架了。
确认时间字段类型和业务语义
先别急着写WHERE，看清楚你查的字段到底存的是什么：
-
TIMESTAMP类型（MySQL）或TIMESTAMPTZ（PostgreSQL）：默认按服务器时区转为UTC存储，查询时再转回会话时区。适合“带时区的时间点”，比如用户登录时间。 -
DATETIME（MySQL）或TIMESTAMP WITHOUT TIME ZONE（PostgreSQL）：纯本地时间，不自动转换。适合“固定营业时间”这类无时区含义的值，但不能用于跨时区统计。 -
DATE类型：只关心年月日，不涉及时分秒和时区。做“当日订单量”统计时，应优先用这个类型存日期，而不是从DATETIME里DATE()截取。
如果原始日志时间存的是 UTC，但字段类型是 DATETIME，那它其实是个“假本地时间”——后续所有 HOUR()、DATE() 都会按服务器时区解释，结果必然偏移。
避免用 HOUR() 或 DATE() 直接分组
写 GROUP BY HOUR(login_time) 或 WHERE DATE(order_time) = '2026-08-04' 是高危操作：
-
HOUR()不区分日期，23:59 和 00:01 被分到不同组，但实际可能属于同一业务“凌晨高峰”； -
DATE(order_time)强制走函数索引，哪怕order_time有B-tree索引也会全表扫描； - 更致命的是：这些函数全部依赖会话时区（
@@time_zone），如果连接没设时区，就按服务器默认值跑，UTC 和北京时间混在一起，跨天边界直接错位。
正确做法是把时间槽拉到“年-月-日-小时”粒度：DATE_FORMAT(login_time, '%Y-%m-%d %H')（MySQL）或 TO_CHAR(login_time AT TIME ZONE 'Asia/Shanghai', 'YYYY-MM-DD HH24')（PostgreSQL）。
跨天范围查询必须用“>= +
别用 BETWEEN '2026-08-04' AND '2026-08-04'，它隐式转成 '2026-08-04 00:00:00'，漏掉全天99.9%的数据。
- 查北京时间 2026-08-04 整天：用
login_time >= '2026-08-04 00:00:00' AND login_time ； - 如果原始数据存的是 UTC，而你要按北京时间统计，就得先转换：
CONVERT_TZ(login_time, '+00:00', 'Asia/Shanghai') >= '2026-08-04 00:00:00' AND CONVERT_TZ(login_time, '+00:00', 'Asia/Shanghai') ； - 注意：
CONVERT_TZ返回 NULL 的常见原因是 MySQL 时区表没加载，执行SELECT COUNT(*) FROM mysql.time_zone_name确认非空，否则得手动运行mysql_tzinfo_to_sql加载。
应用层传参比数据库内转换更可靠
在 WHERE 里反复调用 CONVERT_TZ 或 AT TIME ZONE，不仅性能差，还容易因时区名拼写（CST vs Asia/Shanghai）、版本差异（MySQL 不支持 AT TIME ZONE）翻车。
- 推荐做法：前端或后端明确指定业务时区（如
Asia/Shanghai），算好起止时间戳（如2026-08-04T00:00:00+08:00→2026-08-03T16:00:00Z），然后以 UTC 时间传给 SQL 查询； - 数据库只存 UTC，所有
WHERE条件都用 UTC 时间比较，彻底规避时区函数开销和兼容性问题； - 展示层再按需转回本地时区，比如用
FROM_UNIXTIME(utc_ts + 28800)（+8小时秒数）或应用层格式化。
真正麻烦的从来不是语法，而是时间字段到底代表什么——是某个瞬间的绝对时刻，还是某地某刻的相对读数。没理清这点，再漂亮的SQL也救不了跨天统计。
