MySQL中FROM_UNIXTIME()函数可将Unix时间戳（如1717027200）直接转为可读的YYYY-MM-DD HH:MM:SS格式（如2024-05-30 00:00:00），支持毫秒时间戳除1000处理、自定义格式化输出、时区依赖及NULL/非法值返回NULL，需注意INT溢出和合法时间范围。
MySQL里用FROM_UNIXTIME()转时间戳最直接
Unix时间戳是整数，比如1717027200，直接查出来没法读。MySQL原生支持FROM_UNIXTIME()函数，不用额外处理就能转成可读的日期时间格式。
默认输出是YYYY-MM-DD HH:MM:SS格式，例如FROM_UNIXTIME(1717027200)返回2024-05-30 00:00:00。如果字段本身是BIGINT存的时间戳，直接套用就行：
SELECT FROM_UNIXTIME(create_time) AS readable_time FROM logs;
- 如果时间戳单位是毫秒（比如JavaScript生成的），先除以1000：
FROM_UNIXTIME(create_time / 1000) - 时区会影响结果——该函数按MySQL服务器当前时区解释时间戳，不是UTC。查之前确认
SELECT @@time_zone; - 传入
NULL或非法数值（如负数、超大整数）会返回NULL，不报错但容易漏数据
想自定义输出格式？加第二个参数用FROM_UNIXTIME()格式化
FROM_UNIXTIME()支持格式化字符串，类似DATE_FORMAT()的语法，比如只取年月日、加中文单位、去掉秒等。
第二个参数是格式模板，常用有：'%Y-%m-%d'、'%H:%i'、'%Y年%m月%d日'。注意：必须用单引号包裹，且模板里特殊字符要转义（如%不能少）。
SELECT FROM_UNIXTIME(1717027200, '%Y年%m月%d日 %H:%i') AS custom_time;
- 格式符大小写敏感：
%y是两位年份，%Y是四位；%i是分钟，%I是12小时制小时 - 如果传入的格式字符串非法（如
'%X'这种不存在的符），函数静默返回NULL，不会提示错误 - 格式化只影响显示，不改变底层值——它仍是字符串类型，不能直接参与日期计算
遇到0000-00-00 00:00:00？检查时间戳是否在合法范围内
MySQL能表示的日期范围是1000-01-01到9999-12-31，对应Unix时间戳约-62135596800到253402300799。超出这个范围就会变成零值或NULL。
常见踩坑点：用INT类型存时间戳（最大值2147483647 → 对应2038-01-19），一旦超过就溢出，导致FROM_UNIXTIME()返回0000-00-00 00:00:00。
- 查一下字段类型：
DESCRIBE table_name;，确认时间戳列是BIGINT而非INT - 验证数据：
SELECT create_time, FROM_UNIXTIME(create_time) FROM table WHERE create_time > 2147483647;，看是否已出现零值 - 已有坏数据？可以用
WHERE create_time BETWEEN -62135596800 AND 253402300799做过滤
需要把标准时间再转回时间戳？用UNIX_TIMESTAMP()反向操作
和FROM_UNIXTIME()配对的是UNIX_TIMESTAMP()。它能把DATETIME或DATE转回整数时间戳，方便存储或跨系统对接。
注意：传入NULL返回NULL；传入无效日期（如'2024-02-30'）也返回NULL，不会报错。
SELECT UNIX_TIMESTAMP('2024-05-30 00:00:00'); -- 返回 1717027200- 不带参数时，
UNIX_TIMESTAMP()返回当前时间戳（秒级），等价于NOW()转秒 - 传入
DATE类型（无时间部分）会按当天00:00:00计算，比如UNIX_TIMESTAMP('2024-05-30')=1717027200 - 时区依然关键：该函数把输入时间当作服务器本地时区处理，不是UTC。如果数据按UTC存，得先
CONVERT_TZ()校正
时区和数据类型这两块最容易被跳过，一出问题就难定位。特别是毫秒时间戳和INT溢出，线上查半天才发现是类型不对。
