MySQL 的 DATE_FORMAT() 函数怎么写才不报错
初次使用 MySQL 的 DATE_FORMAT() 函数时，开发者常会遇到 FUNCTION DATE_FORMAT does not exist 的错误提示。这通常并非函数缺失，而是参数类型不匹配所致。该函数仅接受 DATE、DATETIME 或 TIMESTAMP 类型的参数，直接传入字符串会导致报错。例如，字符串 '2024-05-10' 若存储在 VARCHAR 字段中，必须先进行类型转换才能格式化。
- 正确操作：
DATE_FORMAT(STR_TO_DATE('2024-05-10', '%Y-%m-%d'), '%Y年%m月%d日') - 常见陷阱：对
NULL值调用函数会直接返回NULL，虽然不报错，但结果可能出乎意料，记得提前用IFNULL()或COALESCE()处理。 - 时区问题：这个函数的输出不带时区信息。如果字段里存的是 UTC 时间，而你却想按本地时间格式化，结果就会出现偏移。稳妥的做法是先用
CONVERT_TZ()调整时区。
常用格式化符号和坑点（%Y %m %d 到底对应什么）
DATE_FORMAT() 的格式符严格区分大小写，部分符号的用法容易混淆。例如，%y 代表两位年份（如 24），而 %Y 表示四位年份（如 2024）；%m 是补零的两位月份（05），%c 则是不补零的月份（5），但需注意 %c 在部分旧版 MySQL 中可能不被支持。
- 星期相关：
%W输出完整的英文星期名（如 'Monday'），%w返回数字表示（默认周一为 1）。需留意WEEK()函数默认周日为 0，若混用可能导致逻辑错位。 - 中文输出：MySQL 原生不支持直接输出中文月份或星期名。格式串中的“年”、“月”、“日”仅为普通字符。若需输出“五月”，需借助
CASE WHEN MONTH(date_col) = 5 THEN '五月'等方式手动转换。 - 24 小时制：
%H表示 00–23 的小时，%h则是 01–12 的小时。注意区分%h:%i %p（输出如 '02:30 PM'）与%H:%i（24小时制）。
在 SELECT 和 WHERE 中用 DATE_FORMAT() 的性能影响
在 WHERE 条件中对日期列使用 DATE_FORMAT() 函数会严重影响查询性能，因为它会使该列上的 B+ 树索引失效，导致全表扫描。例如 WHERE DATE_FORMAT(create_time, '%Y-%m') = '2024-05' 就是典型的低效写法。
- 替代方案：优先使用日期范围查询来替代格式化匹配，例如
WHERE create_time >= '2024-05-01' AND create_time < '2024-06-01'。 - 必须格式化过滤怎么办：若必须按格式化结果过滤（如查询“每周一的数据”），建议创建存储计算列并建立索引：
ALTER TABLE t ADD COLUMN week_day TINYINT AS (WEEKDAY(create_time)) STORED，然后为该列添加索引。 - SELECT 中的使用：在
SELECT列表中进行格式化通常无直接性能损耗。但需注意，若原字段为TIMESTAMP类型且包含微秒，DATE_FORMAT()会将其截断，不保留小数秒。
和 STR_TO_DATE() 配合做解析时的典型错误
DATE_FORMAT() 用于日期格式化输出，STR_TO_DATE() 用于字符串解析为日期，两者常配合使用，但格式符必须严格对应。例如，用 STR_TO_DATE('10/05/2024', '%d/%m/%Y') 解析后，若误用 DATE_FORMAT(..., '%m/%d/%Y') 输出，会导致日期顺序错乱，将 10 月 5 日显示为 '05/10/2024'。
- 验证方法：使用
STR_TO_DATE()解析字符串后，可结合DATE()函数提取日期部分，以验证解析结果是否符合预期。 - 安全写法：建议统一使用标准日期格式作为中间转换桥梁。先将字符串解析为标准
DATE类型，再使用DATE_FORMAT()输出目标格式，可有效避免格式歧义。 - 注意分隔符：格式串中的分隔符（如 /、-、.）必须与原始数据完全一致。例如，
'%Y-%m-%d'无法解析 '2024/05/10'。
实际应用中，最复杂的往往不是语法，而是确保格式串与数据细节的精确对齐——一个多余的空格、缺失的补零或大小写差异都可能导致结果错误。一个实用的建议是：编写完格式串后，立即使用多个边界测试用例（如月初、月末、跨年日期）进行验证，以确保输出完全符合预期。
