子查询中使用convert_tz需显式添加as别名，否则外层无法引用；时区转换应放在子查询，格式化（如date_format）应移至外层以保持时间类型和索引友好性。
子查询里用 CONVERT_TZ 会报错：Unknown column in 'field list'
常见现象是：外部查询 SELECT 里引用了子查询的某个时间字段，但子查询内部直接对 created_at 做 CONVERT_TZ(created_at, '+00:00', '+08:00')，结果外部查不到这个别名，或者提示字段不存在。
根本原因不是函数写错了，而是 MySQL 的列可见性规则——子查询中未显式 AS 别名的表达式，在外层无法被引用；而且 CONVERT_TZ 返回的是 DATETIME 类型，如果原字段是 TIMESTAMP，隐式转换还可能触发时区双重应用。
- 子查询中所有需要被外层使用的计算字段，必须加
AS别名，比如CONVERT_TZ(created_at, '+00:00', '+08:00') AS local_time - 避免在子查询里做格式化（如
DATE_FORMAT），那会让字段变成字符串，丧失时间运算能力 - 确认数据库服务器、会话、表字段三者的时区设置是否一致，
SELECT @@time_zone, @@session.time_zone可查
DATE_FORMAT 放在子查询还是外层更安全？
放在外层更可控。子查询只负责「转换时区」，外层再「格式化显示」，这样既保留时间类型语义，又避免子查询结果被缓存或优化掉精度。
例如子查询返回 local_time 是 DATETIME，外层用 DATE_FORMAT(local_time, '%Y-%m-%d %H:%i') 输出，比在子查询里直接 DATE_FORMAT(CONVERT_TZ(...), ...) 更易调试、复用、索引友好。
- 子查询中只做
CONVERT_TZ或FROM_UNIXTIME(..., '+08:00')这类类型保持的操作 - 格式化统一收口到最外层 SELECT，方便改样式、适配不同语言环境
- 如果子查询带
GROUP BY或ORDER BY，务必对转换后字段（如local_time）操作，而不是原始字段
PostgreSQL 用户注意：AT TIME ZONE 的括号和顺序很关键
MySQL 用 CONVERT_TZ，PostgreSQL 用 AT TIME ZONE，但语法容易写反。常见错误是把目标时区放前面，比如 'UTC' AT TIME ZONE 'Asia/Shanghai' ——这其实是把字符串 'UTC' 当作本地时间，再转成上海时区，逻辑全反了。
正确写法是：原始时间值 AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai'，等价于先转成 UTC 时间戳，再解释为上海本地时间（即 +8 小时）。中间不能省略第一个 AT TIME ZONE。
- 必须是
timestamp_column AT TIME ZONE 'source_tz' AT TIME ZONE 'target_tz' - 如果字段本身是
TIMESTAMP WITH TIME ZONE，只需一次AT TIME ZONE 'target_tz' - 时区名推荐用
Asia/Shanghai而非+08:00，避免夏令时歧义
嵌套太深时，CONVERT_TZ 性能会明显下降
每层子查询调用一次 CONVERT_TZ，MySQL 就要重复解析时区规则、查时区表（mysql.time_zone*），5 层嵌套可能让单条查询慢 3 倍以上，尤其在没建索引的字段上。
真实业务中，与其在多层子查询里反复转换，不如提前在视图或物化中间表里固化本地时间字段，或者改用应用层转换——数据库只存 UTC，由代码按用户时区渲染。
- 检查
mysql.time_zone_name是否有数据，没有就运行mysql_tzinfo_to_sql导入 - 在子查询中避免对非索引字段（如
CONVERT_TZ(log_time, ...)）做WHERE或JOIN条件 - 如果只是展示用，考虑把时区转换逻辑移到应用层，数据库压力小，也更容易灰度切换
