DATE_FORMAT是MySQL中唯一能按需定制日期字符串输出的内置函数,语法为DATE_FORMAT(date, format);date须为合法日期类型或可隐式转换的表达式(如NOW()),format为含百分号引导格式符的字符串,错填将返回NULL。

DATE_FORMAT 是 MySQL 中唯一能按需定制日期字符串输出的内置函数,它不修改原始数据,只控制查询结果的显示格式。直接用就行,但错一步就返回 NULL 或结果不符合预期。
DATE_FORMAT(date, format) 的两个参数怎么填
date 必须是合法的日期类型值:DATE、DATETIME、TIMESTAMP 字段,或能被隐式转为日期的表达式(如 NOW()、CURDATE())。传字符串(如 '2024-03-15')MySQL 会尝试转换,但不可靠;传 VARCHAR 存的“日期”大概率失败。
format 是纯字符串,必须用百分号引导格式符,大小写敏感,不能漏引号。常见组合:
-
'%Y-%m-%d'→'2026-11-04' -
'%Y年%c月%e日 %a'→'2026年11月4日 Wed' -
'%H:%i:%s'→'19:03:00'
注意:%M 和 %b 输出英文月份名,依赖系统 locale;中文环境里若字段值本身不是 DATE 类型(比如是 VARCHAR),结果恒为 NULL。
MySQL 数据库管理技能,能够通过自然语言查询和管理数据库,支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
为什么 DATE_FORMAT 返回 NULL 而不是报错
这通常由以下原因导致:
- 输入 date 是 NULL → 函数直接返回 NULL(安全但易被忽略)
- 输入是非法日期(如 '2026-02-30')→ 在严格模式下,MySQL 会在进 DATE_FORMAT 前就报 Incorrect date value;非严格模式下可能转成 '0000-00-00',再格式化仍得 NULL
- format 字符串里混入未转义的 %,比如写成 '%Y%%m'(多了一个 %)→ 解析失败,返回 NULL
- 对 DATE 类型字段用了时间格式符(如 %H)→ 不报错,但返回 '00';反过来,对纯时间字段用 %Y 也会得 '0000'
建议先用 IS NOT NULL 或 COALESCE(created_at, '1970-01-01') 做兜底。
WHERE 条件里千万别套 DATE_FORMAT
这是最常踩的性能坑:
- 真正需要格式化时,优先考虑前端或应用层处理——数据库只传原始 WHERE DATE_FORMAT(create_time, '%Y-%m') = '2026-11' → 强制全表扫描,索引完全失效
- 正确做法是用范围查询:WHERE create_time >= '2026-11-01' AND create_time
- 如果真要按格式分组统计,GROUP BY DATE_FORMAT(create_time, '%Y-%m') 可以用,但要注意:分组键是字符串,'2026-1' 会排在 '2026-10' 前面(字典序),不是时间序
DATE_FORMAT 和 STR_TO_DATE 别搞反方向
DATE_FORMAT 只能从日期 → 字符串;它不能把字符串“解析”成日期。
- 错误:DATE_FORMAT('15/03/2024', '%Y-%m-%d') → 返回 NULL
- 正确:先用 STR_TO_DATE('15/03/2024', '%d/%m/%Y') 得到日期值,再套 DATE_FORMAT(..., '%Y-%m-%d')
- 格式符必须和输入字符串严格一致:'15/03/2024' 对应 '%d/%m/%Y',写成 '%m/%d/%Y' 就是 NULLDATETIME 值。只有当格式化逻辑必须固化在 SQL(比如报表视图、导出脚本)里,才用 DATE_FORMAT,且务必检查字段类型、NULL 处理和 WHERE 使用场景。










