date_format函数仅支持datetime/date/timestamp类型，非法输入返回null；需str_to_date转换字符串；格式符大小写敏感；中文需utf8mb4；where中使用会导致索引失效；时区需convert_tz统一；不支持毫秒；推荐date()或cast替代；返回字符串不可直接日期运算。
DATE_FORMAT函数的基本用法和常见错误
DATE_FORMAT 是 MySQL 里格式化日期时间最常用的函数，但它不接受任意字符串，只认 DATETIME、DATE、TIMESTAMP 类型的值。传入 NULL 或非法格式（比如 '2023-13-01'）会直接返回 NULL，不会报错，容易误以为“格式化成功”了。
- 如果字段是字符串类型（如
varchar存的'2023-05-20 14:30:00'），必须先用STR_TO_DATE转成日期类型，再套DATE_FORMAT - 格式符大小写敏感：
%Y是 4 位年份，%y是 2 位；%m是补零月，%c是不补零月（但%c在某些旧版本 MySQL 中不支持） - 中文环境里想输出“年/月/日”，不能直接写
'%Y年%m月%d日'—— MySQL 默认字符集是 latin1 时会乱码，得确保连接、表、字段都设为utf8mb4
SELECT DATE_FORMAT(NOW(), '%Y-%m-%d %H:%i:%s');
WHERE 条件里别直接用 DATE_FORMAT 做筛选
在 WHERE 子句里对字段用 DATE_FORMAT，比如 WHERE DATE_FORMAT(create_time, '%Y-%m') = '2023-05'，会导致索引失效。MySQL 无法利用 create_time 上的索引，只能全表扫描。
- 正确做法是用范围查询：
WHERE create_time >= '2023-05-01' AND create_time - 如果真要按“年月”聚合统计，
GROUP BY DATE_FORMAT(create_time, '%Y-%m')是安全的，它不影响索引使用（前提是GROUP BY字段没被函数包裹在过滤条件里） - 注意时区：如果服务器时区和业务时区不一致（比如服务器是 UTC，业务是 Asia/Shanghai），
NOW()和字段值比较前要统一用CONVERT_TZ
和 PHP/Java 等语言的格式符差异
MySQL 的 DATE_FORMAT 格式符和常见编程语言不兼容，比如：
- PHP 的
date('Y-m-d H:i:s')对应 MySQL 的'%Y-%m-%d %H:%i:%s'，不是'%Y-%m-%d %h:%i:%s'（%h是 12 小时制，带 AM/PM 才有意义） - Java 的
yyyy-MM-dd HH:mm:ss里HH是 24 小时制，对应 MySQL 的%H；但 Java 的mm是分钟，MySQL 的%m是月份 —— 这个最容易写反 - 没有
%f（毫秒）支持，MySQL 5.6+ 的microsecond()可取微秒，但DATE_FORMAT不处理
SELECT DATE_FORMAT('2023-05-20 14:05:30.123', '%Y-%m-%d %H:%i:%s'); -- 结果不带毫秒
替代方案：用 CAST + 表达式更可控
当只需要简单截断（比如只要日期部分），DATE_FORMAT(dt, '%Y-%m-%d') 看似方便，但其实不如 DATE(dt) 或 CAST(dt AS DATE)：
DATE()函数语义清晰、性能更好、不受格式符拼写影响CAST(dt AS CHAR)可转成字符串，但结果依赖系统默认格式（通常是'YYYY-MM-DD'），不如显式格式化可靠如果要兼容 MariaDB 或未来迁移到其他数据库，避免过度依赖
DATE_FORMAT，优先用标准 SQL 的EXTRACT、YEAR()、HOUR()等函数组合DATE_FORMAT返回的是字符串类型，后续不能再直接参与日期运算（比如加一天），得再转回日期类型多层嵌套格式化（比如先格式化再拼接再截取）会让 SQL 难读难调，不如在应用层做最终展示处理
时区、字符集、索引失效这三处，改起来不难，但线上出问题时往往最先被忽略。
