因时区未统一导致日期归类错位：UTC时间'2024-05-01 18:30:00'在东八区实属'2024-05-02'，需用AT TIME ZONE（PostgreSQL）或CONVERT_TZ（MySQL）转目标时区后再截取日期分组。
GROUP BY日期字段时，为什么聚合结果看起来“少了一天”或“多了一天”
因为数据库存储的 datetime 或 timestamp 值在按日期分组时，默认使用服务器时区解析，而你的业务逻辑可能要求按用户本地时区（比如 'Asia/Shanghai'）归日。例如：一条记录在 UTC 时间是 '2024-05-01 18:30:00'，服务器时区为 UTC，DATE(col) 得到 '2024-05-01'；但若用户在东八区，它实际属于 '2024-05-02'，直接 GROUP BY 就会错位。
PostgreSQL 中用 AT TIME ZONE 正确按本地日期聚合
PostgreSQL 支持带时区的转换，关键不是改数据，而是把时间值临时转成目标时区后再截日期：
-
GROUP BY (col AT TIME ZONE 'Asia/Shanghai')::date—— 这才是按北京时间归日 - 不要写
GROUP BY col::date，它无视时区，等价于col AT TIME ZONE current_setting('timezone') - 如果
col是timestamp without time zone，必须先声明其原始时区，例如：(col AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai')::date - 索引失效风险：对列做函数转换后无法走
col上的普通 B-tree 索引，可建表达式索引：CREATE INDEX idx_orders_date_shanghai ON orders (( (created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai')::date ));
MySQL 8.0+ 处理时区日期聚合的实操限制
MySQL 没有 AT TIME ZONE，得靠 CONVERT_TZ()，但它对输入类型敏感，容易静默失败：
-
CONVERT_TZ(col, '+00:00', '+08:00')仅对DATETIME有效；若col是TIMESTAMP，它已隐式转为系统时区，再套用会重复转换 - 安全写法是显式转成 UTC 再转目标时区：
DATE(CONVERT_TZ(CONVERT_TZ(col, @@session.time_zone, '+00:00'), '+00:00', '+08:00')) - 注意
@@session.time_zone可能是SYSTEM，此时需先查清系统时区：SELECT @@system_time_zone; - MySQL 不支持表达式索引，所以
GROUP BY DATE(CONVERT_TZ(...))必然全表扫描，大数据量务必提前物化日期字段
时区聚合偏差最常被忽略的两个点
一是夏令时边界（如 '2024-11-03 01:30' 在美国东部时间可能不存在或重复），AT TIME ZONE 和 CONVERT_TZ() 行为不同，PostgreSQL 会返回 NULL 或自动跳过，MySQL 可能回退到标准时间；二是跨时区统计口径不一致——比如订单按用户时区归日，但支付成功时间按支付网关时区（UTC）记录，二者不能直接 GROUP BY 同一个“日期”字段，必须统一锚点。
