子查询中CONVERT_TZ必须显式加AS别名，否则外层无法引用；且需确保mysql.time_zone_name表已加载时区数据，否则返回NULL。
子查询里直接用 CONVERT_TZ 却外层查不到字段？不是函数写错了，是列没暴露出来——所有时区转换必须显式加 AS 别名，否则外层根本看不见。
子查询中 CONVERT_TZ 必须配 AS 别名
MySQL 的列可见性规则很严格：子查询 SELECT 列表中任何表达式，若没用 AS 显式命名，外层就无法引用。哪怕你写了 CONVERT_TZ(created_at, '+00:00', '+08:00')，外层 SELECT 或 WHERE 里直接写 local_time 会报 Unknown column 'local_time' in 'field list'。
- 正确写法：
CONVERT_TZ(created_at, '+00:00', '+08:00') AS local_time - 别名要语义清晰，避免用
time这类泛称，推荐local_created_at或beijing_time - 如果子查询还带
GROUP BY或ORDER BY，必须对这个别名操作，不能回退到原始字段
别在子查询里套 DATE_FORMAT
DATE_FORMAT(local_time, '%Y-%m-%d %H:%i') 看似方便，但一执行就变成字符串，外层再想按时间排序、计算差值、或和另一个 DATETIME 字段比较，全得隐式转类型——性能掉、精度丢、索引失效。
- 子查询只做「时区转换」，保持返回类型为
DATETIME或TIMESTAMP - 格式化统一收口到最外层
SELECT，比如SELECT DATE_FORMAT(t.local_time, '%Y-%m-%d %H:%i') FROM (…) - 这样调试也简单：先跑子查询确认
local_time值对不对，再加格式化层
CONVERT_TZ 返回 NULL？先查时区表有没有加载
写对了语法却返回 NULL，90% 是因为 MySQL 根本不认识你写的时区名。比如 'Asia/Shanghai' 看着标准，但若 mysql.time_zone_name 表为空，它就是个普通字符串。
- 检查命令：
SELECT COUNT(*) FROM mysql.time_zone_name;—— 返回 0 就得加载 - Linux 加载命令：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql - 时区名必须完全匹配
mysql.time_zone_name.Name字段值，CST、PDT不可靠，优先用Asia/Shanghai、America/New_York -
CONVERT_TZ第一个参数不能是字符串字面量（如'2025-05-19'），得是DATETIME类型；若原始字段是字符串，先在子查询里用STR_TO_DATE()转
嵌套多层时，时区转换尽量压到最内层子查询
三层嵌套里，外层查内层的 local_time，中间层又做了额外计算——这时如果时区转换放在中间层，外层拿到的可能已是被二次处理过的值，逻辑链变长、出错难定位。
- 原则：谁负责“统一时间标准”，谁就该最先完成时区转换
- 典型结构：最内层子查询从原始表取数据 +
CONVERT_TZ→ 中间层聚合或关联 → 外层格式化或筛选 - 如果中间层需要按本地时间分组，
GROUP BY local_time，别用GROUP BY DATE(local_time)，后者不走索引；真要按天聚合，考虑提前建生成列+索引
真正容易被忽略的是时区表加载状态和别名强制要求——这两点不满足，CONVERT_TZ 再怎么写都白搭。别急着调逻辑，先 SELECT COUNT(*) FROM mysql.time_zone_name 看一眼。
