SQL 里算两个日期差几天这事听起来简单到不值一提但我见过太多人在这上面翻车。有人用DATEDIFF算出来少了几个月有人跨年的时候天数直接变成负数还有人把字符串往日期函数里一塞数据库当场报错。问题不在于函数难用而在于不同数据库的日期函数压根不是一套东西——MySQL 的DATEDIFF只算日期部分SQL Server 的DATEDIFF要指定单位PostgreSQL 直接让你做减法Oracle 又玩起了MONTHS_BETWEEN。你要是拿着 MySQL 的写法去 SQL Server 跑结果能差出一天甚至报错。这篇内容就是把这个看似小儿科的需求彻底拆开讲清楚。我会按不同数据库分别给出可直接抄的写法解释每种写法背后的计算逻辑重点说清楚那些“差一天”“差一个月”“跨时区”的坑是怎么来的。适合刚入行的数据分析、后端开发、报表开发同学也适合那些写了几年 SQL 但一直靠试错来调日期函数的老手——看完你至少能明白为什么你算出来的天数总跟业务方对不上。1. 先搞清楚“差几天”到底在问什么1.1 日期差的三种语义选错了结果全错在动手写函数之前得先把需求翻译成精确的语义。业务方说“算两个日期差几天”这句话至少有三种完全不同的含义而不同的数据库函数默认回答的是不同的问题。第一种是自然日差也就是从 1 月 1 日到 1 月 3 日算 2 天不管中间有没有跨月跨年就是日历上数格子。这是最常见的需求考勤、账期、活动天数基本都用这个。第二种是时间跨度差比如从 1 月 1 日 23:00 到 1 月 2 日 01:00按自然日算是 1 天但实际只过了 2 小时如果按“整天数”算应该是 0 天。第三种是工作日差跳过周末和节假日这个就不是单纯日期函数能解决的了得配合日历表。我踩过最典型的一个坑某次做用户留存报表用 MySQL 的DATEDIFF(结束时间, 开始时间)算活跃天数结果用户当天 23:59 注册、次日 00:01 登录算出来是 1 天业务方看着数据说“这用户第二天就来了留存不错”但实际上人家就是连续操作了两分钟。后来改成按小时差再除以 24 取整才符合“完整天数”的口径。所以你在写任何日期差之前先问一句你要的是日历格子数还是经过的完整时间长度这两个答案在跨天场景下能差出整整一天。提示如果字段类型是DATETIME或TIMESTAMP而不是纯DATE默认行为往往带时间部分参与计算务必先确认函数是否会自动截断时间。1.2 为什么各数据库的写法不能通用SQL 标准里其实没有规定日期差函数长什么样所以各大数据库各玩各的。MySQL 的DATEDIFF(expr1, expr2)只接受日期部分返回expr1 - expr2的天数时间部分直接被忽略SQL Server 的DATEDIFF(unit, start, end)第一个参数是单位day、month、year都能填但它算的是“跨越了多少个单位的边界”这个语义很反直觉PostgreSQL 干脆不提供DATEDIFF让你直接date1 - date2得到整数天数时间戳相减则得到interval类型Oracle 用date1 - date2得到天数但带时间的话会得到小数。这种差异导致一个后果你在一个数据库上验证通过的 SQL换一个环境可能静默地返回错误结果而不是报错。静默错误比报错可怕得多因为报表跑出来了数字看着也像那么回事等到月底对账才发现全错了。我建议的做法是在任何跨库项目里把日期差逻辑封装成一个视图或者一层计算字段并且写一条断言测试用几个边界日期跨年、跨月、闰年 2 月 29 日验证结果这样迁移的时候能第一时间发现问题。数据库常用写法返回类型时间部分处理MySQLDATEDIFF(d1, d2)整数天忽略时间SQL ServerDATEDIFF(day, d1, d2)整数按边界跨越算PostgreSQLd1::date - d2::date整数天需显式转 dateOracled1 - d2数字可带小数保留时间差SQLitejulianday(d1) - julianday(d2)浮点天数保留时间差这张表建议你存下来下次换数据库的时候直接对照能省掉大量试错时间。2. 主流数据库的具体写法与参数拆解2.1 MySQLDATEDIFF 的边界与替代方案MySQL 的DATEDIFF(expr1, expr2)返回的是expr1 - expr2的天数注意参数顺序第一个减第二个。它只取日期部分2024-01-03 23:59:59和2024-01-01 00:00:01之间算出来是 2 天因为时间被抹掉了。这个行为在算账期、算活动天数时正好但在算“经过了多少个 24 小时”时就是错的。-- 自然日差最常用 SELECT DATEDIFF(2024-03-01, 2024-02-28) AS diff_days; -- 结果 22024 是闰年2 月有 29 天 -- 带时间的字段会被截断 SELECT DATEDIFF(2024-01-02 00:01:00, 2024-01-01 23:59:00) AS diff_days; -- 结果 1虽然实际只过了 2 分钟如果你要的是“完整经过的天数”得用TIMESTAMPDIFF它支持秒、分、小时、天、月、年等单位而且保留时间精度SELECT TIMESTAMPDIFF(DAY, 2024-01-01 23:59:00, 2024-01-02 00:01:00) AS full_days; -- 结果 0因为不足 24 小时这里有个细节值得说TIMESTAMPDIFF(DAY, ...)算的是完整天数不足一天的零头直接舍掉不是四舍五入。所以如果你要的是“向上取整”得自己加逻辑比如CEIL(TIMESTAMPDIFF(HOUR, a, b) / 24)。我见过有人直接用TIMESTAMPDIFF算租期结果 23 小时的租期算成 0 天被业务方追着问其实就是没搞清楚“完整天数”和“自然日”的区别。还有一个容易忽略的点MySQL 的DATEDIFF参数如果是字符串会尝试隐式转换但格式不对就返回NULL而不是报错。比如DATEDIFF(2024/01/01, 2024-01-02)在某些版本下会静默返回NULL报表里就出现一片空白。所以养成习惯字符串日期先STR_TO_DATE或者CAST(... AS DATE)转一下别指望隐式转换。2.2 SQL ServerDATEDIFF 的“边界跨越”语义SQL Server 的DATEDIFF(unit, start, end)是最容易让人误解的一个。它算的不是时间长度而是跨越了多少个单位的边界。举个例子DATEDIFF(day, 2024-01-01 23:59:59, 2024-01-02 00:00:01)返回 1因为跨过了 1 月 1 日到 1 月 2 日这个边界哪怕实际只过了 2 秒。同理DATEDIFF(year, 2023-12-31, 2024-01-01)返回 1虽然只差一天但跨年了。-- 跨天边界哪怕只差 2 秒也算 1 天 SELECT DATEDIFF(day, 2024-01-01 23:59:59, 2024-01-02 00:00:01) AS d; -- 结果 1 -- 跨年边界只差 1 天也算 1 年 SELECT DATEDIFF(year, 2023-12-31, 2024-01-01) AS y; -- 结果 1这个语义在做“账期跨越了几个自然月”这类需求时是对的但在算“经过了多少天”时就是错的。要算完整天数SQL Server 里得用DATEDIFF(day, ...)配合时间归零或者用DATEDIFF(second, ...) / 86400再取整。我一般推荐后者逻辑清晰不容易错-- 完整经过的天数向下取整 SELECT DATEDIFF(second, start, end) / 86400 AS full_days;注意整数除法在 SQL Server 里是截断的正好符合“完整天数”的语义。如果你要向上取整加个CEILING或者用(DATEDIFF(second, start, end) 86399) / 86400。注意SQL Server 的DATEDIFF在单位是month或year时边界语义带来的偏差更大。比如DATEDIFF(month, 2024-01-31, 2024-02-01)返回 1虽然只差一天但跨月了。做月数统计时务必想清楚这是不是你要的口径。2.3 PostgreSQL直接减法最干净PostgreSQL 没有DATEDIFF函数但它的日期减法设计得很干净。两个date类型相减直接得到整数天数两个timestamp相减得到interval你可以从interval里提取天数-- date 相减直接得整数 SELECT 2024-03-01::date - 2024-02-28::date AS diff_days; -- 结果 2 -- timestamp 相减得 interval再取天数 SELECT EXTRACT(DAY FROM 2024-01-02 00:01:00::timestamp - 2024-01-01 23:59:00::timestamp) AS days; -- 结果 0interval 是 2 分钟天数部分为 0这里有个坑EXTRACT(DAY FROM interval)取的是 interval 里的“天”字段不是总天数。如果 interval 是1 day 05:00:00EXTRACT(DAY ...)返回 1但如果你想要的是“总共经过了多少个完整天”得用EXTRACT(EPOCH FROM interval) / 86400再取整。EPOCH把 interval 转成总秒数这个才是可靠的总量口径SELECT FLOOR(EXTRACT(EPOCH FROM (2024-01-03 12:00:00::timestamp - 2024-01-01 00:00:00::timestamp)) / 86400) AS full_days; -- 结果 2PostgreSQL 还有个AGE函数返回的是“几年几个月几天”这种人类可读的 interval适合做展示不适合做数值计算。我见过有人拿AGE的结果去EXTRACT(DAY ...)结果跨月的场景下天数部分被“借位”了算出来的数字完全不对。记住一条要做数值运算就用减法加 EPOCH要做展示才用 AGE。2.4 Oracle 与 SQLite小数天数与儒略日Oracle 里两个DATE相减得到的是天数但如果带时间部分结果是带小数的。比如TO_DATE(2024-01-02 12:00, YYYY-MM-DD HH24:MI) - TO_DATE(2024-01-01 00:00, ...)得到 1.5。要整数天就TRUNC一下SELECT TRUNC(TO_DATE(2024-01-02 12:00, YYYY-MM-DD HH24:MI) - TO_DATE(2024-01-01 00:00, YYYY-MM-DD HH24:MI)) AS diff_days FROM dual; -- 结果 1Oracle 还有个MONTHS_BETWEEN返回带小数的月数算天数的话不推荐用容易在月末日期上出偏差。SQLite 没有原生日期类型日期存成文本或数字算差值得用julianday转成儒略日再相减结果是浮点天数SELECT julianday(2024-03-01) - julianday(2024-02-28) AS diff_days; -- 结果 2.0SQLite 的julianday对格式要求比较宽松但正因为宽松格式不规范时可能返回NULL。移动端或嵌入式场景用 SQLite 的话建议日期统一存成YYYY-MM-DD文本格式别存时间戳数字否则跨时区转换又是一堆事。3. 实操从需求到可复现的完整方案3.1 一个真实报表场景的完整拆解假设业务方要一张“订单履约天数”报表字段有下单时间order_time和发货时间ship_time要算“发货用了几天”。这个需求听起来简单但拆开至少有四个决策点用自然日还是完整天数时间部分要不要参与跨时区怎么处理空值怎么算我的处理流程是这样的。第一步确认口径业务方要的是“下单当天发货算 0 天次日发货算 1 天”这就是自然日差用日期部分相减。第二步确认字段类型order_time是DATETIME得先转DATE。第三步处理空值未发货的订单ship_time是NULL日期差返回NULL报表里要显示成“未发货”而不是空白。第四步做边界测试拿跨年、跨月、闰日的样本数据跑一遍确认结果符合预期。以 MySQL 为例完整写法SELECT order_id, order_time, ship_time, CASE WHEN ship_time IS NULL THEN NULL ELSE DATEDIFF(DATE(ship_time), DATE(order_time)) END AS fulfill_days FROM orders WHERE order_time 2024-01-01;这里DATE()显式截断时间避免依赖隐式转换。CASE处理空值让报表层能区分“0 天”和“未发货”。这个写法我用了很多次实测下来最稳不会因为字段类型变动或者数据库版本升级出幺蛾子。3.2 参数计算为什么除以 86400 而不是别的前面提到用秒差除以 86400 算完整天数这个 86400 是 24 小时 × 60 分 × 60 秒得来的。为什么要绕这么大一圈因为很多数据库的“天”单位函数要么带边界语义SQL Server要么截断时间MySQLDATEDIFF只有秒是最小粒度、最不容易有歧义的单位。用秒差做除法你能精确控制取整方向也能随时改成小时、分钟口径扩展性好。具体计算过程假设start 2024-01-01 08:00:00end 2024-01-03 07:00:00秒差是(2 天 × 86400) - 3600 169200秒除以 86400 得 1.958向下取整是 1 天。这个结果符合“完整经过 1 天”的语义因为从 1 号 8 点到 3 号 7 点确实只完整经过了 1 个 24 小时周期1 号 8 点到 2 号 8 点剩下的 23 小时不足一天。如果你要向上取整CEILING(169200 / 86400)得 2语义就变成“占用了几个日历天”两种口径各有用途关键是跟业务方对齐。提示除以 86400 时注意整数除法和小数除法的区别。MySQL 里/是小数除法DIV是整数除法SQL Server 里两个整数相除是截断的。写的时候显式用FLOOR或CAST包一层别依赖默认行为。3.3 跨时区场景的处理思路如果两个时间字段存的是不同时区的时间直接相减会得到错误的天数。比如start存的是东八区的2024-01-01 23:00end存的是 UTC 的2024-01-02 01:00实际是同一时刻但直接减会算出 1 天。处理思路是先统一转成 UTC 或者同一个基准时区再做差。MySQL 里可以用CONVERT_TZPostgreSQL 用AT TIME ZONESQL Server 用AT TIME ZONE子句。以 PostgreSQL 为例SELECT (2024-01-02 01:00:0000::timestamptz AT TIME ZONE UTC) - (2024-01-01 23:00:0008::timestamptz AT TIME ZONE UTC) AS diff;不过说实话跨时区的日期差需求我更推荐在数据入库时就统一存 UTC展示层再转本地时区。这样所有计算逻辑都基于 UTC不会出现“同一个报表在不同地区跑出不同数字”的问题。这个原则我在多个项目里验证过能省掉大量对账纠纷。4. 常见问题与排查技巧实录4.1 差一天问题的五种成因速查“算出来差一天”是日期差需求里最高频的投诉成因至少有五种我整理成速查表遇到问题按顺序排查现象可能成因排查方法解决方式结果比预期少 1时间部分被截断检查字段是否带时间改用秒差除法结果比预期多 1边界跨越语义确认函数是否按边界算换完整天数口径跨年时结果异常年份边界被计入用跨年样本测试统一用日期差闰年 2 月 29 日偏差月份计算借位用闰年样本测试避免用月差推天差结果时正时负参数顺序反了检查函数参数顺序统一“后减前”这张表里最隐蔽的是“闰年借位”。比如用MONTHS_BETWEEN算天数2 月 29 日到 3 月 1 日可能算出 0.03 个月再乘 30 得 0.9 天取整后变成 0 天实际应该是 1 天。所以我的原则是算天数就用天粒度函数别用月差或年差去换算换算过程必然引入精度损失。4.2 空值、非法日期与格式陷阱空值处理前面提过用CASE或者COALESCE兜底。非法日期更麻烦因为不同数据库的容错策略不一样。MySQL 在严格模式下插入非法日期会报错非严格模式下会存成0000-00-00这个值参与日期差计算会返回NULL或者奇怪的结果。SQL Server 遇到非法字符串直接报转换错误。PostgreSQL 最严格格式不对直接拒绝。我的做法是在 ETL 层做数据清洗日期字段入库前统一校验格式非法值打标记而不是硬塞。查询层再用TRY_CASTSQL Server或STR_TO_DATE配合NULLIFMySQL做二次防护。格式陷阱主要是分隔符混用2024-01-01和2024/01/01混在一起隐式转换时好时坏统一成 ISO 格式YYYY-MM-DD最省心。4.3 性能考量函数包裹字段导致索引失效最后一个容易被忽略的点是性能。如果你写WHERE DATEDIFF(day, order_time, ship_time) 7order_time上的索引大概率用不上因为函数包裹了字段数据库没法直接用索引定位。数据量小的时候无所谓上百万行就能明显感觉到慢。优化思路是把计算挪到SELECT列表里WHERE条件用原始字段做范围过滤或者建一个计算列/生成列并加索引。比如 MySQL 8.0 支持生成列ALTER TABLE orders ADD COLUMN fulfill_days INT GENERATED ALWAYS AS (DATEDIFF(DATE(ship_time), DATE(order_time))) STORED, ADD INDEX idx_fulfill_days (fulfill_days);这样查询WHERE fulfill_days 7就能走索引。不过生成列会增加写入开销得根据读写比例权衡。我一般是在报表库或者只读副本上做这种优化主库保持精简。我个人在实际操作中的体会是日期差这种需求难点从来不在函数本身而在于把业务口径翻译成精确的技术语义。每次动手前多问一句“你要的是日历天数还是完整时长”能省掉后面 80% 的返工。另外任何日期逻辑上线前拿跨年、跨月、闰日、空值四类样本各跑一遍这个习惯帮我拦下过好几次静默错误。最后分享一个小技巧把常用的日期差写法封装成数据库视图或者应用层的工具函数团队里统一调用比每个人各写各的靠谱得多。
SQL 里算两个日期差几天这事听起来简单到不值一提但我见过太多人在这上面翻车。有人用DATEDIFF算出来少了几个月有人跨年的时候天数直接变成负数还有人把字符串往日期函数里一塞数据库当场报错。问题不在于函数难用而在于不同数据库的日期函数压根不是一套东西——MySQL 的DATEDIFF只算日期部分SQL Server 的DATEDIFF要指定单位PostgreSQL 直接让你做减法Oracle 又玩起了MONTHS_BETWEEN。你要是拿着 MySQL 的写法去 SQL Server 跑结果能差出一天甚至报错。这篇内容就是把这个看似小儿科的需求彻底拆开讲清楚。我会按不同数据库分别给出可直接抄的写法解释每种写法背后的计算逻辑重点说清楚那些“差一天”“差一个月”“跨时区”的坑是怎么来的。适合刚入行的数据分析、后端开发、报表开发同学也适合那些写了几年 SQL 但一直靠试错来调日期函数的老手——看完你至少能明白为什么你算出来的天数总跟业务方对不上。1. 先搞清楚“差几天”到底在问什么1.1 日期差的三种语义选错了结果全错在动手写函数之前得先把需求翻译成精确的语义。业务方说“算两个日期差几天”这句话至少有三种完全不同的含义而不同的数据库函数默认回答的是不同的问题。第一种是自然日差也就是从 1 月 1 日到 1 月 3 日算 2 天不管中间有没有跨月跨年就是日历上数格子。这是最常见的需求考勤、账期、活动天数基本都用这个。第二种是时间跨度差比如从 1 月 1 日 23:00 到 1 月 2 日 01:00按自然日算是 1 天但实际只过了 2 小时如果按“整天数”算应该是 0 天。第三种是工作日差跳过周末和节假日这个就不是单纯日期函数能解决的了得配合日历表。我踩过最典型的一个坑某次做用户留存报表用 MySQL 的DATEDIFF(结束时间, 开始时间)算活跃天数结果用户当天 23:59 注册、次日 00:01 登录算出来是 1 天业务方看着数据说“这用户第二天就来了留存不错”但实际上人家就是连续操作了两分钟。后来改成按小时差再除以 24 取整才符合“完整天数”的口径。所以你在写任何日期差之前先问一句你要的是日历格子数还是经过的完整时间长度这两个答案在跨天场景下能差出整整一天。提示如果字段类型是DATETIME或TIMESTAMP而不是纯DATE默认行为往往带时间部分参与计算务必先确认函数是否会自动截断时间。1.2 为什么各数据库的写法不能通用SQL 标准里其实没有规定日期差函数长什么样所以各大数据库各玩各的。MySQL 的DATEDIFF(expr1, expr2)只接受日期部分返回expr1 - expr2的天数时间部分直接被忽略SQL Server 的DATEDIFF(unit, start, end)第一个参数是单位day、month、year都能填但它算的是“跨越了多少个单位的边界”这个语义很反直觉PostgreSQL 干脆不提供DATEDIFF让你直接date1 - date2得到整数天数时间戳相减则得到interval类型Oracle 用date1 - date2得到天数但带时间的话会得到小数。这种差异导致一个后果你在一个数据库上验证通过的 SQL换一个环境可能静默地返回错误结果而不是报错。静默错误比报错可怕得多因为报表跑出来了数字看着也像那么回事等到月底对账才发现全错了。我建议的做法是在任何跨库项目里把日期差逻辑封装成一个视图或者一层计算字段并且写一条断言测试用几个边界日期跨年、跨月、闰年 2 月 29 日验证结果这样迁移的时候能第一时间发现问题。数据库常用写法返回类型时间部分处理MySQLDATEDIFF(d1, d2)整数天忽略时间SQL ServerDATEDIFF(day, d1, d2)整数按边界跨越算PostgreSQLd1::date - d2::date整数天需显式转 dateOracled1 - d2数字可带小数保留时间差SQLitejulianday(d1) - julianday(d2)浮点天数保留时间差这张表建议你存下来下次换数据库的时候直接对照能省掉大量试错时间。2. 主流数据库的具体写法与参数拆解2.1 MySQLDATEDIFF 的边界与替代方案MySQL 的DATEDIFF(expr1, expr2)返回的是expr1 - expr2的天数注意参数顺序第一个减第二个。它只取日期部分2024-01-03 23:59:59和2024-01-01 00:00:01之间算出来是 2 天因为时间被抹掉了。这个行为在算账期、算活动天数时正好但在算“经过了多少个 24 小时”时就是错的。-- 自然日差最常用 SELECT DATEDIFF(2024-03-01, 2024-02-28) AS diff_days; -- 结果 22024 是闰年2 月有 29 天 -- 带时间的字段会被截断 SELECT DATEDIFF(2024-01-02 00:01:00, 2024-01-01 23:59:00) AS diff_days; -- 结果 1虽然实际只过了 2 分钟如果你要的是“完整经过的天数”得用TIMESTAMPDIFF它支持秒、分、小时、天、月、年等单位而且保留时间精度SELECT TIMESTAMPDIFF(DAY, 2024-01-01 23:59:00, 2024-01-02 00:01:00) AS full_days; -- 结果 0因为不足 24 小时这里有个细节值得说TIMESTAMPDIFF(DAY, ...)算的是完整天数不足一天的零头直接舍掉不是四舍五入。所以如果你要的是“向上取整”得自己加逻辑比如CEIL(TIMESTAMPDIFF(HOUR, a, b) / 24)。我见过有人直接用TIMESTAMPDIFF算租期结果 23 小时的租期算成 0 天被业务方追着问其实就是没搞清楚“完整天数”和“自然日”的区别。还有一个容易忽略的点MySQL 的DATEDIFF参数如果是字符串会尝试隐式转换但格式不对就返回NULL而不是报错。比如DATEDIFF(2024/01/01, 2024-01-02)在某些版本下会静默返回NULL报表里就出现一片空白。所以养成习惯字符串日期先STR_TO_DATE或者CAST(... AS DATE)转一下别指望隐式转换。2.2 SQL ServerDATEDIFF 的“边界跨越”语义SQL Server 的DATEDIFF(unit, start, end)是最容易让人误解的一个。它算的不是时间长度而是跨越了多少个单位的边界。举个例子DATEDIFF(day, 2024-01-01 23:59:59, 2024-01-02 00:00:01)返回 1因为跨过了 1 月 1 日到 1 月 2 日这个边界哪怕实际只过了 2 秒。同理DATEDIFF(year, 2023-12-31, 2024-01-01)返回 1虽然只差一天但跨年了。-- 跨天边界哪怕只差 2 秒也算 1 天 SELECT DATEDIFF(day, 2024-01-01 23:59:59, 2024-01-02 00:00:01) AS d; -- 结果 1 -- 跨年边界只差 1 天也算 1 年 SELECT DATEDIFF(year, 2023-12-31, 2024-01-01) AS y; -- 结果 1这个语义在做“账期跨越了几个自然月”这类需求时是对的但在算“经过了多少天”时就是错的。要算完整天数SQL Server 里得用DATEDIFF(day, ...)配合时间归零或者用DATEDIFF(second, ...) / 86400再取整。我一般推荐后者逻辑清晰不容易错-- 完整经过的天数向下取整 SELECT DATEDIFF(second, start, end) / 86400 AS full_days;注意整数除法在 SQL Server 里是截断的正好符合“完整天数”的语义。如果你要向上取整加个CEILING或者用(DATEDIFF(second, start, end) 86399) / 86400。注意SQL Server 的DATEDIFF在单位是month或year时边界语义带来的偏差更大。比如DATEDIFF(month, 2024-01-31, 2024-02-01)返回 1虽然只差一天但跨月了。做月数统计时务必想清楚这是不是你要的口径。2.3 PostgreSQL直接减法最干净PostgreSQL 没有DATEDIFF函数但它的日期减法设计得很干净。两个date类型相减直接得到整数天数两个timestamp相减得到interval你可以从interval里提取天数-- date 相减直接得整数 SELECT 2024-03-01::date - 2024-02-28::date AS diff_days; -- 结果 2 -- timestamp 相减得 interval再取天数 SELECT EXTRACT(DAY FROM 2024-01-02 00:01:00::timestamp - 2024-01-01 23:59:00::timestamp) AS days; -- 结果 0interval 是 2 分钟天数部分为 0这里有个坑EXTRACT(DAY FROM interval)取的是 interval 里的“天”字段不是总天数。如果 interval 是1 day 05:00:00EXTRACT(DAY ...)返回 1但如果你想要的是“总共经过了多少个完整天”得用EXTRACT(EPOCH FROM interval) / 86400再取整。EPOCH把 interval 转成总秒数这个才是可靠的总量口径SELECT FLOOR(EXTRACT(EPOCH FROM (2024-01-03 12:00:00::timestamp - 2024-01-01 00:00:00::timestamp)) / 86400) AS full_days; -- 结果 2PostgreSQL 还有个AGE函数返回的是“几年几个月几天”这种人类可读的 interval适合做展示不适合做数值计算。我见过有人拿AGE的结果去EXTRACT(DAY ...)结果跨月的场景下天数部分被“借位”了算出来的数字完全不对。记住一条要做数值运算就用减法加 EPOCH要做展示才用 AGE。2.4 Oracle 与 SQLite小数天数与儒略日Oracle 里两个DATE相减得到的是天数但如果带时间部分结果是带小数的。比如TO_DATE(2024-01-02 12:00, YYYY-MM-DD HH24:MI) - TO_DATE(2024-01-01 00:00, ...)得到 1.5。要整数天就TRUNC一下SELECT TRUNC(TO_DATE(2024-01-02 12:00, YYYY-MM-DD HH24:MI) - TO_DATE(2024-01-01 00:00, YYYY-MM-DD HH24:MI)) AS diff_days FROM dual; -- 结果 1Oracle 还有个MONTHS_BETWEEN返回带小数的月数算天数的话不推荐用容易在月末日期上出偏差。SQLite 没有原生日期类型日期存成文本或数字算差值得用julianday转成儒略日再相减结果是浮点天数SELECT julianday(2024-03-01) - julianday(2024-02-28) AS diff_days; -- 结果 2.0SQLite 的julianday对格式要求比较宽松但正因为宽松格式不规范时可能返回NULL。移动端或嵌入式场景用 SQLite 的话建议日期统一存成YYYY-MM-DD文本格式别存时间戳数字否则跨时区转换又是一堆事。3. 实操从需求到可复现的完整方案3.1 一个真实报表场景的完整拆解假设业务方要一张“订单履约天数”报表字段有下单时间order_time和发货时间ship_time要算“发货用了几天”。这个需求听起来简单但拆开至少有四个决策点用自然日还是完整天数时间部分要不要参与跨时区怎么处理空值怎么算我的处理流程是这样的。第一步确认口径业务方要的是“下单当天发货算 0 天次日发货算 1 天”这就是自然日差用日期部分相减。第二步确认字段类型order_time是DATETIME得先转DATE。第三步处理空值未发货的订单ship_time是NULL日期差返回NULL报表里要显示成“未发货”而不是空白。第四步做边界测试拿跨年、跨月、闰日的样本数据跑一遍确认结果符合预期。以 MySQL 为例完整写法SELECT order_id, order_time, ship_time, CASE WHEN ship_time IS NULL THEN NULL ELSE DATEDIFF(DATE(ship_time), DATE(order_time)) END AS fulfill_days FROM orders WHERE order_time 2024-01-01;这里DATE()显式截断时间避免依赖隐式转换。CASE处理空值让报表层能区分“0 天”和“未发货”。这个写法我用了很多次实测下来最稳不会因为字段类型变动或者数据库版本升级出幺蛾子。3.2 参数计算为什么除以 86400 而不是别的前面提到用秒差除以 86400 算完整天数这个 86400 是 24 小时 × 60 分 × 60 秒得来的。为什么要绕这么大一圈因为很多数据库的“天”单位函数要么带边界语义SQL Server要么截断时间MySQLDATEDIFF只有秒是最小粒度、最不容易有歧义的单位。用秒差做除法你能精确控制取整方向也能随时改成小时、分钟口径扩展性好。具体计算过程假设start 2024-01-01 08:00:00end 2024-01-03 07:00:00秒差是(2 天 × 86400) - 3600 169200秒除以 86400 得 1.958向下取整是 1 天。这个结果符合“完整经过 1 天”的语义因为从 1 号 8 点到 3 号 7 点确实只完整经过了 1 个 24 小时周期1 号 8 点到 2 号 8 点剩下的 23 小时不足一天。如果你要向上取整CEILING(169200 / 86400)得 2语义就变成“占用了几个日历天”两种口径各有用途关键是跟业务方对齐。提示除以 86400 时注意整数除法和小数除法的区别。MySQL 里/是小数除法DIV是整数除法SQL Server 里两个整数相除是截断的。写的时候显式用FLOOR或CAST包一层别依赖默认行为。3.3 跨时区场景的处理思路如果两个时间字段存的是不同时区的时间直接相减会得到错误的天数。比如start存的是东八区的2024-01-01 23:00end存的是 UTC 的2024-01-02 01:00实际是同一时刻但直接减会算出 1 天。处理思路是先统一转成 UTC 或者同一个基准时区再做差。MySQL 里可以用CONVERT_TZPostgreSQL 用AT TIME ZONESQL Server 用AT TIME ZONE子句。以 PostgreSQL 为例SELECT (2024-01-02 01:00:0000::timestamptz AT TIME ZONE UTC) - (2024-01-01 23:00:0008::timestamptz AT TIME ZONE UTC) AS diff;不过说实话跨时区的日期差需求我更推荐在数据入库时就统一存 UTC展示层再转本地时区。这样所有计算逻辑都基于 UTC不会出现“同一个报表在不同地区跑出不同数字”的问题。这个原则我在多个项目里验证过能省掉大量对账纠纷。4. 常见问题与排查技巧实录4.1 差一天问题的五种成因速查“算出来差一天”是日期差需求里最高频的投诉成因至少有五种我整理成速查表遇到问题按顺序排查现象可能成因排查方法解决方式结果比预期少 1时间部分被截断检查字段是否带时间改用秒差除法结果比预期多 1边界跨越语义确认函数是否按边界算换完整天数口径跨年时结果异常年份边界被计入用跨年样本测试统一用日期差闰年 2 月 29 日偏差月份计算借位用闰年样本测试避免用月差推天差结果时正时负参数顺序反了检查函数参数顺序统一“后减前”这张表里最隐蔽的是“闰年借位”。比如用MONTHS_BETWEEN算天数2 月 29 日到 3 月 1 日可能算出 0.03 个月再乘 30 得 0.9 天取整后变成 0 天实际应该是 1 天。所以我的原则是算天数就用天粒度函数别用月差或年差去换算换算过程必然引入精度损失。4.2 空值、非法日期与格式陷阱空值处理前面提过用CASE或者COALESCE兜底。非法日期更麻烦因为不同数据库的容错策略不一样。MySQL 在严格模式下插入非法日期会报错非严格模式下会存成0000-00-00这个值参与日期差计算会返回NULL或者奇怪的结果。SQL Server 遇到非法字符串直接报转换错误。PostgreSQL 最严格格式不对直接拒绝。我的做法是在 ETL 层做数据清洗日期字段入库前统一校验格式非法值打标记而不是硬塞。查询层再用TRY_CASTSQL Server或STR_TO_DATE配合NULLIFMySQL做二次防护。格式陷阱主要是分隔符混用2024-01-01和2024/01/01混在一起隐式转换时好时坏统一成 ISO 格式YYYY-MM-DD最省心。4.3 性能考量函数包裹字段导致索引失效最后一个容易被忽略的点是性能。如果你写WHERE DATEDIFF(day, order_time, ship_time) 7order_time上的索引大概率用不上因为函数包裹了字段数据库没法直接用索引定位。数据量小的时候无所谓上百万行就能明显感觉到慢。优化思路是把计算挪到SELECT列表里WHERE条件用原始字段做范围过滤或者建一个计算列/生成列并加索引。比如 MySQL 8.0 支持生成列ALTER TABLE orders ADD COLUMN fulfill_days INT GENERATED ALWAYS AS (DATEDIFF(DATE(ship_time), DATE(order_time))) STORED, ADD INDEX idx_fulfill_days (fulfill_days);这样查询WHERE fulfill_days 7就能走索引。不过生成列会增加写入开销得根据读写比例权衡。我一般是在报表库或者只读副本上做这种优化主库保持精简。我个人在实际操作中的体会是日期差这种需求难点从来不在函数本身而在于把业务口径翻译成精确的技术语义。每次动手前多问一句“你要的是日历天数还是完整时长”能省掉后面 80% 的返工。另外任何日期逻辑上线前拿跨年、跨月、闰日、空值四类样本各跑一遍这个习惯帮我拦下过好几次静默错误。最后分享一个小技巧把常用的日期差写法封装成数据库视图或者应用层的工具函数团队里统一调用比每个人各写各的靠谱得多。
