企业官网建设流程全解析

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

干了这么多年数据库开发，我发现一个挺有意思的现象：无论是新手还是老手，但凡涉及到SQL Server里的日期时间处理，总免不了要去翻文档或者搜一下某个函数的具体用法。日期时间，这个看似基础的数据类型，在实际业务里却是“事故”高发区。订单的创建时间、用户的生日、活动的有效期、报表的统计周期……几乎每个关键业务逻辑都绕不开它。但问题在于，SQL Server提供的日期时间函数零零散散有二三十个，每个函数又有自己特定的参数和返回值格式，光靠脑子记，难免有疏漏。

更让人头疼的是，很多网上的资料要么不全，只讲几个常用的GETDATE()、DATEADD；要么就是直接贴官方文档的翻译，缺乏实际场景的串联和避坑指南。结果就是，开发时写出来的日期查询逻辑，可能在测试环境跑得好好的，一到生产环境，遇到跨时区、闰年、月末最后一天或者性能瓶颈时就“现原形”了。所以，我决定结合自己这些年踩过的坑和积累的经验，整理一份真正“最全”且“能用”的SQL Server日期时间函数指南。这份指南的目的不是简单罗列函数，而是帮你建立一个清晰的“工具箱”认知：知道在什么场景下，该用什么工具，以及怎么用才最安全、最高效。

2. 核心需求解析：日期时间处理的四大核心场景

在深入每个函数之前，我们必须先搞清楚，我们到底要用这些函数解决什么问题？根据我的经验，所有的日期时间操作都可以归结为以下四个核心场景，理解了场景，函数的学习就事半功倍了。

2.1 场景一：获取当前时间与服务器时间基准

这是最基础的场景，但水一点也不浅。核心需求是获取一个可靠的“此刻”时间戳。GETDATE()和SYSDATETIME()是最常用的，但你知道它们有什么区别吗？

GETDATE()返回的是datetime类型，精度到3.33毫秒，而SYSDATETIME()返回的是datetime2类型，精度高达100纳秒。在需要高精度时间戳的场景，比如金融交易流水、高频日志记录，必须使用SYSDATETIME()。我曾经遇到过因为使用GETDATE()导致两条几乎同时发生的交易记录时间戳完全相同，给后续的审计和排序带来了麻烦。

-- 获取当前日期和时间 (旧式，精度较低) SELECT GETDATE() AS CurrentDateTime; -- 获取当前日期和时间 (高精度，推荐用于新系统) SELECT SYSDATETIME() AS CurrentDateTimeHighPrecision; -- 只获取当前日期部分，时间部分为00:00:00.000 SELECT CAST(GETDATE() AS DATE) AS Today; SELECT CONVERT(DATE, GETDATE()) AS Today; -- 另一种写法

这里有一个非常重要的注意事项：这些函数获取的是SQL Server实例所在服务器的系统时间。如果你的应用服务器和数据库服务器分布在不同的地理位置，或者服务器时间未同步，就会导致“应用层时间”和“数据库记录时间”不一致。对于分布式系统，最佳实践是统一使用协调世界时（UTC）来存储和计算。这时，你应该使用GETUTCDATE()或SYSUTCDATETIME()。

注意：在定义表结构时，对于记录创建时间的字段（如CreateTime），我强烈建议默认值设置为GETUTCDATE()，而非GETDATE()。这为未来可能的跨时区业务扩展打下了基础。

2.2 场景二：日期的“计算”与“推算”

业务逻辑中充满了基于时间的推算：“三天后发货”、“会员有效期一年”、“统计上个月的销售额”。这就是DATEADD和DATEDIFF函数的主场。

DATEADD函数用于向日期添加一个时间间隔。它的语法是DATEADD(datepart, number, date)。关键在于第一个参数datepart，它决定了加减的“单位”。常用的有YEAR,QUARTER,MONTH,DAY,WEEK,HOUR,MINUTE,SECOND等。

-- 计算明天、下个月和一年后的今天 SELECT DATEADD(DAY, 1, GETDATE()) AS Tomorrow, DATEADD(MONTH, 1, GETDATE()) AS NextMonth, DATEADD(YEAR, 1, GETDATE()) AS NextYear; -- 一个实际案例：计算订单的预计最晚发货时间（假设下单后3个工作日内发货） -- 这里简化处理，直接加3天。实际中可能需要排除周末和节假日。 SELECT OrderID, OrderDate, DATEADD(DAY, 3, OrderDate) AS LatestShipDate FROM Orders;

DATEDIFF则用于计算两个日期之间的间隔。语法是DATEDIFF(datepart, startdate, enddate)。这里有一个经典的“坑”：计算年龄。很多人会直接用DATEDIFF(YEAR, BirthDate, GETDATE())，但这在生日还没到的那天会多算一岁。正确的做法需要结合CASE WHEN进行判断。

-- 错误示例：计算年龄 SELECT DATEDIFF(YEAR, '1990-02-28', '2023-02-27') AS WrongAge; -- 返回33，实际应为32 -- 正确示例：计算精确年龄 DECLARE @BirthDate DATE = '1990-02-28'; DECLARE @CurrentDate DATE = '2023-02-27'; SELECT DATEDIFF(YEAR, @BirthDate, @CurrentDate) - CASE WHEN MONTH(@BirthDate) > MONTH(@CurrentDate) OR (MONTH(@BirthDate) = MONTH(@CurrentDate) AND DAY(@BirthDate) > DAY(@CurrentDate)) THEN 1 ELSE 0 END AS CorrectAge;

2.3 场景三：日期的“拆解”与“组装”

我们经常需要从完整的日期时间中提取出年、月、日、星期几等部分，或者反过来，用这些部分组合成一个日期。这就是DATEPART、DATENAME和DATEFROMPARTS等函数的用武之地。

DATEPART返回代表日期某部分的整数（如年=2023，月=8）。DATENAME返回日期某部分的字符串名称（如星期='Friday'，月份='August'），这个名称依赖于服务器的语言设置。

-- 提取日期的各个部分 SELECT GETDATE() AS Now, DATEPART(YEAR, GETDATE()) AS YearPart, DATEPART(MONTH, GETDATE()) AS MonthPart, -- 返回8 DATENAME(MONTH, GETDATE()) AS MonthName, -- 返回'August'（如果服务器语言是英文） DATEPART(WEEKDAY, GETDATE()) AS WeekdayNumber, -- 返回1-7 (周日=1) DATENAME(WEEKDAY, GETDATE()) AS WeekdayName; -- 返回'Sunday'等 -- 根据年月日构建一个日期 (SQL Server 2012+) -- 这是避免字符串拼接和隐式转换的推荐做法，非常安全。 SELECT DATEFROMPARTS(2023, 8, 15) AS ConstructedDate; -- 2023-08-15 SELECT DATETIMEFROMPARTS(2023, 8, 15, 14, 30, 0, 0) AS ConstructedDateTime; -- 2023-08-15 14:30:00.000

在报表开发中，按年、月、季度分组统计是高频操作。使用DATEPART可以轻松实现：

-- 统计2023年每个月的销售额 SELECT DATEPART(MONTH, OrderDate) AS OrderMonth, SUM(OrderAmount) AS TotalAmount FROM SalesOrders WHERE DATEPART(YEAR, OrderDate) = 2023 GROUP BY DATEPART(MONTH, OrderDate) ORDER BY OrderMonth;

2.4 场景四：日期的“格式化”与“解析”

这是前端展示和外部数据导入时最常遇到的问题。数据库内部以二进制格式高效存储日期，但展示给人看时需要转换成YYYY-MM-DD或DD/MM/YYYY等格式。CONVERT和FORMAT函数负责这项任务。

CONVERT函数功能强大，但用于日期格式化时，主要依赖style参数。这个参数是一个数字，代表不同的输出格式。

-- 使用CONVERT进行日期格式化 SELECT GETDATE() AS Original, CONVERT(VARCHAR(10), GETDATE(), 120) AS Style_120, -- YYYY-MM-DD HH:MI:SS CONVERT(VARCHAR(10), GETDATE(), 112) AS Style_112, -- YYYYMMDD (纯数字，适合排序或作为文件名) CONVERT(VARCHAR(10), GETDATE(), 23) AS Style_23; -- YYYY-MM-DD (ISO标准，最推荐)

FORMAT函数（SQL Server 2012+）更加强大和直观，它使用.NET Framework的格式字符串，类似于C#中的ToString方法。

-- 使用FORMAT进行更灵活的格式化 SELECT GETDATE() AS Original, FORMAT(GETDATE(), 'yyyy-MM-dd') AS ISO_Date, -- 2023-08-15 FORMAT(GETDATE(), 'dd/MM/yyyy') AS UK_Date, -- 15/08/2023 FORMAT(GETDATE(), 'dddd, MMMM dd, yyyy') AS LongDate; -- Tuesday, August 15, 2023

重要提醒：FORMAT函数虽然好用，但性能开销较大，因为它本质上是调用CLR（公共语言运行时）。在对大结果集（数万行以上）进行查询，或在WHERE、GROUP BY子句中使用FORMAT时，可能会引发严重的性能问题。在内部逻辑处理和条件筛选时，应优先使用CONVERT或直接对DATEPART进行比较。FORMAT最好仅用于最终结果集的展示层。

3. 核心函数库深度解析与实战技巧

掌握了核心场景，我们就可以系统地梳理SQL Server的日期时间函数库了。我将它们分为几个功能组，并附上实战中总结的技巧和避坑点。

3.1 获取与截断函数组

这个组的函数负责获取时间点或对现有时间进行“修剪”。

1. 获取当前时间：

   • GETDATE()/CURRENT_TIMESTAMP：返回当前datetime。CURRENT_TIMESTAMP是ANSI SQL标准写法。
   • GETUTCDATE()：返回当前UTC时间的datetime。
   • SYSDATETIME()/SYSUTCDATETIME()：返回高精度的datetime2，分别对应本地和UTC时间。
   • SYSDATETIMEOFFSET()：返回包含时区偏移量的datetimeoffset类型时间，这是处理跨时区数据的终极武器。

2. 截断函数：

   • CAST(date AS DATE)：这是将datetime或datetime2截断至日期部分（时间归零）的最佳实践，性能最好，语义最清晰。
   • CONVERT(DATE, date)：功能同上，是另一种写法。
   • DATETRUNC(datepart, date)(SQL Server 2022+ 新增)：这个新函数非常强大，可以截断到指定的日期部分。例如，DATETRUNC(MONTH, ‘2023-08-15 14:30:00’)将返回2023-08-01 00:00:00.000。如果你的环境是SQL Server 2022+，强烈推荐使用它来代替复杂的DATEADD和DATEDIFF组合。

实战技巧：如何高效地查询“今天”的数据？错误做法是在WHERE子句中对字段使用函数，这会导致索引失效。

-- 错误做法：导致全表扫描 SELECT * FROM Orders WHERE CAST(OrderDate AS DATE) = CAST(GETDATE() AS DATE); -- 正确做法：使用范围查询，可以利用索引 SELECT * FROM Orders WHERE OrderDate >= CAST(GETDATE() AS DATE) AND OrderDate < DATEADD(DAY, 1, CAST(GETDATE() AS DATE));

3.2 计算与推算函数组

这是业务逻辑的核心，务必熟练掌握。

1. DATEADD(datepart, number, date)：前面已详细介绍。number可以为负数，表示向前推算。
2. DATEDIFF(datepart, startdate, enddate)：计算两个日期的间隔。注意，它计算的是跨越的“边界”数。例如，DATEDIFF(DAY, ‘2023-08-15 23:59:59’, ‘2023-08-16 00:00:01’)返回1，尽管时间差只有2秒。
3. EOMONTH(start_date [, month_to_add])(SQL Server 2012+)：神级函数！传入一个日期，返回该日期所在月份的最后一天。可选参数month_to_add可以推算未来或过去某个月的最后一天。

-- 获取本月底、下月底、上月底的日期 SELECT EOMONTH(GETDATE()) AS ThisMonthEnd, -- 2023-08-31 EOMONTH(GETDATE(), 1) AS NextMonthEnd, -- 2023-09-30 EOMONTH(GETDATE(), -1) AS LastMonthEnd; -- 2023-07-31 -- 经典应用：生成一个月的日期维度表 DECLARE @StartDate DATE = '2023-08-01'; DECLARE @EndDate DATE = EOMONTH(@StartDate); -- ... 后续可以用循环或递归CTE生成从@StartDate到@EndDate的所有日期

3.3 提取与解析函数组

用于从日期中获取特定部件。

1. DATEPART(datepart, date)：返回整数。
2. DATENAME(datepart, date)：返回字符串。注意其语言依赖性。
3. YEAR(date)/MONTH(date)/DAY(date)：DATEPART的快捷方式，代码更简洁。
4. 组装函数：DATEFROMPARTS(year, month, day),DATETIME2FROMPARTS,SMALLDATETIMEFROMPARTS,TIMEFROMPARTS等。在动态构造日期时，永远优先使用这些函数，而不是字符串拼接，可以完全避免格式歧义和转换错误。

-- 危险的字符串拼接 DECLARE @y INT=2023, @m INT=08, @d INT=15; SELECT CAST(@y AS VARCHAR) + '-' + @m + '-' + @d; -- 可能因类型转换失败或格式问题出错 -- 安全的组装方式 SELECT DATEFROMPARTS(@y, @m, @d); -- 2023-08-15

3.4 验证与判断函数组

用于处理脏数据或进行逻辑判断。

1. ISDATE(expression)：判断字符串是否可以转换为日期。返回1（真）或0（假）。但要注意，它的结果受会话语言设置影响！例如，‘01/02/03’在美国语言下可能是2003-01-02，在英国语言下可能是2003-02-01，而ISDATE可能都返回1，但转换结果不同。
2. 日期范围校验：SQL Server本身没有直接的“是否在范围内”函数，但我们可以轻松组合。

-- 判断一个日期是否在本周内 DECLARE @TargetDate DATE = '2023-08-16'; SELECT CASE WHEN @TargetDate >= DATEADD(WEEK, DATEDIFF(WEEK, 0, GETDATE()), 0) -- 本周周一 AND @TargetDate < DATEADD(WEEK, DATEDIFF(WEEK, 0, GETDATE()) + 1, 0) -- 下周一 THEN '在本周内' ELSE '不在本周内' END AS WeekCheck;

3.5 格式化与转换函数组

1. CONVERT(data_type, date [, style])：功能多样，可用于类型转换和格式化。记住几个关键style码：112(YYYYMMDD),120(YYYY-MM-DD HH:MI:SS),23(YYYY-MM-DD)。
2. FORMAT(date, format [, culture])：功能强大，但慎用。culture参数可以指定区域设置，如‘en-US’,‘zh-CN’。

-- 使用FORMAT进行本地化展示 SELECT FORMAT(GETDATE(), 'D', 'zh-CN') AS ChineseLongDate; -- 2023年8月15日 SELECT FORMAT(GETDATE(), 'd', 'en-US') AS USShortDate; -- 8/15/2023

4. 高阶应用与性能优化实战

把单个函数用熟只是第一步，真正考验功力的是如何将它们组合起来，解决复杂的业务问题，并保证高性能。

4.1 复杂业务场景拆解

场景A：计算工作日（排除周末和节假日）这是一个经典需求。我们需要一个“工作日日历表”作为基础。假设我们有一个WorkCalendar表，包含所有工作日日期。

-- 计算订单从下单到发货的工作日天数 SELECT o.OrderID, o.OrderDate, o.ActualShipDate, (SELECT COUNT(*) FROM WorkCalendar c WHERE c.WorkDate >= o.OrderDate AND c.WorkDate < o.ActualShipDate) AS WorkingDays FROM Orders o WHERE o.ActualShipDate IS NOT NULL;

场景B：生成连续日期序列（用于填充报表缺失日期）使用递归公共表表达式（CTE）是标准做法。

DECLARE @StartDate DATE = '2023-08-01'; DECLARE @EndDate DATE = '2023-08-31'; WITH DateSeries AS ( SELECT @StartDate AS TheDate UNION ALL SELECT DATEADD(DAY, 1, TheDate) FROM DateSeries WHERE TheDate < @EndDate ) SELECT TheDate, DATENAME(WEEKDAY, TheDate) AS WeekdayName FROM DateSeries OPTION (MAXRECURSION 365); -- 防止无限递归

场景C：处理月末最后一天的特殊逻辑DATEADD和DATEDIFF在处理月末时有个“陷阱”：DATEADD(MONTH, 1, ‘2023-01-31’)会得到2023-02-28，而DATEADD(MONTH, DATEDIFF(MONTH, 0, ‘2023-01-31’), 0)可以得到当月的第一天。结合EOMONTH函数可以更优雅地处理。

-- 获取任意日期所在月份的第一天（SQL Server 2008+通用方法） SELECT DATEADD(MONTH, DATEDIFF(MONTH, 0, GETDATE()), 0) AS FirstDayOfMonth; -- 获取上个月的最后一天（使用EOMONTH） SELECT EOMONTH(GETDATE(), -1) AS LastDayOfLastMonth;

4.2 索引与SARGable原则优化

这是性能优化的核心。SARGable指的是查询条件能够利用索引（Search Argument Able）。在WHERE和JOIN子句中，对日期列进行任何函数操作（如CONVERT,FORMAT,DATEPART,DATEADD等）都会导致索引失效。

-- 反例：非SARGable，无法使用OrderDate上的索引 SELECT * FROM LargeSalesTable WHERE YEAR(OrderDate) = 2023 AND MONTH(OrderDate) = 8; -- 正例：SARGable，可以高效利用索引 SELECT * FROM LargeSalesTable WHERE OrderDate >= '2023-08-01' AND OrderDate < '2023-09-01'; -- 另一个常见反例：查询“过去30天”的数据 SELECT * FROM LogTable WHERE DATEDIFF(DAY, CreateTime, GETDATE()) <= 30; -- 糟糕！ -- 正例： SELECT * FROM LogTable WHERE CreateTime >= DATEADD(DAY, -30, GETDATE()); -- 优秀！

对于按年、月、季度分组的统计查询，如果WHERE条件中必须使用函数，可以考虑创建持久化计算列并为其建立索引。

-- 1. 添加计算列 ALTER TABLE Sales ADD SaleYear AS YEAR(OrderDate) PERSISTED; ALTER TABLE Sales ADD SaleMonth AS MONTH(OrderDate) PERSISTED; -- 2. 在计算列上创建索引 CREATE INDEX IX_Sales_YearMonth ON Sales(SaleYear, SaleMonth); -- 3. 查询时直接使用计算列，效率极高 SELECT SaleYear, SaleMonth, SUM(Amount) FROM Sales WHERE SaleYear = 2023 AND SaleMonth = 8 GROUP BY SaleYear, SaleMonth;

4.3 时区处理最佳实践

对于全球化应用，时区是必须严肃对待的问题。我的建议是：

1. 存储层：始终使用UTC时间。使用datetimeoffset类型存储可以保留原始的时区信息，但更常见的做法是用datetime2存储UTC时间。
2. 业务逻辑层：所有内部计算、比较、排序都基于UTC时间进行。
3. 展示层：在数据最终呈现给用户前，根据用户的个人时区设置，在应用服务器或数据库查询中使用AT TIME ZONE（SQL Server 2016+）进行转换。

-- 假设我们以UTC时间存储 CREATE TABLE Events ( EventId INT PRIMARY KEY, EventName NVARCHAR(100), EventTimeUTC DATETIME2 ); -- 插入一条UTC时间记录 INSERT INTO Events VALUES (1, 'Product Launch', '2023-08-15 09:00:00'); -- 查询时，转换为美国东部时间（夏令时） SELECT EventName, EventTimeUTC AT TIME ZONE 'UTC' AT TIME ZONE 'Eastern Standard Time' AS EventTimeEST FROM Events; -- 查询今天（美国东部时间）的事件 DECLARE @TodayEST DATE = CAST(SYSDATETIMEOFFSET() AT TIME ZONE 'Eastern Standard Time' AS DATE); SELECT * FROM Events WHERE CAST(EventTimeUTC AT TIME ZONE 'UTC' AT TIME ZONE 'Eastern Standard Time' AS DATE) = @TodayEST;

注意：AT TIME ZONE转换依赖于SQL Server服务器上的时区数据。确保你的服务器操作系统时区数据是最新的，特别是对于夏令时规则可能变化的地区。

5. 常见疑难杂症与避坑指南

在实际开发中，你一定会遇到下面这些问题。我把它们和解决方案记录下来，希望能帮你节省大量排查时间。

5.1 日期格式歧义与转换失败

这是最经典的“坑”。‘01/02/2023’是1月2日还是2月1日？这取决于服务器的DATEFORMAT或语言设置。

根本原因：当使用CONVERT或CAST从字符串隐式或显式转换为日期时，SQL Server会尝试根据当前会话的设置去解析。如果字符串格式不明确，就可能出错或得到意外结果。

解决方案：

1. 使用标准格式：对于字面量，使用YYYYMMDD或YYYY-MM-DDTHH:MM:SS这类无歧义的ISO格式。SQL Server总能正确解析它们。

   SELECT CAST('20230815' AS DATE); -- 安全 SELECT CAST('2023-08-15T14:30:00' AS DATETIME2); -- 安全

2. 使用CONVERT并明确指定style参数：如果你必须处理非标准格式字符串，使用CONVERT并指定第三参数style码。

   SELECT CONVERT(DATE, '15/08/2023', 103); -- 指定为dd/mm/yyyy格式 (style 103)

3. 使用PARSE函数 (SQL Server 2012+)：PARSE可以配合区域性设置，更智能地解析，但性能比CONVERT差。

   SELECT PARSE('August 15, 2023' AS DATE USING 'en-US');

4. 在应用层统一转换：最彻底的做法是在代码（C#, Java等）中将日期格式化为无歧义的字符串（如ISO 8601），再传递给数据库。

5.2 时间类型的精度与溢出问题

• datetime类型：范围1753-01-01到9999-12-31，精度3.33毫秒。不要用它存储1753年以前的日期（如历史数据）。
• datetime2类型：范围0001-01-01到9999-12-31，精度可指定（最高100纳秒）。对于新项目，无脑选择datetime2就对了。
• smalldatetime类型：范围1900-01-01到2079-06-06，精度到分钟。存储空间小，但范围有限且精度低，现代系统已很少使用。
• date类型：仅存储日期，无时间部分。存储生日、纪念日等非常合适。
• time类型：仅存储时间，无日期部分。

避坑点：在进行日期计算时，要注意类型的隐式转换和可能的数据截断。例如，将datetime2的高精度值赋给datetime列，会损失精度。

5.3 日期函数在WHERE子句中的性能陷阱

如前所述，在WHERE子句中对索引列使用函数是性能杀手。这里再强调几个隐蔽的陷阱：

• 隐式转换：如果WHERE子句中比较的两个值数据类型不同，SQL Server会进行隐式转换，也可能导致索引失效。

  -- 假设OrderDate是datetime类型 DECLARE @SearchDate VARCHAR(20) = '2023-08-15'; SELECT * FROM Orders WHERE OrderDate = @SearchDate; -- 发生隐式转换，索引可能失效 -- 应改为： SELECT * FROM Orders WHERE OrderDate = CAST(@SearchDate AS DATETIME);

• 使用BETWEEN处理日期范围：BETWEEN是包含边界的。对于带有时间的datetime字段，BETWEEN ‘2023-08-15’ AND ‘2023-08-15’查不到任何数据，因为‘2023-08-15’被当作‘2023-08-15 00:00:00.000’。更推荐使用>=和<的组合。

5.4 特定函数在不同版本间的差异

• FORMAT和EOMONTH是SQL Server 2012引入的。
• DATETRUNC是SQL Server 2022引入的。
• AT TIME ZONE是SQL Server 2016引入的。

在编写通用脚本或为不同版本环境提供支持时，要注意函数的兼容性。可以使用IF语句判断版本，或者准备替代方案。

-- 模拟DATETRUNC功能（用于SQL Server 2012-2019） DECLARE @InputDate DATETIME2 = GETDATE(); DECLARE @DatePart VARCHAR(10) = 'MONTH'; SELECT CASE @DatePart WHEN 'YEAR' THEN DATEFROMPARTS(YEAR(@InputDate), 1, 1) WHEN 'MONTH' THEN DATEFROMPARTS(YEAR(@InputDate), MONTH(@InputDate), 1) WHEN 'DAY' THEN CAST(@InputDate AS DATE) -- ... 其他部分 END AS TruncatedDate;

5.5 星期与工作日计算的区域性差异

DATEPART(WEEKDAY, date)的返回值受SET DATEFIRST设置影响。DATEFIRST定义了每周的第一天是星期几（美国是周日=7，欧洲多是周一=1）。这会导致按周分组统计时结果不一致。

解决方案：在需要跨区域一致性的查询中，显式设置DATEFIRST，或者使用更复杂的计算来标准化星期数。

-- 将周一作为每周的第一天，并返回1-7（周一到周日） SET DATEFIRST 1; SELECT DATEPART(WEEKDAY, GETDATE()) AS MondayBasedWeekday; -- 或者，使用一个不依赖DATEFIRST的计算方法 SELECT (DATEPART(WEEKDAY, GETDATE()) + @@DATEFIRST - 2) % 7 + 1 AS ConsistentWeekday;

处理日期时间，本质上是在处理业务规则的具象化。这份指南里的每一个函数、每一个技巧，背后都是无数个需求、无数个坑堆出来的经验。我最深的体会是，在数据库设计之初，就明确日期时间字段的用途（是纯日期、时间戳还是带时区？），选择正确的数据类型，并坚持使用UTC时间存储，能为后续开发省去至少一半的麻烦。当遇到复杂的日期逻辑时，别急着写一堆嵌套函数，先拆解步骤，用CTE或者临时表把中间结果理清楚，代码的可读性和可维护性会高很多。最后，性能问题往往出现在最不起眼的地方，养成在WHERE子句中避免对索引列进行函数操作的习惯，是写出高效SQL的基本素养。