DATE_FORMAT()需传入合法日期类型，否则静默返回NULL；应先用STR_TO_DATE()显式转换，避免隐式转换失败；返回字符串无法用于高效排序或分组，且不支持中文月份/星期，跨时区或动态时间需交由应用层处理。
DATE_FORMAT() 函数怎么写才不报错
MySQL 的 DATE_FORMAT() 不是万能日期转换器，它只接受合法的日期类型（DATE、DATETIME、TIMESTAMP）作为第一个参数。传入字符串或 NULL 会静默返回 NULL，而不是报错——这最容易让人误以为“格式对了”，其实根本没生效。
常见错误现象：SELECT DATE_FORMAT('2023-10-01', '%Y年%m月%d日'); 看似能跑，但实际依赖隐式转换；一旦字段值含非法格式（如 '2023/10/01' 或空格），结果就是 NULL，且毫无提示。
- 务必先用
STR_TO_DATE()显式转成日期类型再格式化，比如：DATE_FORMAT(STR_TO_DATE('2023-10-01', '%Y-%m-%d'), '%Y年%m月%d日') - 对字段操作时，先检查类型：
SELECT COLUMN_NAME, DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'your_table' AND COLUMN_NAME = 'date_col'; - 避免在 WHERE 条件里用
DATE_FORMAT()做筛选——它无法走索引，性能极差
常用格式符和中文显示要注意什么
MySQL 默认不支持中文月份/星期名，%M 和 %W 输出的是英文（如 January、Sunday）。想显示“一月”“星期三”，不能靠改格式符，得手动映射或拼接。
使用场景：后台导出报表、前端展示需要本地化日期字符串时。
-
%Y是 4 位年份，%y是 2 位（2023 →23），别混用 -
%m是补零月份数字（01），%c是不补零（1），后者在某些 PHP/Java 后端解析时更安全 - 要显示“2023年10月01日”，必须写
'%Y年%c月%e日'（注意：%e是不补零日，对应%c；若坚持用%d，就得接受01）
DATE_FORMAT() 在 ORDER BY 或 GROUP BY 中为什么失效
因为 DATE_FORMAT() 返回的是字符串，不是日期。按字符串排序，“2023-10-01” 会排在 “2023-09-30” 前面（字典序比较），逻辑完全错乱。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
性能影响：在 GROUP BY DATE_FORMAT(created_at, '%Y-%m') 这类写法中，MySQL 无法利用 created_at 字段上的索引，每次都要全表计算格式化结果。
- 排序/分组必须用原始日期字段：
ORDER BY created_at或GROUP BY YEAR(created_at), MONTH(created_at) - 如果真要按“年月”分组又想显示“2023-10”，用子查询或生成列（MySQL 5.7+）先算好日期维度，再格式化展示
- 临时方案：用
LEFT(created_at, 7)取前 7 位（假设是DATETIME类型且格式统一），比DATE_FORMAT()快得多，但可读性差
替代方案：什么时候该放弃 DATE_FORMAT()
当需求超出纯格式化（比如带时区转换、相对时间计算、多语言支持），硬撑 DATE_FORMAT() 会越来越难维护。
容易被忽略的点：MySQL 8.0+ 支持 CONVERT_TZ() 和窗口函数，但 DATE_FORMAT() 本身不感知时区——它只是按当前会话时区解释输入值，再按固定规则转字符串。
- 跨时区显示？先用
CONVERT_TZ(created_at, '+00:00', '+08:00')转换，再DATE_FORMAT() - 要“3天前”“刚刚”这种动态文本？数据库层不做，交给应用层处理更可控
- 需要 ISO 8601 标准格式（如
2023-10-01T12:34:56+08:00）？DATE_FORMAT()拼不出来，用JSON_OBJECT()+ 字符串拼接或升级到 MySQL 8.0.30+ 的ISO_WEEK相关函数也不够，老实用应用层
真正麻烦的从来不是怎么写对 DATE_FORMAT()，而是没想清楚——这个格式化，到底该在数据库里做，还是留到代码里做。
