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 Skill 1.0.0 (3)
下载
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
- 如果真要按格式分组统计，<code>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' 就是 NULL真正需要格式化时，优先考虑前端或应用层处理——数据库只传原始 DATETIME 值。只有当格式化逻辑必须固化在 SQL（比如报表视图、导出脚本）里，才用 DATE_FORMAT，且务必检查字段类型、NULL 处理和 WHERE 使用场景。
