date_format是mysql特有函数，用于将日期格式化为字符串，需注意格式符大小写区分、中文字符集支持及where中使用会导致索引失效。
DATE_FORMAT函数的基本用法和常见格式符
DATE_FORMAT 是 MySQL 特有的函数，不能直接在 PostgreSQL、SQL Server 或 SQLite 中使用。它接收两个参数：一个日期值（DATE、DATETIME 或 TIMESTAMP 类型），以及一个格式字符串。格式符以 % 开头，比如 %Y 表示 4 位年份，%m 表示补零的月份（01–12），%d 表示补零的日期（01–31）。
常见组合示例：
SELECT DATE_FORMAT(NOW(), '%Y-%m-%d'); -- 输出：2024-06-15 SELECT DATE_FORMAT(NOW(), '%Y年%m月%d日'); -- 输出：2024年06月15日 SELECT DATE_FORMAT(NOW(), '%H:%i:%s'); -- 输出：14:23:05（注意是 %H，不是 %h）
容易踩的坑：
-
%h表示 12 小时制小时（01–12），%H才是 24 小时制（00–23），混淆会导致时间显示异常 - 中文字符（如“年”“月”“日”）可直接写在格式串中，但需确保数据库连接字符集支持（如
utf8mb4），否则可能变成乱码 -
DATE_FORMAT返回的是字符串类型，不能参与日期运算；若后续还要做日期比较，别忘了保留原始字段
DATE_FORMAT在WHERE条件中使用的风险
很多人试图用 DATE_FORMAT 在 WHERE 子句里过滤日期，比如：
WHERE DATE_FORMAT(create_time, '%Y-%m') = '2024-06'
这会导致索引失效——因为对字段施加函数后，MySQL 无法利用 create_time 上的索引。性能会随数据量增长急剧下降。
正确做法是用范围查询替代：
WHERE create_time >= '2024-06-01' AND create_time <p>这样能走索引，且语义更精确（包含毫秒、时区等细节）。只有在明确需要字符串匹配（比如导出报表标题）时，才应在 <code>SELECT</code> 或 <code>ORDER BY</code> 中用 <code>DATE_FORMAT</code>。</p><h3>替代方案：跨数据库的日期格式化思路</h3><p>如果你写的 SQL 要兼容多种数据库，<code>DATE_FORMAT</code> 就不可靠。PostgreSQL 用 <code>TO_CHAR()</code>，SQL Server 用 <code>FORMAT()</code> 或 <code>CONVERT()</code>，SQLite 用 <code>strftime()</code>。</p><p>例如同一种“YYYY-MM-DD”格式：</p>
- MySQL：
DATE_FORMAT(col, '%Y-%m-%d') - PostgreSQL：
TO_CHAR(col, 'YYYY-MM-DD') - SQL Server：
FORMAT(col, 'yyyy-MM-dd')（SQL Server 2012+）或CONVERT(VARCHAR, col, 23) - SQLite：
strftime('%Y-%m-%d', col)
关键点：各系统格式符大小写、占位符写法、默认行为都不同。比如 PostgreSQL 的 YYYY 是大写，MySQL 的 %Y 是小写加百分号；SQLite 的 %Y 和 MySQL 一致，但不支持中文文字拼接。
时区与函数结果的关系
DATE_FORMAT 本身不处理时区转换，它只是格式化传入的 datetime 值。如果字段是 TIMESTAMP 类型，MySQL 会自动按系统时区或会话时区转成本地时间再格式化；如果是 DATETIME，则原样格式化，不作任何时区调整。
验证当前会话时区：
SELECT @@time_zone;
临时切换（仅当前会话）：
SET time_zone = '+08:00';
所以，当你发现 DATE_FORMAT(NOW(), '%H:%i') 显示的时间和服务器时间不一致，先查 @@time_zone，而不是怀疑函数写错了。很多线上环境默认是 UTC，但业务期望展示东八区时间，这时得配合 CONVERT_TZ() 使用：
DATE_FORMAT(CONVERT_TZ(NOW(), '+00:00', '+08:00'), '%Y-%m-%d %H:%i')
这个链式调用容易漏掉时区转换环节，尤其在跨地域部署或容器化环境中，NOW() 的含义其实依赖于 MySQL 配置，不是绝对可靠的“当前北京时间”。
