DATE_FORMAT结果为空通常因输入值非法（NULL、非日期字符串、0000-00-00等），而非函数错误；NOW()每次调用独立求值，但语句内多次出现值相同，且不随事务冻结。
MySQL 里 DATE_FORMAT 格式化结果为空？先查时区和字段类型
空字符串或 NULL 不是函数写错了，大概率是输入值本身不合法。比如对 NULL 字段、非日期类型的字符串（如 '2024-13-01'）、或者 0000-00-00 这类非法日期调用 DATE_FORMAT，MySQL 默认静默返回 NULL。
实操建议：
- 用
SELECT col, IS_DATE(col), IS_VALID_DATE(col)（MySQL 8.0.29+）或SELECT col, col + INTERVAL 0 DAY检查字段是否真能被识别为日期 - 确保字段类型是
DATETIME、TIMESTAMP或DATE；若存的是字符串（如VARCHAR），先用STR_TO_DATE(col, '%Y-%m-%d')转换再格式化 - 检查会话时区：
SELECT @@time_zone, @@session.time_zone；时区错可能导致NOW()返回值与预期不符，间接影响格式化结果
NOW() 在 INSERT 和 WHERE 中行为不一致？注意求值时机
NOW() 是运行时函数，每次出现在 SQL 语句中都独立求值——但具体“什么时候求”取决于上下文。在单条 INSERT 里多次写 NOW()，值相同；但在 UPDATE ... WHERE created_at > NOW() - INTERVAL 1 HOUR 这种语句里，NOW() 只算一次，不是每行都重算。
常见错误现象：
- 触发器里用
NOW()记录日志时间，却发现多行记录时间差几毫秒——其实是触发器执行批次不同导致的，不是函数问题 - 用
NOW()生成唯一标识（如拼接字符串）失败，因为并发插入时可能撞上同一毫秒级时间 - 在存储过程中反复调用
NOW()做逻辑判断，却没意识到它不随事务时间点冻结，回滚不影响已取的值
用 DATE_FORMAT(NOW(), '%Y%m%d%H%i') 生成文件名？小心跨天边界和时区漂移
这种写法看着干净，但上线后容易在凌晨出问题：比如定时任务在 23:59 启动，NOW() 返回当天时间，但脚本实际运行到写文件时已过 00:00，而格式化结果还是昨天的日期串。
实操建议：
- 固定时间戳比依赖实时
NOW()更可靠：先SET @ts = NOW(); INSERT ... VALUES (DATE_FORMAT(@ts, '%Y%m%d%H%i')); - 如果必须用表达式，且部署在多时区机器上，显式指定时区：
CONVERT_TZ(NOW(), '+00:00', '+08:00')，避免依赖系统默认 -
%i是分钟（00–59），别误写成%I（12小时制小时），否则凌晨会输出202404010001这种看似正常实则含义错乱的字符串
替代方案：为什么有时该用 CURDATE() 或 SYSDATE()？
NOW() 和 SYSDATE() 都返回当前时间，但前者在语句开始时“定格”，后者是函数调用瞬间的时间——在同一条语句里混用，可能得到不同值。而 CURDATE() 只取日期部分，没有时间精度开销，也更安全。
使用场景差异：
- 做日期范围查询（如
WHERE date_col = CURDATE()）比DATE(NOW())少一次函数计算，还能走索引（如果date_col是DATE类型） - 审计日志需要精确到微秒且不受语句延迟影响，用
SYSDATE(6)；但注意它不能被查询缓存，性能略低 - 在复制环境（replica）上，
NOW()的值由主库传过来，保证一致性；SYSDATE()则各算各的，可能导致主从数据逻辑不一致
真正麻烦的不是语法，是当你在凌晨三点看日志发现时间戳全偏了两小时，才想起服务器时区没同步、应用又没设 time_zone 参数。这种事没法靠文档记住，只能在第一次踩坑时记牢。
