1. 项目概述：为什么你需要一份“最全”的日期时间函数指南

如果你正在用SqlServer处理数据，尤其是那些带有时效性的业务数据，比如订单、日志、用户行为记录，那你一定绕不开日期和时间。我见过太多同事和网友，在处理一个简单的“获取上个月第一天”的需求时，还在用DATEADD和DATEDIFF进行复杂的嵌套计算，或者写一堆CASE WHEN来判断季度。更常见的是，面对DATETIME、DATETIME2、DATE这些类型时一脸茫然，不知道用哪个，或者转换格式时到处搜索“CONVERT函数格式代码”。

这正是我决定整理这份指南的原因。网上的资料要么零散，要么只讲几个常用函数，对于DATEFROMPARTS、EOMONTH这类在特定场景下能极大简化代码的函数提及甚少。这份指南的目标，是成为你手边最全、最实用的SqlServer日期时间函数工具手册。它不仅仅罗列函数，更会结合我十多年踩坑经验，告诉你什么场景下该用什么函数，参数怎么调，以及那些官方文档里不会写的性能陷阱和边界情况。无论你是刚入门的新手，还是需要处理复杂时间逻辑的中高级开发者，这里都有你需要的“干货”。

2. 核心思路：系统化掌握日期时间处理的四层逻辑

面对SqlServer众多的日期时间函数，死记硬背效率极低。我的经验是，将它们按处理逻辑分层理解，构建一个知识体系。这样，遇到问题时，你就能快速定位到该用哪一层的哪个工具。

2.1 第一层：获取与构建日期时间

这是最基础的一层，核心是“无中生有”或“获取当前”。很多查询的第一步就是从这里开始。

1.1.1 获取系统当前时间这是最常用的操作。SqlServer提供了多个函数，细微差别决定了使用场景：

• GETDATE(): 返回当前数据库服务器所在时区的日期和时间，精度到毫秒（3.33毫秒）。这是最常用的函数，适用于绝大多数业务场景，如记录操作时间CREATE_TIME。
• SYSDATETIME(): 返回当前日期和时间，精度更高，达到100纳秒。如果你的业务对时间精度要求极高（如高频交易日志），应该使用它。它的返回类型是DATETIME2(7)。
• GETUTCDATE(): 返回当前的UTC（协调世界时）日期和时间。当你的应用服务全球用户，需要统一时间基准时，务必使用此函数将时间存入数据库，在前端根据用户时区进行转换。这是避免时区混乱的最佳实践。
• CURRENT_TIMESTAMP: 这是ANSI SQL标准语法，功能与GETDATE()完全相同。在需要保证SQL代码跨数据库平台兼容性时，建议使用它。

实操心得：在表结构设计时，对于记录创建时间的字段，我通常使用DATETIME2(3)类型，并默认值绑定SYSDATETIME()。DATETIME2在范围、精度和存储效率上都优于旧的DATETIME类型。(3)表示毫秒精度，对于业务系统足够用。

1.1.2 从部件构造日期当需要组装一个特定日期时（例如，固定每月1号跑批处理），这些函数比字符串拼接安全得多：

• DATEFROMPARTS(year, month, day): 根据指定的年、月、日返回一个DATE类型。参数无效时会直接报错，避免了隐式转换产生无效日期。

  -- 构造2023年国庆节日期 SELECT DATEFROMPARTS(2023, 10, 1) AS NationalDay;

• DATETIME2FROMPARTS(year, month, day, hour, minute, seconds, fractions, precision): 构造DATETIME2类型。fractions是小数秒，precision指定其精度（0-7）。
• DATETIMEFROMPARTS(year, month, day, hour, minute, seconds, milliseconds): 构造DATETIME类型。

使用这些函数，代码意图清晰，且能进行有效的参数校验。

2.2 第二层：提取与分解日期时间

拿到了一个日期时间值，我们常常需要从中抽取出特定的部分，比如年、月、日、星期几。

1.2.1 使用DATEPART函数DATEPART(datepart, date)是这方面的瑞士军刀。datepart参数指定要提取的部分。

DECLARE @MyDate DATETIME2 = ‘2023-11-02 14:30:15.1234567‘; SELECT DATEPART(YEAR, @MyDate) AS TheYear, -- 2023 DATEPART(QUARTER, @MyDate) AS TheQuarter, -- 4 (第四季度) DATEPART(WEEK, @MyDate) AS TheWeek, -- 44 (一年中的第几周，依赖@@DATEFIRST设置) DATEPART(WEEKDAY, @MyDate) AS TheWeekday; -- 5 (星期四，1=周日，7=周六，依赖@@DATEFIRST)

关键点：WEEK和WEEKDAY的返回值受服务器全局变量@@DATEFIRST影响，该变量定义一周的第一天（美国是周日=7，欧洲多是周一=1）。在涉及周的计算时，务必先使用SET DATEFIRST 1（设置周一为第一天）来明确规则，避免跨地域部署时的歧义。

1.2.2 使用YEAR(),MONTH(),DAY()函数这是DATEPART的快捷方式，代码更简洁。

SELECT YEAR(@MyDate), MONTH(@MyDate), DAY(@MyDate);

1.2.3 获取日期名称DATENAME(datepart, date)与DATEPART类似，但返回的是字符串名称（如‘Monday‘, ‘October‘）。

SELECT DATENAME(MONTH, @MyDate) AS MonthName, -- November DATENAME(WEEKDAY, @MyDate) AS WeekdayName; -- Thursday

注意，返回的名称语言取决于数据库的默认语言（LANG）设置。

2.3 第三层：计算与偏移日期时间

业务逻辑中充斥着“三天后”、“上个月同期”、“本财年末”这类需求，这是日期处理的核心。

1.3.1 日期加减：DATEADD函数DATEADD(datepart, number, date)对指定日期部分进行加减。

-- 基础加减 SELECT DATEADD(DAY, 7, @MyDate) AS NextWeek, -- 加7天 DATEADD(MONTH, -1, @MyDate) AS LastMonth; -- 减1个月 -- 复杂场景：获取上个月的同一天（处理月末边界） DECLARE @TestDate DATE = ‘2023-03-31‘; -- 直接减1个月会得到2023-02-31，无效日期，SqlServer会返回2023-02-28 SELECT DATEADD(MONTH, -1, @TestDate); -- 结果：2023-02-28

踩坑记录：DATEADD在处理MONTH、YEAR等部分时，如果结果日期无效（如2月30日），SqlServer会自动将其转换为该月的最后一天。这有时是便利，有时是陷阱。例如，从1月31日加1个月得到2月28日，这可能不符合“下个月最后一天”的业务预期，需要仔细甄别。

1.3.2 日期差值：DATEDIFF函数DATEDIFF(datepart, startdate, enddate)计算两个日期之间指定部分的差值。

SELECT DATEDIFF(DAY, ‘2023-10-01‘, ‘2023-10-31‘) AS DayDiff; -- 30 SELECT DATEDIFF(MONTH, ‘2023-01-31‘, ‘2023-02-01‘) AS MonthDiff; -- 1 (只看月份部分)

重要提示：DATEDIFF计算的是跨越的“边界”数。计算年龄时，直接用DATEDIFF(YEAR, BirthDate, GETDATE())是不准确的，因为它只关心年份数字的变化。一个生日是2000-12-31的人，在2001-01-01那天，用此函数算出的年龄是1岁，但实际上他只过了1天。正确的年龄计算需要结合DATEADD进行判断。

2.4 第四层：格式化与高级转换

这一层关乎数据的展示、交互与系统集成。

1.4.1 格式化输出：CONVERT与FORMAT

• CONVERT(data_type, date, style): 传统且高效的格式化方法。style参数是数字代码。

  SELECT CONVERT(VARCHAR, GETDATE(), 23) AS ISO_Date; -- ‘2023-11-02‘ (YYYY-MM-DD) SELECT CONVERT(VARCHAR, GETDATE(), 120) AS ODBC_Canonical; -- ‘2023-11-02 14:30:15‘ (YYYY-MM-DD HH:MI:SS)

  它的性能优于FORMAT，但样式代码需要记忆（120、23等是常用且好记的）。

• FORMAT(value, format [, culture]): .NET风格格式化，功能强大，可读性好，但性能开销较大。

  SELECT FORMAT(GETDATE(), ‘yyyy年MM月dd日‘) AS ChineseDate; -- ‘2023年11月02日‘ SELECT FORMAT(GETDATE(), ‘dddd, MMMM dd, yyyy‘, ‘en-US‘) AS US_LongDate; -- ‘Thursday, November 02, 2023‘

  性能警告：FORMAT函数虽然方便，但其内部调用CLR，在需要处理大数据集（如百万行报表）时，会成为严重的性能瓶颈。在SELECT列表中对大表字段使用FORMAT是常见的性能反模式。最佳实践是在数据库层用CONVERT处理成标准格式，或在应用层进行格式化。

1.4.2 获取月份的第一天和最后一天这是报表查询中的高频需求。

• EOMONTH(start_date [, month_to_add]): 返回指定日期所在月份的最后一天。可选参数可以偏移月份。

  SELECT EOMONTH(GETDATE()) AS LastDayOfThisMonth, -- 本月最后一天 EOMONTH(GETDATE(), -1) AS LastDayOfLastMonth; -- 上个月最后一天

• 获取月份第一天：通常通过计算上个月最后一天加1天，或使用DATEFROMPARTS。

  -- 方法1：利用EOMONTH SELECT DATEADD(DAY, 1, EOMONTH(GETDATE(), -1)) AS FirstDayOfThisMonth; -- 方法2：直接构造（推荐，意图更清晰） SELECT DATEFROMPARTS(YEAR(GETDATE()), MONTH(GETDATE()), 1) AS FirstDayOfThisMonth;

3. 实战进阶：应对复杂业务场景的日期处理方案

掌握了基础函数，我们来看如何组合它们解决实际问题。这些方案都是我多年积累下来的“套路”，可以直接套用。

3.1 场景一：计算精确年龄

如前所述，简单的DATEDIFF计算年龄不精确。标准算法是：如果今年的生日还没过，则年龄减1。

DECLARE @BirthDate DATE = ‘1990-08-15‘; DECLARE @CurrentDate DATE = ‘2023-11-02‘; SELECT DATEDIFF(YEAR, @BirthDate, @CurrentDate) - CASE WHEN DATEADD(YEAR, DATEDIFF(YEAR, @BirthDate, @CurrentDate), @BirthDate) > @CurrentDate THEN 1 ELSE 0 END AS AccurateAge;

逻辑拆解：先算出年份差，然后判断“今年生日那天”的日期是否已经过去。DATEADD(YEAR, DATEDIFF(YEAR, @BirthDate, @CurrentDate), @BirthDate)这个表达式计算出“今年生日”的日期，如果它大于当前日期，说明生日还没过，年龄需要减1。

3.2 场景二：生成日期维度表

在数据仓库和BI分析中，一个独立的日期维度表至关重要。以下脚本可以快速生成若干年的日期数据。

DECLARE @StartDate DATE = ‘2020-01-01‘; DECLARE @EndDate DATE = ‘2025-12-31‘; WITH DateCTE AS ( SELECT @StartDate AS TheDate UNION ALL SELECT DATEADD(DAY, 1, TheDate) FROM DateCTE WHERE DATEADD(DAY, 1, TheDate) <= @EndDate ) INSERT INTO DimDate (DateKey, FullDate, Year, Quarter, Month, Day, DayOfWeek, ...) SELECT CONVERT(INT, FORMAT(TheDate, ‘yyyyMMdd‘)), -- 代理键，如20231102 TheDate AS FullDate, YEAR(TheDate) AS Year, DATEPART(QUARTER, TheDate) AS Quarter, MONTH(TheDate) AS Month, DAY(TheDate) AS Day, DATEPART(WEEKDAY, TheDate) AS DayOfWeek, ... -- 可以继续添加财年、周数、节假日标志等 FROM DateCTE OPTION (MAXRECURSION 0); -- 解除递归次数限制

这个查询使用了递归公共表表达式（CTE）来生成连续的日期序列，是填充时间维度表的经典方法。

3.3 场景三：基于时间段的统计查询（如查询本月数据）

这是最常见的查询模式。关键是要避免对日期字段使用函数包装，这会导致索引失效。

-- 低效写法（索引失效）： SELECT * FROM Orders WHERE YEAR(OrderDate) = 2023 AND MONTH(OrderDate) = 11; -- 高效写法（利用索引范围扫描）： DECLARE @FirstDayOfMonth DATE = DATEFROMPARTS(2023, 11, 1); DECLARE @FirstDayOfNextMonth DATE = DATEADD(MONTH, 1, @FirstDayOfMonth); SELECT * FROM Orders WHERE OrderDate >= @FirstDayOfMonth AND OrderDate < @FirstDayOfNextMonth; -- 注意是‘<‘，不包含下个月第一天

核心技巧：始终使用>=和<来构造一个左闭右开的区间[Start, End)。这样既能包含开始时间点，又能清晰、无遗漏地排除结束时间点，并且完美利用索引。

3.4 场景四：处理工作日计算（排除周末）

SqlServer没有内置的工作日函数，需要自己实现逻辑。一个简单的版本是计算总天数减去中间的周末天数。

CREATE FUNCTION dbo.GetWorkDays (@StartDate DATE, @EndDate DATE) RETURNS INT AS BEGIN DECLARE @TotalDays INT = DATEDIFF(DAY, @StartDate, @EndDate) + 1; DECLARE @WeekendDays INT = (DATEDIFF(WEEK, @StartDate, @EndDate) * 2) -- 完整的周数*2 + CASE WHEN DATEPART(WEEKDAY, @StartDate) = 1 THEN 1 ELSE 0 END -- 起始日是周日 + CASE WHEN DATEPART(WEEKDAY, @EndDate) = 7 THEN 1 ELSE 0 END; -- 结束日是周六 -- 更精确的计算需要考虑起始日和结束日自身是否周末，此处为简化逻辑 RETURN @TotalDays - @WeekendDays; END;

注意事项：这个函数是一个简化模型，未考虑法定节假日。在实际生产环境中，工作日计算通常需要关联一个节假日日历表。

4. 性能调优与避坑指南

日期时间函数用不好，很容易成为性能杀手。下面是一些关键的优化点和常见陷阱。

4.1 索引失效的罪魁祸首：在WHERE子句中对字段使用函数

这是最经典的性能问题。当你写WHERE YEAR(OrderDate) = 2023时，SqlServer无法使用OrderDate上的索引，因为它必须对每一行数据都计算YEAR()函数，导致全表扫描。正确做法：如场景三所示，将计算转移到条件值上，保持字段“干净”。

-- 好：SARGable（可搜索参数），能用索引 WHERE OrderDate >= ‘2023-01-01‘ AND OrderDate < ‘2024-01-01‘ -- 坏：非SARGable，全表扫描 WHERE YEAR(OrderDate) = 2023

4.2 数据类型的选择：DATETIME2vsDATETIME

在新项目和系统改造中，应优先选择DATETIME2。

对于只需要日期的字段，使用DATE类型（3字节），而不是DATETIME或DATETIME2，存储和比较效率都更高。

4.3 时区处理的最佳实践

对于全球化应用，必须在设计之初就统一时区策略。

1. 存储时区：在数据库层，使用GETUTCDATE()或SYSUTCDATETIME()来获取和存储时间。所有时间戳字段统一存储为UTC时间。
2. 业务逻辑：在业务逻辑层或数据库查询中，所有时间比较、计算都基于UTC时间进行。
3. 展示时区：在应用层或报表层，根据最终用户的时区设置，将UTC时间转换为本地时间进行展示。可以使用AT TIME ZONE（SQL Server 2016+）进行转换。

   -- 将UTC时间转换为东部标准时间 SELECT UTC_Time AT TIME ZONE ‘UTC‘ AT TIME ZONE ‘Eastern Standard Time‘ AS EST_Time FROM MyTable;

   绝对避免在数据库存储本地时间，否则夏令时切换、跨国查询将是噩梦。

4.4 隐式转换与格式陷阱

SqlServer会尝试进行隐式类型转换，但这常常是性能问题和错误结果的源头。

-- 假设@DateVar是VARCHAR类型，值为‘20231102‘ WHERE OrderDate = @DateVar; -- 发生隐式转换，OrderDate索引可能失效 WHERE OrderDate = CONVERT(DATE, @DateVar, 112); -- 显式转换，格式112对应yyyymmdd

黄金法则：确保比较运算符两边的数据类型一致。在将字符串转换为日期时，使用带有明确样式代码的CONVERT函数，或者更现代的TRY_CONVERT（转换失败返回NULL，而不是报错）。

SELECT TRY_CONVERT(DATETIME2, ‘2023-13-01‘, 120); -- 返回 NULL SELECT CONVERT(DATETIME2, ‘2023-13-01‘, 120); -- 报错：转换失败

使用TRY_系列函数（TRY_CONVERT,TRY_CAST,TRY_PARSE）可以使你的代码更健壮，避免因为脏数据导致整个查询失败。

5. 疑难杂症排查与解决方案实录

即使掌握了所有函数，在实际开发中还是会遇到一些令人头疼的问题。这里记录了几个我亲身踩过的坑和解决方案。

5.1 问题：DATEDIFF计算周数结果不符合预期？

现象：计算两个日期之间相差的周数，发现结果和日历上数出来的不一样。根因：DATEDIFF(WEEK, ...)计算的是两个日期之间“星期几边界”（例如周日到周一）跨越的次数，而不是完整的7天周期数。它的计算严重依赖于@@DATEFIRST的设置。复现与解决：

SET DATEFIRST 7; -- 设置周日为一周的第一天（美国默认） SELECT DATEDIFF(WEEK, ‘2023-10-29‘, ‘2023-10-30‘); -- 结果：1 (从周日跨到周一) SET DATEFIRST 1; -- 设置周一为一周的第一天（国际标准/中国） SELECT DATEDIFF(WEEK, ‘2023-10-29‘, ‘2023-10-30‘); -- 结果：0

解决方案：如果业务上需要计算完整的7天周期数，更可靠的方法是计算天数差再除以7。

SELECT DATEDIFF(DAY, ‘2023-10-01‘, ‘2023-10-31‘) / 7 AS CompleteWeeks;

在进行任何与“周”相关的计算前，务必用SET DATEFIRST明确服务器周的起始日，或者使用基于天数的计算来规避歧义。

5.2 问题：DATEPART(WEEKDAY, ...)返回值飘忽不定？

现象：同一个日期，WEEKDAY返回的值有时是1，有时是7。根因：WEEKDAY的返回值（1-7）对应周几，取决于@@DATEFIRST的设置。@@DATEFIRST=1时，1=周一，7=周日；@@DATEFIRST=7时，1=周日，7=周六。解决方案：如果需要与具体星期名称（如‘Monday‘）绑定，使用DATENAME函数。如果需要固定的数字表示（比如1总是周一），则在计算前设置SET DATEFIRST 1，或者使用一个更稳定的公式：

-- 返回一个固定的ISO周几数字（1=周一，7=周日） SELECT ((DATEPART(WEEKDAY, GETDATE()) + @@DATEFIRST - 2) % 7) + 1 AS ISO_Weekday;

5.3 问题：批量更新日期字段时超慢？

现象：用一个包含DATEADD或复杂日期计算的UPDATE语句更新一个大表，性能极差。排查与解决：

1. 检查是否在SET列上使用了函数：UPDATE T SET DateCol = DATEADD(DAY, 1, DateCol)这种写法是OK的，因为是对原字段值进行计算。
2. 检查WHERE条件是否SARGable：如果WHERE子句像WHERE CONVERT(VARCHAR, DateCol, 112) = ‘20231102‘，会导致全表扫描。必须改写为WHERE DateCol >= ‘2023-11-02‘ AND DateCol < ‘2023-11-03‘。
3. 考虑批处理：对于超大规模更新，不要一次性执行。使用WHILE循环或TOP子句进行分批提交，减少事务日志压力和锁竞争。

   WHILE 1=1 BEGIN UPDATE TOP (10000) MyTable SET UpdateTime = GETUTCDATE() WHERE SomeCondition = 1 AND UpdateTime IS NULL; -- 只更新未处理的部分 IF @@ROWCOUNT = 0 BREAK; WAITFOR DELAY ‘00:00:01‘; -- 可选，减轻系统负载 END

5.4 问题：FORMAT函数导致查询超时？

现象：一个在测试环境运行很快的报表查询，在生产环境大数据量下超时。排查：使用SQL Server Profiler或扩展事件捕获执行计划，发现最耗时的操作是一个针对数百万行数据的FORMAT函数调用。根因：FORMAT函数是CLR函数，每行调用一次开销巨大。解决方案：

• 首选：将格式化操作移至应用层（如C#、Java、Python），数据库只返回原始的DATETIME2或标准化字符串（如CONVERT(VARCHAR, date, 120)）。
• 次选：如果必须在数据库层格式化，考虑在ETL过程中将格式化好的字符串作为一个持久化列存入表或视图，用触发器或计算列维护，避免实时计算。
• 紧急止血：对于现有查询，尝试能否在WHERE或GROUP BY子句之前，先通过子查询或CTE将数据量过滤到最小，再对少量结果集应用FORMAT。

日期时间处理是SqlServer开发中的基本功，但细节繁多，陷阱也不少。从基础的获取、构建，到复杂的计算、格式化，再到深层次的性能优化和时区处理，每一个环节都需要我们根据具体的业务场景做出恰当的选择。这份指南试图为你提供一个从入门到精通的路径图，但真正的掌握，还需要你在实际项目中反复运用和思考。记住几个核心原则：保持字段“干净”以利用索引、新项目优先使用DATETIME2、时间存储坚持UTC、对不信任的数据使用TRY_函数。当你把这些原则内化，再结合本文提供的各种“套路”和“避坑指南”，你会发现绝大多数日期时间问题都能迎刃而解。