视图里不建议直接用convert_tz()：mysql 5.6+才支持该函数，低版本会创建失败；依赖时区表（如mysql.time_zone_name为空则返回null）；优先用固定偏移（如'+08:00'）替代命名时区，避免部署风险。
视图里不能直接用 CONVERT_TZ()？先确认 MySQL 版本
MySQL 5.6+ 才支持 CONVERT_TZ() 函数，低于该版本（比如 5.5 或 MariaDB 10.2 之前）调用会直接报错 FUNCTION CONVERT_TZ does not exist。视图定义中一旦包含不支持的函数，创建就会失败，不是运行时报错——这点容易被忽略。
实操建议：
- 执行
SELECT VERSION();确认版本； - 若版本不足，改用
DATE_ADD()+ 固定时区偏移（如DATE_ADD(dt, INTERVAL 8 HOUR)），但注意夏令时失效； - MariaDB 用户可查
SELECT @@version_comment;，部分旧版虽标称兼容 MySQL，实际缺该函数。
视图定义中硬编码时区名风险高
写成 CONVERT_TZ(created_at, '+00:00', 'Asia/Shanghai') 看似可行，但时区名依赖系统时区表（mysql.time_zone* 表）。如果数据库没加载时区数据（常见于 Docker 镜像或精简部署），运行视图会返回 NULL，且无任何错误提示。
实操建议：
- 运行
SELECT COUNT(*) FROM mysql.time_zone_name;，结果为 0 就得先执行mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql； - 优先用固定偏移（如
'+08:00'）代替时区名，避免依赖外部数据； - 若必须用时区名，视图里加
COALESCE(CONVERT_TZ(...), created_at)防止 NULL 污染下游逻辑。
视图字段类型受 CONVERT_TZ() 返回值影响
CONVERT_TZ() 返回的是 DATETIME 类型，即使输入是 TIMESTAMP。这意味着：如果原字段是 TIMESTAMP（自动按连接时区转换），视图里转成的 DATETIME 就不再随连接时区变化——它变成“固定时间点”的字面值。
实操建议：
- 别在视图里对
TIMESTAMP字段做CONVERT_TZ()后再存为同名字段，否则应用层可能误以为仍是时区敏感类型； - 显式命名转换后字段，例如
CONVERT_TZ(created_at, '+00:00', '+08:00') AS created_at_cst； - 注意排序、索引失效：视图字段无法直接走原表
created_at的索引，WHERE 条件若用新字段需额外考虑性能。
PostgreSQL 怎么办？没有 CONVERT_TZ()
PostgreSQL 用 AT TIME ZONE 操作符，语法和语义都不同：created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai'。它本质是把 TIMESTAMP WITHOUT TIME ZONE 当 UTC 解释，再转目标时区——和 MySQL 的 CONVERT_TZ() 行为不等价。
实操建议：
- 输入是
TIMESTAMP WITH TIME ZONE时，直接created_at AT TIME ZONE 'Asia/Shanghai'即可； - 输入是
TIMESTAMP WITHOUT TIME ZONE，必须明确其原始时区，否则结果不可靠； - PostgreSQL 视图里用
AT TIME ZONE是安全的，不依赖外部表，但要注意字符串时区名大小写敏感（'utc'不行，得'UTC'）。
