SQL日期函数详解：获取、格式化、计算与性能优化

日期函数这个东西，写SQL查询的时候真的绕不开。不管你是做数据分析、后端开发，还是天天跟报表打交道，几乎每个业务查询里都会碰到“查最近7天订单”“统计本月销售额”“对比去年同期”这类需求。只要涉及到时间维度，就必然会用到日期函数。但很多人对日期函数的态度是“用到哪个查哪个”，没有形成系统认知，结果就是同样的需求，别人一行搞定，你要写半天，甚至写出来的SQL还带着隐式转换的坑，数据量一大直接慢查询。

这篇博文我从实操角度出发，把SQL查询中真正高频的日期函数用法、常见陷阱、跨数据库差异一次性讲透。内容以SQL Server语法为主，同时标注MySQL和Oracle的对应写法，因为工作里这三家数据库太常遇到了。适合正在学SQL的初学者，也适合写了好几年SQL但没系统整理过日期函数的老手。

1. 日期函数的核心价值与分类思路

1.1 为什么日期函数是SQL查询的“隐藏关键点”

很多人在写SQL时对日期函数不以为然，觉得无非就是拿个日期字段跟“今天”比一比。但实际工作中，日期处理往往是最容易出乱子的地方。

举个最常见的例子：业务要查“昨天的订单”，新手可能会写WHERE order_date = '2024-01-15'，但这样的写法存在两个问题——第一，日期写死了，第二天这条SQL就失效；第二，如果order_date是datetime类型，精确到时分秒，那等值判断永远匹配不到数据。正确的思路是用日期函数动态计算：WHERE order_date >= DATEADD(DAY, -1, CAST(GETDATE() AS DATE)) AND order_date < CAST(GETDATE() AS DATE)。

类似这种问题，在面试题里出现频率极高，在实际生产环境里踩坑的概率也极高。所以，日期函数不是“会用就行”，而是要理解它的设计逻辑、边界处理、性能影响。

1.2 主流数据库日期函数体系差异总览

先给一张总览表，后面所有细节都基于这个框架展开。

这张表建议收藏。理解这张表，你就能明白为什么网上很多SQL教程会特别标注“以下语法适用于XXX数据库”——因为日期函数的命名和参数顺序差异实在太大了。

1.3 从业务需求反推函数选型的方法

我在写SQL时有一套固定的思考顺序，分享给大家：

第一步，先明确你要的是“时间点”还是“时间段”。比如“本月销售额”是时间段，“当前时间”是时间点，两者用的函数和写法完全不同。

第二步，明确业务上“日”的边界。是按自然日（0点到24点）算，还是按某个业务时区的起点算，这决定了你要不要对日期做截断处理。

第三步，确认数据库类型和版本。同一个函数在不同版本里可能有行为差异，比如SQL Server的FORMAT函数在2012版本才引入，STRING_AGG在2017版本才有。写代码前先确认版本，可以避免上线时报语法错误。

第四步，写完看一下执行计划。日期函数看起来简单，但写法不当会导致索引失效，这条在后面性能优化部分详细说。

2. 最常用日期函数的实操细节与参数解析

2.1 获取当前日期时间：别再只用GETDATE()

获取当前时间是最基础的操作，但里面的细节值得展开。

SQL Server里GETDATE()返回的是datetime类型，精度到3.33毫秒；SYSDATETIME()返回datetime2类型，精度更高；CURRENT_TIMESTAMP是ANSI标准写法，等价于GETDATE()。如果你只需要日期部分，建议用CAST(GETDATE() AS DATE)或者直接CONVERT(DATE, GETDATE())，这样得到的就是不带时分秒的日期。

MySQL里NOW()返回YYYY-MM-DD HH:MM:SS，CURDATE()只返回日期，CURRENT_DATE是它的别名，CURRENT_TIMESTAMP等价于NOW()。这里有个小差异：MySQL里SYSDATE()虽然看起来和NOW()一样，但它取的是函数执行时刻的时间，而NOW()取的是语句开始执行的时刻。在一个长事务里批量插入数据时，SYSDATE()会导致每条记录的创建时间不同，而NOW()会让所有记录的创建时间相同。

Oracle里直接用SYSDATE（伪列，不需要括号）返回日期和时间，CURRENT_DATE返回当前会话时区的日期，SYSTIMESTAMP返回带时区和微秒的时间戳。如果你的业务涉及跨时区，Oracle的CURRENT_DATE比SYSDATE更安全。

实际工作中我推荐的做法是：查询条件里需要“今天”时，一律写日期字段 >= 今天零点 AND 日期字段 < 明天零点这样的区间，而不是BETWEEN 今天零点 AND 今天23:59:59。原因在后面的边界问题里细说。

2.2 日期格式化与字符串互转：格式化的正确姿势

把日期转成字符串，最常见的是用来做报表展示、文件名拼接、日志输出。但很多人在这一步会踩“区域设置”的坑。

SQL Server里CONVERT(VARCHAR(10), GETDATE(), 120)是经典写法，120对应YYYY-MM-DD HH:MM:SS格式。常用的样式编号还有：101对应MM/DD/YYYY（美国习惯）、102对应YYYY.MM.DD、112对应YYYYMMDD（纯数字紧凑格式）、23对应YYYY-MM-DD。如果你需要中文格式的月份名称，可以用FORMAT(GETDATE(), 'yyyy年MM月dd日')，但FORMAT走的是.NET的CLR，性能比CONVERT差很多，大数据量查询里尽量避免。

MySQL里对应的是DATE_FORMAT(NOW(), '%Y-%m-%d %H:%i:%s')。注意大小写敏感：%Y是四位年份，%y是两位年份；%m是两位月份，%c是一位或两位月份；%d是两位日，%e是一位或两位日。这些很容易混，建议直接记常用格式串。

Oracle里是TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS')，注意Oracle的格式串里MI是分钟，MM是月份，写错的话数据完全不对；HH24代表24小时制，没有它默认是12小时制，下午1点会被显示成01。

反向操作，字符串转日期：

• SQL Server：CAST('2024-01-15' AS DATE)或CONVERT(DATE, '2024-01-15', 23)。只要字符串符合ISO格式YYYY-MM-DD，直接CAST就行，性能也最好。
• MySQL：STR_TO_DATE('2024-01-15', '%Y-%m-%d')。
• Oracle：TO_DATE('2024-01-15', 'YYYY-MM-DD')。

2.3 日期加减与间隔计算：DATEADD的变体与边界

日期加减是日报、周报、月报SQL里最常用的操作。SQL Server的DATEADD语法是DATEADD(datepart, number, date)，三个参数顺序要记牢——是数量在前、日期在后。比如DATEADD(DAY, -7, GETDATE())表示七天前，DATEADD(MONTH, 1, GETDATE())表示一个月后。

为什么我要强调参数顺序？因为MySQL的写法正好相反。MySQL的DATE_ADD(date, INTERVAL 表达式 单位)把日期放前面，间隔放后面：DATE_ADD(NOW(), INTERVAL -7 DAY)。而且MySQL还有一个等价写法DATE_SUB(date, INTERVAL 7 DAY)专门做减法。Oracle更特殊，直接对日期做算术运算：SYSDATE + 1表示加一天，SYSDATE - 7表示减七天，ADD_MONTHS(SYSDATE, 3)表示加三个月。

这里有个非常容易踩的坑：DATEADD(DAY数量)和DATEADD(MONTH数量)在月末的边界行为不同。比如1月31日加一个月，SQL Server得到2月28日（或闰年的29日），MySQL同样如此。但如果你做的是“三个月前的今天”且今天是5月31日，得到的是2月28日，很多业务会觉得不对。更好的办法是明确业务规则——是月末对齐、月末顺延，还是固定按天累加。不同规则对应不同写法，建议在SQL注释里写清楚业务逻辑。

另一个实用技巧：计算年龄、工龄时，推荐用DATEDIFF(YEAR, 出生日期, GETDATE())然后根据是否过了今年的生日再减一。SQL Server的DATEDIFF是按“跨越了多少个边界”来计算的，不是精确的时间差。DATEDIFF(YEAR, '2023-12-31', '2024-01-01')结果是1，虽然只差了一天。

2.4 提取年、月、日、周、季度：拆解日期维度

按时间维度做分组统计，是日期函数最典型的应用。SQL Server里用YEAR(date)、MONTH(date)、DAY(date)最直白，也可以用统一的DATEPART(YEAR, date)、DATEPART(WEEK, date)。DATEPART(WEEK, date)返回的是当前日期在当年的第几周，但要注意SQL Server默认一周从周日开始，这个可以通过SET DATEFIRST改变。

MySQL里除了YEAR()、MONTH()、DAY()外，还常用QUARTER(date)直接返回季度（1到4），WEEK(date)返回周数，WEEKDAY(date)返回周几（0代表周一，6代表周日），DAYOFWEEK(date)返回周几（1代表周日，7代表周六）。两个函数返回数字含义不同，写代码前先确认要的是哪种。

Oracle的提取相对复杂，通常用EXTRACT(YEAR FROM date)提取年份、EXTRACT(MONTH FROM date)提取月份、TO_CHAR(date, 'Q')提取季度，TO_CHAR(date, 'WW')提取周数。

另外提一个很实用的场景：按周几分布统计。SQL Server可以这样写：

sql复制SELECT DATENAME(WEEKDAY, order_date) AS weekday_name, COUNT(*)
FROM orders
GROUP BY DATENAME(WEEKDAY, order_date)
ORDER BY MIN(order_date);

DATENAME返回的是周几的名称文本（比如“星期一”或“Monday”，取决于语言设置），DATEPART返回数字。在实际报表中两者经常配合使用。

3. 日期条件查询与性能优化要点

3.1 日期范围查询的几个典型写法陷阱

我排查过很多慢SQL，发现日期条件部分最容易出问题。最典型的是在索引列上套函数。

比如有一个查询：

sql复制SELECT * FROM orders
WHERE DATE_FORMAT(create_time, '%Y-%m-%d') = '2024-01-15';

这种写法看起来“直观”，但它对create_time这一列做了函数运算，导致索引失效，数据库只能全表扫描。数据量小没感觉，数据量到千万级就卡死。

正确的写法是：

sql复制SELECT * FROM orders
WHERE create_time >= '2024-01-15 00:00:00'
  AND create_time < '2024-01-16 00:00:00';

或者用SQL Server的写法：

sql复制SELECT * FROM orders
WHERE create_time >= '2024-01-15'
  AND create_time < DATEADD(DAY, 1, '2024-01-15');

保持列本身不含函数、不隐式转换，索引才能正常工作。

另一个常见陷阱是BETWEEN AND配合日期时间。BETWEEN '2024-01-01' AND '2024-01-31'在日期类型上没问题，但如果列是datetime类型，2024-01-31会被解释成2024-01-31 00:00:00，那么1月31日当天除了零点以外的数据全部查不到。所以日期时间列的范围查询，请用左闭右开[start, end)区间。

3.2 按日期分组统计的正确打开方式

日报、月报、按小时统计，是日期分组最常见的三种形态。

日报统计：

sql复制SELECT CAST(create_time AS DATE) AS stat_date, COUNT(*)
FROM orders
WHERE create_time >= DATEADD(DAY, -30, CAST(GETDATE() AS DATE))
GROUP BY CAST(create_time AS DATE)
ORDER BY stat_date;

这段SQL里有一个关键点：WHERE里的DATEADD(DAY, -30, CAST(GETDATE() AS DATE))是对常量做计算，不会影响索引；而GROUP BY里的CAST(create_time AS DATE)是在分组时对列做操作，这个场景下没问题，因为分组本身就要全量扫描。但如果你想优化，可以增加一个stat_date冗余列（在插入时提前写入纯日期），然后直接对stat_date分组，性能会好很多。

按月/年统计：

sql复制-- SQL Server
SELECT YEAR(create_time) AS yr, MONTH(create_time) AS mon, COUNT(*)
FROM orders
GROUP BY YEAR(create_time), MONTH(create_time)
ORDER BY yr DESC, mon DESC;

按小时统计（统计一天内每个小时的订单量）：

sql复制-- SQL Server
SELECT DATEPART(HOUR, create_time) AS hour_no, COUNT(*)
FROM orders
WHERE create_time >= CAST(GETDATE() AS DATE)
  AND create_time < DATEADD(DAY, 1, CAST(GETDATE() AS DATE))
GROUP BY DATEPART(HOUR, create_time);

这里补充一个心得：如果业务上经常按小时维度查询，建议在表设计时增加一个hour_no冗余字段（0到23），写入数据时通过程序计算好。这属于空间换时间的典型优化，在报表类系统中非常有效。

3.3 日期条件下索引失效的排查路线

如果你发现加了日期条件的查询反而更慢，按下面的路线排查：

第一步，查看执行计划。SQL Server里按Ctrl + M开启显示执行计划，MySQL用EXPLAIN SELECT...，Oracle用EXPLAIN PLAN FOR。重点关注Scan和Seek，如果是Index Scan（全索引扫描），基本可以断定索引没起到预期作用。

第二步，确认索引列的数据类型和查询条件的类型一致。varchar类型的日期字段和datetime类型的查询条件比较，会导致隐式转换，索引照样失效。这种情况我见过很多，根源往往是表设计阶段把时间字段建成了varchar。

第三步，检查查询条件是否对列做了函数运算、算术运算、LIKE模糊匹配。WHERE DATEADD(DAY, 1, create_time) > GETDATE()这类写法，会让索引失效，改成WHERE create_time > DATEADD(DAY, -1, GETDATE())就好。

第四步，确认查询条件的参数化情况。如果SQL是动态拼接的，且日期条件部分因为格式不同导致每次生成的SQL文本都不同，会破坏查询计划复用，可以理解为“无法命中缓存”，要改写为统一的参数化查询。

4. 常见问题排查与避坑经验

4.1 隐式转换：日期函数最常见的翻车现场

隐式转换是SQL里最隐蔽的坑。举个例子，一个表里的create_date字段是varchar(10)，存的是'2024-01-15'这样的字符串，然后查询条件写WHERE create_date >= '2024-01-01'。表面上看没问题，但如果排序规则是二进制排序，字符串比较是按字符ASCII码来，结果可能和日期顺序不一致，比如'2024-02-01'小于'2024-01-31'的ASCII码顺序？实际不是，但'2024-1-5'会排在'2024-1-15'后面，这个就非常容易出问题。

更好的做法是把这类字段彻底改为DATE/DATETIME类型，或者在查询时显式转换：WHERE CONVERT(DATE, create_date) >= '2024-01-01'。但要记住，使用CONVERT包裹列会导致索引失效，所以根本上还是要把表结构修正。

还有一类隐式转换坑在于“默认值”。SQL Server里CAST('' AS DATETIME)会报错，但CAST(NULL AS DATETIME)没问题；MySQL里空字符串转日期会变成0000-00-00，再参与运算就得出荒谬结果。处理历史数据时，一定要先做空值清洗，再进入日期计算。

4.2 日期边界：BETWEEN AND的闭区间与半开区间

前面提到过，日期时间字段的BETWEEN AND是闭区间，包含两端。问题是，你能接受包含2024-01-31 00:00:00，但绝对不想只包含这一秒，却漏掉后面23小时59分59秒的数据。

严谨的写法是半开区间：

sql复制WHERE create_time >= '2024-01-01 00:00:00'
  AND create_time < '2024-02-01 00:00:00';

如果是按天查询，SQL Server可以更优雅：

sql复制WHERE create_time >= '2024-01-01'
  AND create_time < DATEADD(DAY, 1, '2024-01-01');

这里有个小技巧：SQL Server里字符串'2024-01-01'与datetime比较时，会自动转换为当天的零点。所以create_time < DATEADD(DAY, 1, '2024-01-01')实际上限是1月2日零点，包含了1月1日全天。

MySQL的写法类似：

sql复制WHERE create_time >= '2024-01-01'
  AND create_time < DATE_ADD('2024-01-01', INTERVAL 1 DAY);

4.3 季度和周跨年场景的统计陷阱

季度统计看着简单，但跨年时容易出错。如果你想统计“本财年Q1”（假设财年从4月开始），直接QUARTER()是不行的，需要做偏移处理：

sql复制-- SQL Server: 财年Q1 = 4-6月
SELECT CASE
    WHEN MONTH(order_date) BETWEEN 4 AND 6 THEN 'Q1'
    WHEN MONTH(order_date) BETWEEN 7 AND 9 THEN 'Q2'
    WHEN MONTH(order_date) BETWEEN 10 AND 12 THEN 'Q3'
    ELSE 'Q4'
END AS fiscal_quarter, COUNT(*)
FROM orders
GROUP BY CASE
    WHEN MONTH(order_date) BETWEEN 4 AND 6 THEN 'Q1'
    WHEN MONTH(order_date) BETWEEN 7 AND 9 THEN 'Q2'
    WHEN MONTH(order_date) BETWEEN 10 AND 12 THEN 'Q3'
    ELSE 'Q4'
END;

周统计的跨年陷阱更常见。大部分数据库的周编号规则不统一：SQL Server默认周日是一周的第一天，MySQL默认周日是一周的第一天但实际上WEEK()函数有多种模式，Oracle的IW是按ISO标准（周一是第一天）。如果你在SQL Server里用DATEPART(WEEK, '2025-01-01')得到的结果，可能和业务日历上的周数对不上。解决方案是：统一使用ISO周数，或者在SQL注释里明确写明计算规则，前后端保持一致。

4.4 常见问题速查表

4.5 几句真心建议

最后分享一点个人经验。日期函数并不难，难的是在复杂业务里保持一致的日期处理约定。我见过一个项目里，有人用字符串比较日期，有人用SUBSTRING截取年月日，还有人直接在应用层算好再传参——每种写法都能跑，但混在一起维护成本极高，后来出了问题只能靠人肉review。

我的建议是，团队里定一套日期处理规范：统一用数据库原生的日期类型、统一使用左闭右开区间、统一规定“天”的边界、统一函数风格。把这个规范写进Code Review清单，能减少至少一半的日期类Bug。另外，面试时经常考日期函数，本质上考的是候选人对边界情况和索引优化的理解，而不只是背语法——这也是我想通过这篇文章传递的核心：日期函数的真正价值，在于你能用它对业务时间维度做准确、高效、可靠的刻画。