FROM_UNIXTIME()将UNIX时间戳转为可读日期，默认格式'YYYY-MM-DD HH:MM:SS'；支持自定义格式、时区转换，但WHERE中使用会导致索引失效，应反向用UNIX_TIMESTAMP()转换条件。
MySQL里用 FROM_UNIXTIME() 转时间戳最直接
UNIX时间戳是整数，比如 1717027200，直接查出来没法读。MySQL原生支持转成可读日期，核心就是 FROM_UNIXTIME() 函数。它默认输出 'YYYY-MM-DD HH:MM:SS' 格式，符合大多数场景需求。
常见错误是传入空值或非法数字（如负数、超大数），这时函数返回 NULL，不会报错但结果容易被忽略。
- 基本用法：
SELECT FROM_UNIXTIME(1717027200);→'2024-05-31 00:00:00' - 只取日期部分：
SELECT DATE(FROM_UNIXTIME(1717027200));→'2024-05-31' - 字段转换示例：
SELECT id, FROM_UNIXTIME(created_at) AS created_time FROM logs;
需要自定义格式？用 FROM_UNIXTIME() 的第二个参数
第二个参数是格式化字符串，类似 PHP 的 date()，但语法受限。MySQL 不支持所有格式符，常用且安全的有：%Y（4位年）、%m（补零月）、%d（补零日）、%H（24小时制）、%i（分钟）。
注意：%h 是12小时制，%l（小写L）才是去掉前导零的小时，容易混淆；%s 是秒，不是字符串。
- 年月日中文格式：
FROM_UNIXTIME(1717027200, '%Y年%m月%d日')→'2024年05月31日' - 短日期（无分隔符）：
FROM_UNIXTIME(1717027200, '%Y%m%d')→'20240531' - 错误写法：
FROM_UNIXTIME(1717027200, '%Y-%m-%d %h:%i:%s')→ 小时会错成12进制，且没补零
时区问题常被忽略：FROM_UNIXTIME() 默认用系统时区
UNIX时间戳本身是UTC，但 FROM_UNIXTIME() 输出的是当前MySQL服务器设置的时区时间。如果你查出来的日期比预期早/晚8小时，大概率是时区没对齐。
不建议改全局时区配置，临时处理更稳妥。可以在函数调用前加 CONVERT_TZ()，或者直接在连接层指定时区（如 JDBC 的 serverTimezone=Asia/Shanghai）。
- 查当前时区：
SELECT @@time_zone;（常见返回SYSTEM或具体时区名） - 强制转为东八区：
SELECT CONVERT_TZ(FROM_UNIXTIME(1717027200), '+00:00', '+08:00'); - 如果字段本身存的是本地时间戳（非UTC），那反而不该转——得先确认业务约定
性能和索引：别在 WHERE 里对时间戳字段用 FROM_UNIXTIME()
如果表有百万级数据，又写 WHERE FROM_UNIXTIME(created_at) > '2024-01-01'，MySQL无法走 created_at 字段的索引，会全表扫描。
正确做法是把条件反向转换：把标准时间转回时间戳，再和整数字段比较。
- 慢查询（不走索引）：
WHERE FROM_UNIXTIME(created_at) >= '2024-01-01' - 快查询（走索引）：
WHERE created_at >= UNIX_TIMESTAMP('2024-01-01') -
UNIX_TIMESTAMP()也支持带格式字符串，但注意它默认按服务器时区解析输入日期
