MySQL中FROM_UNIXTIME()转换时间戳需注意时区、引号、NULL及类型溢出：时区用'+08:00'显式指定；格式化字符串须加单引号；NULL返回NULL需COALESCE处理；大整数应防科学计数法溢出。
MySQL 用 FROM_UNIXTIME() 转时间戳，但要注意时区
直接调用 FROM_UNIXTIME(1717027200) 会按 MySQL 当前会话时区返回日期，不是 UTC 也不是你本地系统时区——它只认 TIMESTAMP 类型的隐式转换规则。如果你的服务器时区是 +00:00，而应用逻辑默认东八区，结果就差 8 小时。
- 查当前会话时区：
SELECT @@time_zone;，常见值是SYSTEM（继承系统）或具体偏移如'+08:00' - 强制指定时区转换：
FROM_UNIXTIME(1717027200, '+08:00')—— 第二个参数必须是带符号的字符串，不能写'CST'或'Asia/Shanghai' - 如果字段是
BIGINT存秒级时间戳，直接传入即可；毫秒级要先除以 1000：FROM_UNIXTIME(UNIX_TIMESTAMP_MS / 1000)
FROM_UNIXTIME() 的格式化参数容易漏掉引号
很多人写 FROM_UNIXTIME(ts, %Y-%m-%d) 报错，其实是忘了格式化字符串必须加单引号。MySQL 不会自动补，报错信息是 ERROR 1064 (42000)，看着像语法问题，实际只是引号缺失。
- 正确写法：
FROM_UNIXTIME(1717027200, '%Y-%m-%d %H:%i:%s') - 常用占位符：年
%Y（4 位）、月%m（补零）、日%d、时%H（24 小时制）、分%i（注意是字母 i，不是 L） - 不传第二个参数时，默认返回
'YYYY-MM-DD HH:MM:SS'格式的字符串，不是DATETIME类型——但能被 MySQL 自动转，不影响 WHERE 条件比较
和 UNIX_TIMESTAMP() 配合用时，NULL 值会导致意外空结果
FROM_UNIXTIME() 对 NULL 输入返回 NULL，看起来合理，但容易在聚合或 JOIN 中被忽略。尤其当源字段允许 NULL，又没做前置判断，查出来的日期列就突然断层。
- 安全写法：
COALESCE(FROM_UNIXTIME(ts), '1970-01-01')或IFNULL(FROM_UNIXTIME(ts), '0000-00-00') - 注意：
UNIX_TIMESTAMP('0000-00-00')返回NULL，反过来不成立 ——FROM_UNIXTIME(NULL)是NULL，但FROM_UNIXTIME(0)是'1970-01-01 08:00:00'（按当前时区） - 如果用于索引字段转换，别在 WHERE 里写
FROM_UNIXTIME(create_time) > '2024-01-01'——这无法走索引，应改用create_time > UNIX_TIMESTAMP('2024-01-01')
PHP/Python 写 SQL 时拼接时间戳要防整型溢出
PHP 的 time() 和 Python 的 int(time.time()) 在 32 位环境可能超 int 范围，MySQL 的 FROM_UNIXTIME() 虽然支持大整数，但拼 SQL 时若用字符串拼接，一不小心就会把时间戳当科学计数法处理（比如 PHP 默认 float 输出）。
- PHP 中确保传整型：
(int)time()或strval(time())显式转字符串 - Python 中用
str(int(time.time()))，别用f"{time.time():.0f}"—— 浮点转整可能有精度误差 - 更稳妥的方式：交给预处理语句，让驱动处理类型，比如 PDO 绑定
PDO::PARAM_INT，避免手动拼接
