CONVERT_TZ返回NULL的直接原因是MySQL时区表未加载，导致命名时区无法解析；需运行mysql_tzinfo_to_sql导入时区数据，并验证mysql.time_zone_name表非空。
phpMyAdmin 里 CONVERT_TZ 返回 NULL 怎么办
直接原因是 mysql 时区表没加载，convert_tz 没法查到目标时区的偏移规则，只能返回 null。不是语法错，也不是 phpmyadmin 限制，是底层数据缺失。
- 执行
SELECT CONVERT_TZ('2024-01-01 12:00:00', '+00:00', 'Asia/Shanghai');返回NULL？先别改 SQL，去检查时区表 - 在 phpMyAdmin 的 SQL 标签页运行：
SELECT COUNT(*) FROM mysql.time_zone_name;—— 如果结果是0，就确认没加载 - Linux 下常用修复方式：用系统命令导入（需有 MySQL root 权限），例如：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql - Windows 或 Docker 环境可能没
/usr/share/zoneinfo，得换路径或手动下载 tzdata 后导入
为什么 CONVERT_TZ 用符号时区（如 +08:00）能工作，用命名时区（如 Asia/Shanghai）就不行
因为符号时区是固定偏移，MySQL 内置支持；命名时区依赖 mysql.time_zone* 表里的历史 DST 规则 —— 这些表默认空，必须显式加载。
-
CONVERT_TZ('2024-01-01 12:00:00', '+00:00', '+08:00')永远有效，不查表 -
CONVERT_TZ('2024-01-01 12:00:00', 'UTC', 'CST')也可能失败 ——CST是模糊缩写，MySQL 不认，得用America/Chicago或Asia/Shanghai - 命名时区大小写敏感：
asia/shanghai≠Asia/Shanghai，查mysql.time_zone_name表确认实际值 - phpMyAdmin 本身不缓存时区数据，每次查询都实时读表，所以表一空，所有命名时区转换全挂
在 phpMyAdmin 中测试 CONVERT_TZ 是否真正生效的三步验证
别只看单条语句结果，要分层验证：系统级、MySQL 级、SQL 级。
- 第一步：确认 MySQL 服务已识别时区数据 —— 运行
SELECT @@system_time_zone;（显示主机时区，如CST）和SELECT @@time_zone;（当前会话时区，默认SYSTEM） - 第二步：确认命名时区可解析 —— 执行
SELECT CONVERT_TZ(NOW(), '+00:00', 'Asia/Shanghai') IS NOT NULL;，返回1才算通过 - 第三步：交叉验证 DST 行为 —— 查 2024 年 3 月 10 日（美国夏令时起始日）：
SELECT CONVERT_TZ('2024-03-10 10:00:00', 'UTC', 'America/New_York');，应返回06:00:00（非05:00:00），否则说明时区规则旧或不全
phpMyAdmin 界面里执行 CONVERT_TZ 查询的实操注意点
phpMyAdmin 只是前端，但有些 UI 行为会影响你判断问题根源。
- SQL 查询框里粘贴含中文时区名（如
上海）会报错 —— 必须用标准 IANA 名称：Asia/Shanghai，不能用本地化名称 - 如果 phpMyAdmin 显示“无返回结果”，先看右上角是否提示“0 行受影响”，那是正常（
SELECT不影响行数），不是执行失败 - 执行大范围时间转换（如对百万行表用
CONVERT_TZ）会极慢 —— 因为无法走索引，且每行都查时区表；线上慎用，优先在应用层转换 - 某些共享主机禁用
mysql.time_zone*表写入权限，你导入成功了，重启后又变空 —— 这类环境建议统一用+08:00类符号时区，避开依赖
CONVERT_TZ 调用也只会安静地返回 NULL。 
