直接用 CONVERT_TZ() 后 GROUP BY DATE() 会出错，因 DATE() 不接受显式时区上下文，会隐式转为服务器本地时区再截取日期，导致跨天偏差；正确做法是用 DATE(CONVERT_TZ(...)) 并指定 IANA 时区名（如 'Asia/Tokyo'），避免变量或缩写，且应通过生成列+索引或应用层预计算提升性能。
为什么直接用 CONVERT_TZ() 后 GROUP BY DATE() 会出错？
因为 CONVERT_TZ() 返回的是带时区的 DATETIME，而 DATE() 函数在 MySQL 中会先隐式转成系统时区再截日期——如果你的 MySQL 服务器时区是 +00:00，但用户在东京（+09:00），CONVERT_TZ(created_at, '+00:00', '+09:00') 得到的是 2024-05-20 09:12:33，可 DATE() 却可能按服务器本地时间（UTC）取成 2024-05-20，也可能因隐式转换逻辑不一致变成 2024-05-19。根本问题不是函数不会转，而是 DATE() 不接受显式时区上下文。
正确做法：用 DATE(CONVERT_TZ(...)) 但必须确保时区参数为字符串字面量或命名时区
MySQL 的 CONVERT_TZ() 第二、三参数必须是合法时区描述，不能是变量或表达式（除非启用了 explicit_defaults_for_timestamp=OFF 且 MySQL 版本 ≥ 8.0.19）。常见踩坑点：
-
CONVERT_TZ(created_at, '+00:00', @@session.time_zone)—— 表面合理，但@@session.time_zone若是SYSTEM，仍走服务器默认时区，不可控 - 用缩写如
'PST'或'CET'—— 不推荐，MySQL 依赖系统 tzdata，不同机器行为可能不一致 - 正确写法是使用 IANA 时区名（如
'Asia/Tokyo'、'America/New_York'）或完整偏移字符串（如'+08:00'）
示例（按东京本地自然日统计）：
SELECT DATE(CONVERT_TZ(created_at, '+00:00', 'Asia/Tokyo')) AS local_date, COUNT(*) FROM events GROUP BY DATE(CONVERT_TZ(created_at, '+00:00', 'Asia/Tokyo'));
性能关键：别在 GROUP BY 里重复写 CONVERT_TZ()
上面的 SQL 在 GROUP BY 和 SELECT 里各算了一次 CONVERT_TZ()，MySQL 无法自动复用。如果表很大，又没索引支持，会全表扫描+多次时区计算。更稳妥的做法是：
- 加生成列（MySQL 5.7+）：
ALTER TABLE events ADD COLUMN created_date_jp DATE AS (DATE(CONVERT_TZ(created_at, '+00:00', 'Asia/Tokyo'))) STORED;，然后建索引：CREATE INDEX idx_created_date_jp ON events(created_date_jp); - 或者在应用层预计算好“本地自然日”并存为普通字段（比如
event_date_jp），避免每次查询都算 - 注意：生成列 + 索引只对固定目标时区有效；多时区需求建议用应用层处理或物化视图思路
PostgreSQL 用户注意：AT TIME ZONE 行为完全不同
PostgreSQL 没有 CONVERT_TZ()，而是用 AT TIME ZONE，但它分两步：先解释输入时间的时区含义，再转为目标时区。例如：
-- 假设 created_at 是 TIMESTAMP WITHOUT TIME ZONE，存的是 UTC SELECT (created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Tokyo')::DATE AS local_date FROM events;
这里第一个 AT TIME ZONE 'UTC' 把无时区时间当作 UTC 解释，第二个再转成东京时间。漏掉第一步就会误把输入当成本地时间处理，结果偏移整整一天。另外 PostgreSQL 的 ::DATE 是基于当前会话时区的，所以必须用双重 AT TIME ZONE 显式锚定，不能依赖会话设置。
时区转换本身不难，难的是让「自然日」这个业务概念和数据库的日期函数严格对齐——它要求你明确每一步的时间语义：原始字段是什么时区？目标本地日的定义依据是什么？数据库函数到底在哪个环节做解释、哪个环节做转换。少一个环节，GROUP BY 就可能跨天聚合。
