先问一个问题：你编写的那套双倍余额递减法，基于WHILE循环实现，在实际运行中真的能稳定执行吗？很多人在MySQL或SQL Server中直接使用WHILE循环，结果发现：明明理论上24期刚好折旧完毕，偏偏最后一期还会剩下几分钱，永远无法清零。这不是你的代码写得不好，而是WHILE循环本身存在四个致命缺陷。
相比之下，采用递归CTE来实现双倍余额递减法或VDB这类分段折旧，比游标和WHILE循环要可靠得多。但也不是直接套用就能成功——手动处理切换点、残值兜底以及精度截断，这三个环节缺一不可，否则第23年的折旧额可能会被算成负数，到时候审计查账就麻烦了。
WHILE循环为什么总在最后一期翻车
举个例子，资产原值5000元，残值200元，折旧年限24期。按理论，第24期应该把剩余账面价值全部折旧完。但WHILE循环的判断条件如果只写了@book_value > @salvage，最后一步很可能算出当期折旧199.99元，剩下那0.01元永远卡在那里，循环无法终止。
WHILE还有几个隐藏问题：
- 迭代顺序天生与会计期间对不齐，特别是遇到跨年时，日期计算稍不留神就会错位
- 每次SET赋值都会触发隐式类型转换——
@book_value声明为DECIMAL(15,2)，但参与ROUND(@book_value * 2 / 24, 2)运算后，MySQL一高兴就把小数位截成一位了 - 想要实现VDB函数那种“某个期间内折旧”的任意起止区间？你得额外维护一个累计数组，这复杂度直接翻倍
递归CTE怎么安全落地VDB风格折旧
递归CTE的玩法不一样：核心思路是把“是否切换到直线法”这个逻辑拆成两层。先用CTE生成每期账面价值，外层再用SELECT按起始期间和结束期间切片求和。这么做的好处是逻辑清晰，但陷阱在于切换点判断必须用精确DECIMAL比较，千万别依赖FLOAT中间值。
几个必须注意的细节：
- 初始折旧率要显式CAST：
CAST(2 AS DECIMAL(5,2)) * @cost / @life，否则SQL Server把2当成INT，除法直接截断 - 切换条件的判断得两边都用相同精度的DECIMAL，不能一边是精确值另一边是浮点结果
- 最后一期强制兜底：
CASE WHEN @period = @life THEN @book_value - @salvage ELSE [computed_dep] END，确保残值不残留
精度断裂的链条：从函数声明开始就埋了雷
你辛辛苦苦写了个CREATE FUNCTION calc_vdb(...) RETURNS DECIMAL(15,2)，调用时随手写了SELECT calc_vdb(cost, salvage, life, 1, 12, 2, FALSE)。结果第7期开始漂移了？问题出在参数传入那瞬间，MySQL自动转成了DOUBLE——精度就这么断裂了。
要解决这个问题，输入参数声明必须带完整精度：IN cost DECIMAL(15,2), IN salvage DECIMAL(15,2)，不能偷懒只写DECIMAL。函数体内第一行就做校验：IF cost < 0 THEN SIGNAL ...。遇到POW()或LOG()这类函数时，立刻CAST一下：CAST(POW(1 + 0.05, @n) AS DECIMAL(18,6))，别等返回后再转。
SQL Server里的负底数幂：不是数据异常，是公式设计缺陷
POWER(-1000, 0.5)这种写法在T-SQL里直接返回NULL。VDB算法中有个“剩余年限倒数”的操作，残值设高一点，底数就可能变成负数。这看起来像数据异常，其实根源是公式设计本身的问题。
解决方法有两种：
- 手动拆解符号：用
EXP(0.5 * LOG(ABS(-1000))) * CASE WHEN -1000 < 0 THEN 1 ELSE -1 END - 更稳妥的方式是在CTE里直接加防护：用
ABS(@book_value - @salvage)作为直线法分子，单独判断@book_value < @salvage时提前退出 - 如果你用的SQL Server 2022以上版本，
TRY_POWER()是个不错的选择，失败时返回NULL而不是中断，配合COALESCE(..., 0)兜底
最后说一个最容易被忽略的细节：折旧期间单位的一致性。CTE里的[Month]字段如果只用了INT型月份序号，但业务要求按“天”算折旧（比如半年惯例），那生成序列时就得用DATEADD(day, n, @start_date)，不能简单+1。否则夏令时切换那天会少算8小时折旧——这个问题不会报错，只会让全年总额差个0.03元，够审计同事追查三天。
