1. 为什么 sql dateadd 函数是绕不开的时间计算工具做过账单、报表、会员系统的人大概都有这种体会需求里最不起眼的一句话往往就是时间计算的坑。比如用户到期前七天发一次提醒统计最近三十天的活跃用户把下单时间按月归到对应的账期——这些需求单看逻辑都不复杂但落到 sql 语句里几乎全部要靠 dateadd 函数家族来完成偏移计算。它解决的问题非常聚焦给一个时间点按某个粒度往前或往后推若干个单位返回一个新的时间点。这篇内容围绕 sql dateadd 函数展开但不会只停留在语法怎么写的层面。因为真正让人出问题的从来不是记住DATEADD(day, 1, date)这种写法而是参数怎么选、边界怎么处理、索引会不会失效、换个数据库怎么改写。我会把 SQL Server 的 DATEADD 当作主线顺带把 MySQL、PostgreSQL、Oracle、SQLite、BigQuery 这几个常见环境里对应的写法一起梳理清楚因为现实项目里跨库迁移太常见了一个在 SQL Server 里跑得好好的语句搬到 MySQL 可能直接报错。适合谁看写过基础 SQL、能看懂 JOIN 和 GROUP BY但一碰到上月同期自然周起始日月末对齐就开始翻文档的人正在做报表开发、数仓建模、后端业务逻辑的同学以及准备从一种数据库迁到另一种需要一份语义对照清单的人。我会把踩过的坑、排查思路、优化改写都写进去能直接抄走用。2. DATEADD 的三个参数每个都能让人翻车2.1 参数骨架与返回值类型SQL Server 里的标准签名是DATEADD (datepart, number, date)三个参数依次是时间粒度、偏移量、基准时间。它返回的类型跟第三个参数完全一致——传 datetime 返回 datetime传 date 返回 date传 datetime2 返回 datetime2传 time 返回 time。这一点很多人没注意导致后续比较时出现精度问题。看一个最基础的例子-- 基准是 datetime2(7)返回值也是 datetime2(7) SELECT DATEADD(day, -7, CAST(2024-03-15 10:20:30.1234567 AS datetime2(7))); -- 结果2024-03-08 10:20:30.1234567第三个参数如果是字符串SQL Server 会先隐式转换成 datetime 再参与计算返回的也是 datetime。这带来一个隐藏风险字符串的解析依赖当前会话的DATEFORMAT和LANGUAGE设置。01/02/2024在不同语言设置下可能是 1 月 2 日也可能是 2 月 1 日。所以我在生产环境里从来不给 DATEADD 直接喂字符串一律显式 CAST 成date或datetime2把解析规则钉死。提示涉及日期常量的地方用2024-01-02这种 ISO 8601 的yyyy-mm-dd格式最保险它不受语言设置影响带时间的场景用2024-01-02T10:20:30。2.2 datepart 全表与缩写陷阱datepart 支持的单位比大多数人用到的多缩写更是重灾区。我整理了一张常用对照表datepart常用缩写说明yearyy, yyyy年quarterqq, q季度monthmm, m月dayofyeardy, y一年中的第几天daydd, d日weekwk, ww周weekdaydw, w星期几仅作为偏移粒度时等于 dayhourhh小时minutemi, n分钟secondss, s秒millisecondms毫秒microsecondmcs微秒nanosecondns纳秒最经典的坑是m和mi。m是month月mi才是minute分钟。我见过有人写DATEADD(m, 30, GETDATE())想加 30 分钟结果时间直接跳到 30 个月之后测试环境数据少没被发现上线后定时任务的查询窗口全部错位。同理s是秒ss也是秒但ms是毫秒mcs是微秒ns是纳秒这三个后缀差一个字母量级差一千倍。还有一组容易混的dd、d都是日dy、y是年积日dw、w是星期。虽然DATEADD(dw, 1, ...)和DATEADD(dd, 1, ...)结果一样但语义上dw是用来取星期几的配合DATEPART拿它做偏移纯属给自己添麻烦。我的建议是在团队规范里禁用单字母缩写统一写day、month、minute、second多打几个字符换来的是半年后自己能读懂。这个代价太值了。2.3 number 参数小数、负数、溢出的真实行为第二个参数是偏移量类型是 int。正数是往后推负数是往前推零就是原样返回但类型可能被转换。三个行为必须记住第一小数会被截断不是四舍五入。传入 1.9 等价于 1传入 -1.9 等价于 -1。SQL Server 对 number 参数做的是向零截断。所以如果你从应用程序传了一个decimal类型的天数进来一定要在应用层先取整别指望数据库帮你处理。第二超出 int 范围会直接报错。DATEADD(year, 3000000000, GETDATE())会因为 30 亿超出 int 上限而报错而不是返回一个极大的日期。第三结果超出目标类型范围会溢出。这是最容易踩的-- datetime 的上限是 9999-12-31 23:59:59.997 SELECT DATEADD(year, 1, CAST(9999-12-31 AS datetime)); -- 报错Adding a value to a datetime column caused an overflow.date类型同样有 9999-12-31 的上限。做会员永久有效这类需求时很多人习惯写DATEADD(year, 100, GETDATE())当永久这在 9999 年之前是安全的但如果基准时间已经接近上限或者偏移量本身很大就会炸。更稳的做法是用一个明确的哨兵值比如CAST(9999-12-31 AS date)而不是靠加法去凑。3. 月末、闰年、跨年时间加法最容易翻车的地方3.1 月末对齐与月末漂移先说一个必须理解清楚的行为DATEADD 在月粒度上是目标月份不存在该日则取月末在日粒度上是精确平移。这跟 Oracle 的ADD_MONTHS、MySQL 的DATE_ADD(INTERVAL n MONTH)行为一致但跟某些人脑子里的加 30 天完全不是一回事。SELECT DATEADD(month, 1, CAST(2024-01-31 AS date)); -- 2024-02-29闰年 SELECT DATEADD(month, 1, CAST(2023-01-31 AS date)); -- 2023-02-28 SELECT DATEADD(month, 1, CAST(2023-03-31 AS date)); -- 2023-04-30看起来很贴心对吧但问题出在连续加法上。这是个真实的坑-- 想做连续三个月每月月末于是这样写 SELECT DATEADD(month, 0, CAST(2024-01-31 AS date)) AS m1, -- 2024-01-31 DATEADD(month, 1, CAST(2024-01-31 AS date)) AS m2, -- 2024-02-29 DATEADD(month, 2, CAST(2024-01-31 AS date)) AS m3; -- 2024-03-31正确只要每次都以原始基准日计算结果是正确的。但如果写成链式递推每次都拿上一次的结果当基准-- 错误示范链式递推导致月末日越算越小 -- 2024-01-31 - 2024-02-29 - 2024-03-29 - 2024-04-29 ...一旦中间落到了 29 号后面就再也回不到 31 号了。这个月末漂移在账期计算、分期还款计划、订阅续费里会造成实打实的金额差错。我的处理原则很简单所有周期性的偏移永远以原始基准日计算绝不在上一次结果上叠加。如果业务确实需要每个月最后一天那就老老实实用月末构造函数而不是靠加法碰运气-- 取指定月份的最后一天 DECLARE base date 2024-02-15; SELECT EOMONTH(base) AS 当月最后一天, EOMONTH(base, 1) AS 下月最后一天, EOMONTH(base, -1) AS 上月最后一天;EOMONTH是 SQL Server 2012 起提供的函数比DATEADD(month, 1, DATEADD(day, -1, DATEADD(month, 1, ...)))这种套娃写法清晰太多。如果你的环境版本够优先用它。3.2 闰年与 2 月 29 日闰年问题本质上是月末问题的特例但它值得单独说因为 2 月 29 日这个日期在业务上非常容易出现不该存在的日期。-- 2024-02-29 往前推一年 SELECT DATEADD(year, -1, CAST(2024-02-29 AS date)); -- 2023-02-28这个结果是合理的但很多业务逻辑会因此产生偏差。比如按年对比同日数据2024-02-29 的对标日是 2023-02-28而 2023-02-28 本身又是正常的一天如果直接拿两天做同比等于把 2023 年的 2 月 28 日和 2024 年的 2 月 29 日放在了一起实际上错位了一天。做严谨的同比分析时我通常会用年积日dayofyear对齐或者干脆按自然月汇总避开单日对齐带来的歧义。另外一个细节datetime类型的精度是 3.33 毫秒datetime2才是 100 纳秒。做跨年跨月的高精度计算时如果列是datetimeDATEADD(millisecond, 1, ...)可能加不出你想要的值因为 1 毫秒落在它的精度间隙里会被舍入。要精确到毫秒以下先把类型转成datetime2(3)或更高精度。3.3 跨年跨季的偏移写法季度偏移用quarter很直观加 1 个季度等于加 3 个月但语义更清楚SELECT DATEADD(quarter, -1, CAST(2024-05-20 AS date)); -- 2024-02-20跨年也是自动处理的不用担心 12 月加 1 个月会出错SELECT DATEADD(month, 1, CAST(2024-12-15 AS date)); -- 2025-01-15需要提醒的是week粒度加 1 等于加 7 天dayofyear加 1 等于加 1 天这两个和day在偏移语义上是等价的。它们的区别在于配合DATEPART时读取的含义不同别在偏移里用它们用了只会让代码更难读。4. 业务场景实战把 DATEADD 用进真实需求里4.1 到期日、账期与试用期计算这是 DATEADD 最主力的一块。典型需求用户 2024-01-31 开通 1 个月会员到期日是哪天SELECT DATEADD(month, 1, CAST(2024-01-31 AS date)); -- 2024-02-29按自然月算是 2 月 29 日符合大多数业务预期。但如果需求是30 天那就得写DATEADD(day, 30, ...)结果是 2024-03-01。这两个结果差了两天必须先跟产品确认清楚是自然月还是固定天数。我遇到过需求文档写一个月开发和测试各自理解不同最后对账对不上返工重算了几十万条订单的有效期。试用期同理。七天试用写成DATEADD(day, 7, created_at)但要考虑起算点的口径是从注册那一刻算含时分秒还是从次日零点算-- 口径 A精确到秒注册即刻起算 SELECT DATEADD(day, 7, created_at) AS expire_at FROM users; -- 口径 B从注册次日零点起算多给用户几个小时 SELECT DATEADD(day, 8, CAST(created_at AS date)) AS expire_at FROM users;第二种写法用了一个小技巧先把时间戳截断成日期去掉时分秒再加 8 天得到的就是次日零点 7 天。这类边界口径一定要在需求评审时定死写进字段注释里否则后期扯皮无穷无尽。4.2 报表时间窗口今天、本周、本月、上季度报表开发里 80% 的 DATEADD 都花在构造时间窗口上。我把常用窗口整理成一套可以直接复用的模板全部以GETDATE()为基准DECLARE now datetime2 SYSDATETIME(); DECLARE today date CAST(now AS date); -- 今天零点含到明天零点不含这是最推荐的左闭右开写法 SELECT today AS start_today, DATEADD(day, 1, today) AS end_today_exclusive; -- 最近 7 天含今天 SELECT DATEADD(day, -6, today) AS start_7d, DATEADD(day, 1, today) AS end_7d_exclusive; -- 本周一假设周一为一周起点 SELECT DATEADD(day, 1 - DATEPART(weekday, today), today) AS start_of_week; -- 本月第一天 / 下月第一天 SELECT DATEFROMPARTS(YEAR(today), MONTH(today), 1) AS start_of_month, DATEADD(month, 1, DATEFROMPARTS(YEAR(today), MONTH(today), 1)) AS start_of_next_month; -- 上季度第一天 SELECT DATEADD(quarter, DATEDIFF(quarter, 0, today) - 1, 0) AS start_of_last_quarter;最后这条DATEADD(quarter, DATEDIFF(quarter, 0, today) - 1, 0)是个非常经典的套路值得拆开讲。DATEDIFF(quarter, 0, today)算出的是从 1900-01-01 到现在的季度数减去 1 就是上一个季度的序号再把这个数量加回基准日0即 1900-01-01得到的就是上季度的第一天。这个用 DATEDIFF 算差值再用 DATEADD 还原的组合拳是 SQL Server 里做时间对齐的通用手法把quarter换成month、week、day就能得到对应粒度的起点。注意0在日期上下文里被解释为1900-01-01。这个隐式约定在 SQL Server 里成立但跨库迁移时完全不通用MySQL 和 PostgreSQL 里这么写会报错迁移时记得改。另外提醒一点DATEPART(weekday, ...)的返回值受SET DATEFIRST影响默认值是 7周日为一周第一天。如果你的业务按周一起算要么显式SET DATEFIRST 1要么用上面那个1 - DATEPART(weekday, ...)的偏移公式自适应。团队协作时我更推荐后者因为它不依赖会话状态复制到哪都能跑出同样的结果。4.3 留存、同比、环比的时间偏移留存计算的本质是两个时间窗口做关联DATEADD 在这里主要是构造对照窗口-- 次日留存今天注册、明天有行为的用户 SELECT COUNT(*) AS next_day_retention FROM users u WHERE u.created_at 2024-03-01 AND u.created_at 2024-03-02 AND EXISTS ( SELECT 1 FROM events e WHERE e.user_id u.id AND e.event_time DATEADD(day, 1, CAST(u.created_at AS date)) AND e.event_time DATEADD(day, 2, CAST(u.created_at AS date)) );这里用的是逐用户相对偏移而不是全局统一日期。这种做法更精确因为每个用户的次日起点不同。但代价也很明显DATEADD出现在了关联条件里无法用索引直接收窄范围只能靠created_at的过滤把数据量先压下来再逐条判断。如果用户量很大更常见的做法是先在子查询里把注册日期和次日窗口预先算出来用中间表或 CTE 落地再参与 JOIN。同比环比则是固定偏移-- 去年同期 SELECT DATEADD(year, -1, start_date) AS yoy_start, DATEADD(year, -1, end_date) AS yoy_end; -- 上月同期 SELECT DATEADD(month, -1, start_date) AS mom_start, DATEADD(month, -1, end_date) AS mom_end;这里有个老生常谈但确实容易出事的地方如果end_date是 3 月 31 日减一个月得到 2 月 29 日闰年或 28 日边界就变了。做严谨的环比时我的处理方式是先按月整体偏移再在月内保持起止日的偏移量或者干脆改成按自然月聚合对比放弃日级精度的环比。宁可口径粗一点也不要算出个自己都解释不清的数。4.4 时间分桶与滚动窗口分桶统计把时间归到天、周、月通常用DATEPART或DATEDIFF做截断但如果需要保留完整的日期类型DATEADD 加 DATEDIFF 的组合更合适-- 把时间戳归到所在周的周一保留 date 类型 SELECT DATEADD(week, DATEDIFF(week, 0, created_at), 0) AS week_bucket, COUNT(*) AS cnt FROM orders GROUP BY DATEADD(week, DATEDIFF(week, 0, created_at), 0) ORDER BY week_bucket;这个写法的可读性不算好但语义是干净的DATEDIFF把时间戳压扁成整数桶号DATEADD再把桶号还原成日期。它比CONVERT(varchar(10), created_at, 120)强的地方在于结果是真正的date类型能正常排序、能参与日期运算不会因为字符串排序在跨年时出错虽然yyyy-mm-dd格式的字符串排序恰好也是对的但这属于巧合不该依赖。滚动窗口比如过去 30 天每天的 7 日活跃更依赖 DATEADD 生成序列。在 SQL Server 里可以用递归 CTE 或GENERATE_SERIES2022 起支持造日期轴-- SQL Server 2022 WITH date_axis AS ( SELECT DATEADD(day, value, CAST(2024-01-01 AS date)) AS d FROM GENERATE_SERIES(0, 29) ) SELECT d FROM date_axis;老版本就得用递归 CTE 或者一张预置的日期维度表。我在数仓项目里一律推荐建一张日期维度表把年、季、月、周、是否工作日、是否节假日全部预先算好。这样做的好处是所有时间窗口查询变成简单的范围过滤不用现场算 DATEADD执行计划稳定还不会因为DATEFIRST、LANGUAGE这类会话设置导致结果漂移。这张表一次建好能用好几年。5. 性能与索引DATEADD 写错位置会让索引白建5.1 SARGable 原则必须先说清楚DATEADD 本身开销极小它真正影响性能的地方在于出现在 WHERE 的哪一侧。数据库的查询优化器只能对列 与 常量形式的条件做索引查找一旦列被函数包裹索引就退化成了全表扫描。-- 反例列被 DATEADD 包裹索引失效无法 SEEK SELECT * FROM orders WHERE DATEADD(day, 7, order_date) GETDATE(); -- 正例DATEADD 作用在常量侧索引正常走 SEEK SELECT * FROM orders WHERE order_date DATEADD(day, -7, GETDATE());这两条语句在业务上可以等价取决于边界是否严格但执行计划天差地别。第一句是把每一行的order_date都加 7 天再比较1000 万行就要算 1000 万次第二句是先算出常量阈值然后用索引定位。我在千万级订单表上实测过同一需求两种写法耗时能差出两个数量级。改写的方法很简单就是把函数从列上挪到常量上顺手改变不等号方向。规则是f(x) C改成x f⁻¹(C)前提是f是单调的。DATEADD 对固定的 datepart 是单调递增的所以可以直接移项。5.2 常见改写对照原始写法索引失效改写后可走索引WHERE DATEADD(day, 1, order_date) dWHERE order_date DATEADD(day, -1, d)WHERE DATEDIFF(day, order_date, GETDATE()) 30WHERE order_date DATEADD(day, -30, GETDATE())WHERE DATEADD(month, 1, due_date) todayWHERE due_date DATEADD(month, -1, today)WHERE CAST(order_date AS date) dWHERE order_date d AND order_date DATEADD(day, 1, d)最后一行特别值得说。CAST(列 AS date) d是报表里极其常见的写法它有两个问题一是索引失效二是它把时间精度丢掉了。改成左闭右开区间之后既能走索引语义也更严谨——d当天的所有记录都会被包含包括 23:59:59.999。5.3 大表上做时间分桶的正确姿势如果需要按天分组统计直接GROUP BY CAST(created_at AS date)会让索引完全用不上。更实际的做法是先用可索引的范围把数据筛到目标区间再做分桶SELECT CAST(created_at AS date) AS d, COUNT(*) AS cnt FROM orders WHERE created_at 2024-03-01 AND created_at 2024-04-01 -- 左闭右开边界用 DATEADD 算也行 GROUP BY CAST(created_at AS date) ORDER BY d;这里的过滤条件本身是范围比较能走索引把数据量砍下来后面的 CAST 只作用在剩下的行上代价可以接受。如果你的表大到索引范围扫描也很慢那就该考虑按时间分区了让分区裁剪来承担主要过滤工作这时候 DATEADD 的作用就只剩构造分区边界。提示判断一条语句有没有走索引别靠猜。看一眼执行计划里是不是出现了Index Seek如果显示Index Scan或者Table Scan基本就是列被函数包了或者隐式类型转换把索引废了。6. 跨数据库怎么改写 DATEADD6.1 五类数据库写法对照这块是迁移时最容易出问题的地方因为加一天这个动作在不同库里长得完全不一样。能力SQL ServerMySQLPostgreSQLOracleSQLite加 1 天DATEADD(day,1,d)DATE_ADD(d, INTERVAL 1 DAY)d INTERVAL 1 day或d 1d 1date(d,1 day)加 1 月DATEADD(month,1,d)DATE_ADD(d, INTERVAL 1 MONTH)d INTERVAL 1 monthADD_MONTHS(d,1)date(d,1 month)减 1 小时DATEADD(hour,-1,d)DATE_ADD(d, INTERVAL -1 HOUR)d - INTERVAL 1 hourd - 1/24datetime(d,-1 hour)加 1 季度DATEADD(quarter,1,d)DATE_ADD(d, INTERVAL 1 QUARTER)d INTERVAL 3 monthADD_MONTHS(d,3)date(d,3 month)当前时间SYSDATETIME()NOW()now()SYSDATEdatetime(now)几个要点MySQL 的DATE_ADD单位必须大写写在INTERVAL后面而且它和ADDDATE、DATE_SUB、SUBDATE是同一个家族DATE_SUB(d, INTERVAL 1 DAY)就等价于加负数。MySQL 还支持复合单位比如INTERVAL 1 2 DAY_HOUR表示 1 天 2 小时这是 SQL Server 没有的能力。PostgreSQL 没有 DATEADD全部靠interval字面量或整数加法。date 1是最快的加一天写法比 INTERVAL 1 day更直接因为前者结果还是date类型后者会变成timestamp。如果你的列是date但结果需要保持date用完 interval 记得再::date转回来。Oracle 里ADD_MONTHS是处理月粒度偏移的正牌函数行为和 DATEADD(month, ...) 一致月末自动对齐。但 Oracle 没有加小时的函数靠1/24、1/1440这类分数运算可读性差建议包一层自定义函数或者用INTERVAL字面量d INTERVAL 1 HOUR。SQLite 最有意思它把时间存成字符串所有运算靠date()、datetime()、strftime()的修饰符参数完成修饰符可以链式叠加datetime(d,1 month,start of month)。灵活但完全没有类型保护脏数据能一路带进结果里。6.2 迁移时的语义差异清单光把语法改对还不够语义上的差异才是埋雷的地方我列几个必查项月末行为。大部分库的月偏移都是目标月不存在该日则取月末包括 SQL Server、MySQL、Oracle。但如果你在 PostgreSQL 里对date用 INTERVAL 1 month结果会转成timestamp2024-01-31 00:00:00 interval 1 month得到2024-02-29 00:00:00行为一致但类型变了后续比较可能出问题。DATEFIRST 和周围起始日。SQL Server 的DATEPART(week, ...)结果受会话设置影响MySQL 的WEEK()默认周日为周首PostgreSQL 的date_trunc(week, ...)强制周一开始。跨库对比周数据时不统一周围定义会得到完全对不上的数字。空值处理。所有库的 DATEADD 传入 NULL 都返回 NULL这点是一致的。但 MySQL 在某些模式下对非法日期比如0000-00-00的处理跟别家完全不同迁移前要做一次全表数据体检。隐式转换。SQL Server 会愉快地把2024-01-01转成日期MySQL 在宽松模式下也可能容忍一堆奇奇怪怪的格式但 PostgreSQL 极其严格格式不对直接报错。这种在 A 库能跑在 B 库报错的情况是迁移中最耗时的部分。7. 排错实录DATEADD 报错与结果不对的常见原因7.1 报错速查表报错信息典型原因处理方式Adding a value to a datetime column caused an overflow结果超出 9999-12-31用哨兵值代替大偏移或在计算前判空判界Argument data type ... is invalid for argument 1 of dateadd functiondatepart 传了非法值比如拼错了检查是不是把minute拼成了min或者括号位置错了Conversion failed when converting date and/or time from character string第三个参数是非法字符串改用 ISO 8601 格式或显式 CASTMySQL 下Incorrect datetime value日期格式不合法或0被当成日期检查字符串格式别用0当基准日Arithmetic overflow error converting expression to data type intnumber 参数超出 int 范围拆成多次小偏移或改用大范围类型7.2 结果不对但没报错的排查顺序有些问题不报错结果就是错的这类最难查。我自己的排查顺序是固定的第一步确认基准日的类型。打印SQL_VARIANT_PROPERTY(base, BaseType)或者直接看SELECT base的输出精度。如果基准日是date那么加hour也没用时间部分永远是 00:00:00。这个坑我见过不止一次接口传进来的字段在表里是date业务方以为有时分秒加两小时之后发现毫无变化。第二步确认 datepart 拼写。单字母缩写是重灾区m/mi/ms三兄弟害人无数。快速自查的方法是把缩写全部换成全称跑一遍结果一致才说明没写错。第三步确认 number 的符号和量级。特别是从应用层传参的地方-1和1差一个方向参数校验缺失时很容易把往前推写成往后推。我习惯在存储过程里加一句防御IF days IS NULL OR days 0 OR days 3650 THROW 50001, 偏移量超出合理范围, 1;第四步确认时区和会话设置。GETDATE()返回的是服务器本地时间GETUTCDATE()返回 UTC。如果数据库服务器和应用服务器的时区不一致算出来的今天可能差一天。这个问题的隐蔽性极强因为它在白天大部分时间不会暴露只在跨零点的几个小时内咬人。我的做法是所有时间戳统一用 UTC 存储只在展示层转换从源头上消灭这个问题。7.3 几条我踩出来的经验关于跨零点的那笔账。有一次做日活统计用DATEADD(day, -1, GETDATE())作为昨天的起点结果每天早上 8 点前的报表数字总是比平时少一截。排查了半天才发现服务器是 UTC 时间而业务方的昨天是东八区的昨天两者差了 8 小时。后来统一改成先算本地日期边界再转 UTC报表就对上了。这件事之后我在所有涉及今天/昨天的地方都会加注释写明用的是什么时区。关于日期维度表的价值。前面提过这里再强调一次。我参与过的一个数仓项目早期所有时间窗口都是现场用 DATEADD 算的问题出了一堆周围定义不统一、节假日判断散落在十几个地方、换个数据库就得全部重写。后来统一改成日期维度表每个日期一行带年、季、月、周、工作日标记、节假日标记、上期对应日期等字段。之后所有查询都变成JOIN dim_date ON ... WHERE is_workday 1这种形式代码量下来了一致性也上来了。这张表的成本很低几百年的数据也就十几万行收益却贯穿整个项目生命周期。关于负偏移的边界。DATEADD(day, -1, 0001-01-01)在 SQL Server 里会直接溢出报错因为date类型的最小值是 0001-01-01。做前一天计算时如果数据里存在极早的哨兵日期比如用 0001-01-01 表示未知一定要先过滤掉再参与运算否则整条语句会因为一行脏数据直接挂掉。这种失败方式很讨厌因为它只在你最不希望出问题的时候出现。关于永久有效的表示。别用DATEADD(year, 100, GETDATE())。这个值会随时间漂移今天算出来是 2124 年明年就是 2125 年同一份数据在不同时间跑出不同结果对账时根本没法比。用一个固定的哨兵值9999-12-31语义清晰比较稳定还省一次函数调用。-- 到期判断的推荐写法 SELECT id, expire_at, CASE WHEN expire_at IS NULL OR expire_at 9999-12-31 THEN 永久 WHEN expire_at SYSDATETIME() THEN 有效 ELSE 已过期 END AS status FROM memberships;最后再分享一个小技巧关于边界区间的写法。所有时间范围查询我一律用左闭右开 start AND endend用DATEADD从start推出来而不是自己手写一个23:59:59。原因是datetime的精度只到 3.33 毫秒23:59:59.999会被舍入成第二天的00:00:00.000导致当天最后一秒的数据被排除在外。左闭右开从根上规避了这个问题还顺便让索引范围更干净。这个习惯坚持几年下来时间相关的线上问题少了一大半。
