unix_timestamp() 返回bigint类型；不带参数时返回当前时间秒级时间戳，传入非法日期字符串、空字符串或null时返回0或null，且受mysql版本和sql模式影响。
UNIX_TIMESTAMP() 返回什么类型？为什么有时得到0或NULL
UNIX_TIMESTAMP() 默认返回当前时间的秒级整数，但很多人没注意它其实有三种调用方式：不带参数、带 DATETIME 字符串、带 DATE。如果传入格式不对的字符串（比如 '2023-13-01' 或含毫秒的 '2023-01-01 12:00:00.123'），MySQL 会静默转成 0 或 NULL，而不是报错。
常见踩坑点：
- 传入
TIMESTAMP类型字段时，实际是先隐式转成DATETIME再计算，时区会影响结果 - 传入空字符串
''或NULL，直接返回NULL，不是 0 - MySQL 5.6+ 对非法日期更严格，
'2023-02-30'在宽松模式下可能得 0，在严格模式下会报错
把 DATETIME 转成时间戳：别硬拼字符串
想把 created_at 字段转成 Unix 时间戳，直接写 UNIX_TIMESTAMP(created_at) 就行，别用 CONCAT 拼年月日再转——那既慢又容易出错。
真实场景中要注意：
- 字段是
TIMESTAMP类型时，UNIX_TIMESTAMP()返回的是 UTC 时间戳，和服务器时区无关；但DATETIME是“字面值”，会按当前会话时区解释 - 如果业务要求统一用北京时间（UTC+8），而服务器时区是
+00:00，那对DATETIME字段必须显式加偏移：UNIX_TIMESTAMP(DATE_ADD(created_at, INTERVAL 8 HOUR)) - 别在 WHERE 条件里对字段用函数，比如
WHERE UNIX_TIMESTAMP(created_at) > 1717027200，这会让索引失效
从时间戳还原 DATETIME：FROM_UNIXTIME() 的精度陷阱
FROM_UNIXTIME() 默认只支持秒级，传入毫秒时间戳（如 1717027200123）会截断成 1717027200，结果差一整天。要保留毫秒，得手动除以 1000 并用小数点表示：
SELECT FROM_UNIXTIME(1717027200.123); -- 正确：返回 '2024-05-30 00:00:00.123'
还要注意：
- 第二个参数可指定格式，但只影响输出字符串，不影响时区转换逻辑
- 如果传入超大数值（如
9999999999），MySQL 可能返回NULL，因为内部限制在 2147483647（2038年问题） - 在 MySQL 8.0.28+ 中，
FROM_UNIXTIME()支持微秒精度，但需确保输入是带小数的浮点数，不是整数
跨时区写入和查询时，UNIX_TIMESTAMP() 不是你该依赖的函数
如果你的应用部署在多个时区，或者用户来自不同时区，靠 UNIX_TIMESTAMP() 做时间比较或存储，很容易出现“明明时间对得上却查不到数据”的问题。
真正稳妥的做法是：
- 写入前统一转成 UTC 时间（用
CONVERT_TZ(created_at, @@session.time_zone, '+00:00')），再用UNIX_TIMESTAMP() - 查询时也统一用 UTC 时间戳比对，而不是依赖客户端传来的本地时间戳
- 更推荐跳过
UNIX_TIMESTAMP()，直接用TIMESTAMP类型字段存 UTC 时间，读写都走原生类型，省去转换环节
时区相关的转换永远比看起来复杂，尤其是夏令时切换那几天，UNIX_TIMESTAMP() 自带的“隐式时区解释”反而成了最不透明的一环。
