mysql中无dateformat和unixtimestamp函数，正确为date_format()和unix_timestamp()；date_format()将日期转字符串，需两参数且格式符以%开头，where中使用会导致全表扫描。
MySQL 里没有 DateFormat 函数，也没有 UnixTimestamp 这个函数名 —— 正确的函数是 DATE_FORMAT() 和 UNIX_TIMESTAMP()。混淆这两个名字会导致语法错误或查不到结果。
DATE_FORMAT() 的正确用法和常见陷阱
DATE_FORMAT() 是 MySQL 唯一用于将日期转为字符串格式的内置函数，它不改变字段类型，只影响 SELECT 输出结果。
- 必须传两个参数：
DATE_FORMAT(date, format)，date必须是合法的 DATE/DATETIME/TIMESTAMP 值，否则返回NULL - 格式符必须以
%开头，比如%Y（4位年）、%m（01–12）、%d（01–31），%i是分钟（不是%m），%s是秒（不是%S，两者等价但习惯用小写） - 在
WHERE子句中对日期字段套DATE_FORMAT()会强制全表扫描，例如WHERE DATE_FORMAT(create_time, '%Y-%m') = '2026-04'—— 应改用范围查询：WHERE create_time >= '2026-04-01' AND create_time - 如果字段本身是字符串（如
VARCHAR存的'20260412'），先用STR_TO_DATE()转成日期再格式化，否则DATE_FORMAT()直接返回NULL
UNIX_TIMESTAMP() 和 FROM_UNIXTIME() 的配对逻辑
UNIX_TIMESTAMP() 返回整数时间戳（单位：秒），FROM_UNIXTIME() 把它转回可读日期；二者必须配合使用，不能混用毫秒时间戳。
-
UNIX_TIMESTAMP(NOW())和UNIX_TIMESTAMP()效果一样，都返回当前秒级时间戳（如1744450680） -
FROM_UNIXTIME(1744450680)默认输出'2026-04-12 12:18:00'；加第二个参数可自定义格式：FROM_UNIXTIME(1744450680, '%Y年%m月%d日') - 13位毫秒时间戳（如
1744450680123）必须先除以 1000：FROM_UNIXTIME(1744450680123 / 1000)，否则结果错乱甚至溢出 -
UNIX_TIMESTAMP('2026-04-12')会把日期转为当天 00:00:00 对应的时间戳；但传入非法格式字符串（如'2026/04/12'）可能静默失败，建议统一用'YYYY-MM-DD'格式
WHERE 条件中格式化日期的性能雷区
很多人想按“年月”筛选数据，直接写 DATE_FORMAT(create_time, '%Y-%m') = '2026-04'，这会让索引失效。
- 正确做法是用日期范围：
create_time >= '2026-04-01' AND create_time ，这样能走 <code>create_time字段上的索引 - 如果字段是
TIMESTAMP类型且带时区，注意 MySQL 服务端时区设置（SELECT @@time_zone），否则NOW()和存储值可能跨天 - 对
NULL值做DATE_FORMAT()或UNIX_TIMESTAMP()都返回NULL，需要显式判断：WHERE create_time IS NOT NULL AND ... - 若必须按格式分组（如统计每月订单数），
GROUP BY DATE_FORMAT(create_time, '%Y-%m')是可接受的，但大数据量下仍建议在应用层预处理或加冗余字段
真正容易被忽略的是：MySQL 的日期函数行为高度依赖系统时区和 SQL 模式。哪怕只是换了一台服务器部署，UNIX_TIMESTAMP() 的结果也可能差 8 小时——上线前务必用 SELECT NOW(), UNIX_TIMESTAMP(NOW()), @@time_zone 对照验证。
