mysql的from_unixtime()和unix_timestamp()函数时区处理不对称：前者支持±hh:mm偏移量参数（如'+08:00'），后者仅依赖会话time_zone；推荐统一存utc秒数，查询时用from_unixtime(ts, '+08:00')转显。
别指望它们自动处理时区——这两个函数本身不带时区感知，转换结果完全取决于当前会话的 time_zone 设置，或你显式传入的偏移量。
FROM_UNIXTIME() 的时区参数必须是 ±HH:MM 字符串
很多人写 FROM_UNIXTIME(1717027200, 'Asia/Shanghai') 报错，是因为 MySQL（尤其 5.7 及以下）不支持命名时区作为第二个参数，除非你提前导入了时区表且确认生效。更通用、更稳的做法是用偏移量：
-
FROM_UNIXTIME(1717027200, '+08:00')→ 强制按东八区解释该时间戳 -
FROM_UNIXTIME(1717027200, '+00:00')→ 强制按 UTC 解释（推荐用于统一存储逻辑） - 不能写成
'+8:00'（缺前导零）、'CST'或'GMT+8'，MySQL 只认±HH:MM格式
UNIX_TIMESTAMP() 对输入时间的时区理解是隐式的
它把传入的 DATETIME 或字符串，**按当前会话时区理解后，再转成 UTC 秒数**。这意味着：
-
UNIX_TIMESTAMP('2024-05-30 00:00:00')在time_zone = '+08:00'下返回的是 2024-05-29 16:00:00 UTC 对应的秒数（即 1717027200 - 28800） - 如果想把“北京时间 2024-05-30 00:00:00”转成时间戳，得先确保会话时区是
'+08:00'，或改用UNIX_TIMESTAMP(CONVERT_TZ('2024-05-30 00:00:00', '+08:00', '+00:00')) - 对
TIMESTAMP类型字段调用UNIX_TIMESTAMP(col)是安全的，因为它内部已按 UTC 存储，不受会话时区影响
跨时区查询别链式嵌套太多层
想把一个 UTC 时间戳字段 ts 显示为北京时间并格式化成 2024-05-30，最简路径是：
- 直接：
FROM_UNIXTIME(ts, '+08:00')→ 得到 DATETIME 字符串，再套DATE()或DATE_FORMAT(..., '%Y-%m-%d') - 别绕：
CONVERT_TZ(FROM_UNIXTIME(ts), '+00:00', '+08:00')是冗余的——FROM_UNIXTIME(ts, '+00:00')已经按 UTC 解释了，再用CONVERT_TZ转一次，等于多算一遍 - 注意 NULL：如果
ts列允许 NULL，FROM_UNIXTIME(NULL, '+08:00')还是 NULL，聚合或展示时容易断层，建议加COALESCE(FROM_UNIXTIME(ts, '+08:00'), '1970-01-01')
WHERE 条件里永远别对时间戳字段用 FROM_UNIXTIME()
比如写 WHERE FROM_UNIXTIME(created_at) > '2024-01-01'，MySQL 无法走索引，会全表扫描。正确做法是反向转换条件：
- 把右边日期转成时间戳：
WHERE created_at > UNIX_TIMESTAMP('2024-01-01') - 如果右边也要指定时区（比如‘2024-01-01’是北京时间），那就用：
WHERE created_at > UNIX_TIMESTAMP(CONVERT_TZ('2024-01-01', '+08:00', '+00:00')) - 或者更干脆：统一在应用层把业务时间转成 UTC 时间戳再传入，数据库只存和比 UTC 秒数
真正容易被忽略的点是：FROM_UNIXTIME() 的第二个参数（时区）优先级高于会话 time_zone，但 UNIX_TIMESTAMP() 的输入解析却只认会话时区——这两者不对称，混用时极易出偏差。实际建表和查询时，建议时间戳字段全用 BIGINT 存 UTC 秒数，查的时候统一用 FROM_UNIXTIME(ts, '+08:00')，写的时候用 UNIX_TIMESTAMP(NOW() + INTERVAL 8 HOUR) 或应用层处理，避免在数据库里反复横跳时区逻辑。
