DATEDIFF_BIG能解决毫秒级大跨度溢出，因其返回BIGINT（上限±922万亿），而DATEDIFF返回INT（上限约21亿），跨几十年毫秒差（如1900–2200年约9.4e12毫秒）远超INT容量，必报算术溢出错误。
为什么DATEDIFF_BIG能解决毫秒级大跨度溢出？
因为DATEDIFF返回INT，最大值约21亿，而跨几十年的毫秒差轻松突破3万亿（例如'1900-01-01'到'2200-01-01'约9.4e12毫秒），直接报Arithmetic overflow error converting expression to data type int。DATEDIFF_BIG返回BIGINT，上限±922万亿，足够覆盖公元元年到9999年的任意DATETIME2毫秒差。
哪些datepart和时间类型组合必须用DATEDIFF_BIG？
以下场景不换就必然溢出：
-
millisecond搭配跨度 > 24 天的DATETIME2或DATETIMEOFFSET（DATETIME因精度限制实际更早溢出） -
microsecond下，只要跨度超过约27.8小时（1e8微秒）就可能触INT上限 -
nanosecond几乎任何非瞬时差都会溢出——1秒 = 10⁹纳秒，远超INT容量 - 用
GETDATE()或SYSDATETIME()作起点、且业务要求计算“自系统上线以来毫秒数”这类长周期值
替换DATEDIFF时最容易踩的三个坑
函数名写错、参数没对齐、后续类型不兼容是高频问题：
- 必须写成
DATEDIFF_BIG（全大写或按SQL Server规范大小写），不是DATE_DIFF_BIG、DATEDIFF_BIG()（括号不能跟在函数名后） - 参数顺序和语义与
DATEDIFF完全一致：DATEDIFF_BIG(datepart, startdate, enddate)，不能颠倒startdate和enddate - 返回值是
BIGINT，如果插入到INT列、参与JOIN条件中的INT字段，或赋值给DECLARE @x INT变量，会触发隐式转换警告甚至截断——必须显式转换或确认目标类型支持BIGINT
时区与精度协同使用的注意事项
毫秒级时间戳若需UTC对齐，DATEDIFF_BIG本身不处理时区，必须配合AT TIME ZONE：
- 旧版本SQL Server（AT TIME ZONE，只能手动减去
GETUTCDATE() - GETDATE()估算偏移，误差可达分钟级 - 用
datetime2代替datetime——前者最小精度100纳秒，后者仅3.33毫秒，舍入误差在毫秒差计算中不可忽略 - 示例：安全获取Unix毫秒时间戳（UTC）
SELECT DATEDIFF_BIG(millisecond, '1970-01-01T00:00:00.000Z', SYSDATETIMEOFFSET() AT TIME ZONE 'UTC')
真正麻烦的是跨版本兼容性——DATEDIFF_BIG在SQL Server 2014及更早版本里根本不存在，报错Invalid column name 'DATEDIFF_BIG'。如果应用要跑在混合版本环境，得提前做版本检测或准备降级方案。
