MySQL中秒级时间戳（10位）必须用FROM_UNIXTIME()转换，它默认返回'Y-m-d H:i:s'格式DATETIME值；传入毫秒级（13位）会导致错误日期；结果受time_zone影响，需注意时区设置与NULL容错处理。
MySQL里用FROM_UNIXTIME()直接转秒级时间戳
秒级时间戳（10位整数）在MySQL中不能直接用STR_TO_DATE()或DATE()处理，必须用FROM_UNIXTIME()——这是唯一原生支持 Unix 时间戳转日期的函数。它默认返回'Y-m-d H:i:s'格式的DATETIME值，无需额外拼接。
常见错误是传入毫秒级时间戳（13位），结果会变成公元3985年左右的日期，因为MySQL把前10位当秒、后3位当微秒（实际不生效但数值已错）。确认输入是10位整数：比如1717027200对应2024-05-30 00:00:00，而不是1717027200000。
- 基础用法：
SELECT FROM_UNIXTIME(1717027200);→'2024-05-30 00:00:00' - 指定格式：
SELECT FROM_UNIXTIME(1717027200, '%Y年%m月%d日 %H:%i'); - 配合字段使用：
SELECT FROM_UNIXTIME(create_time) AS dt FROM logs;（假设create_time是INT类型秒级时间戳）
自定义函数封装时注意参数类型和时区
如果频繁调用，可以建一个简单函数避免重复写FROM_UNIXTIME()，但别过度封装。MySQL函数不支持默认参数，所以必须显式传入时间戳；同时要注意：函数体内不自动继承会话时区，FROM_UNIXTIME()结果受time_zone系统变量影响。
例如服务器设为+00:00，但业务在中国，直接调用会比本地时间晚8小时。要么在函数里加CONVERT_TZ()，要么统一在应用层或会话层设置SET time_zone = '+08:00';。
- 安全的函数定义：
DELIMITER $$<br>CREATE FUNCTION ts2dt(ts BIGINT) RETURNS DATETIME<br> READS SQL DATA<br> DETERMINISTIC<br>BEGIN<br> RETURN FROM_UNIXTIME(ts);<br>END$$<br>DELIMITER ;
- 调用：
SELECT ts2dt(1717027200); - 不推荐在函数里硬编码时区转换，因为
CONVERT_TZ(FROM_UNIXTIME(ts), '+00:00', '+08:00')性能略差，且依赖时区表是否加载
遇到NULL或非法值时的容错处理
FROM_UNIXTIME()对无效输入（如NULL、负数、超范围值如0或大于2147483647）一律返回NULL，不会报错。这在聚合或JOIN中容易引发静默数据丢失。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
若字段可能为空或异常，建议用IF()或CASE兜底，而不是依赖函数自身行为。尤其注意：MySQL 5.7+ 对0时间戳（即1970-01-01 00:00:00）默认允许，但开启NO_ZERO_DATE模式后会变NULL。
- 基础容错：
SELECT IF(create_time > 0 AND create_time - 更严格判断（排除常见埋点错误值）：
FROM_UNIXTIME(IF(create_time BETWEEN 1000000000 AND 2500000000, create_time, NULL)) - 注意：
UNIX_TIMESTAMP(NOW())返回的是当前秒级时间戳，可用于校验逻辑是否正常
性能和索引注意事项
在WHERE子句里对时间戳字段用FROM_UNIXTIME()会导致全表扫描，因为无法走索引。正确做法是把标准时间条件转成时间戳再比较。
比如想查“2024-05-30当天的数据”，不要写WHERE FROM_UNIXTIME(create_time) >= '2024-05-30' AND FROM_UNIXTIME(create_time) ，而应反向计算：
- 用
UNIX_TIMESTAMP('2024-05-30')得1717027200，UNIX_TIMESTAMP('2024-05-31')得1717113600 - 写成：
WHERE create_time >= 1717027200 AND create_time - 如果字段是
INT类型且有索引，这样能命中索引；若字段是VARCHAR存的时间戳，先转类型再建函数索引（MySQL 8.0+支持）或改存储结构
真正麻烦的是跨时区批量转换——比如导出报表时要按用户本地时区展示，这时候别在SQL里硬算，优先考虑应用层处理，或者用临时表预计算好带时区的字段。
