双倍余额递减法不能直接用WHILE循环可靠实现，因其收敛判定松散易致多算一期、隐式类型转换引发精度丢失、无法天然对齐会计期间、不支持任意起止区间折旧计算，且难以精准处理切换点与残值兜底。
直接用递归CTE实现双倍余额递减法或VDB类分段折旧，比写游标或WHILE循环更可靠；但必须手动处理切换点、残值兜底和精度截断，否则第23年折旧额可能变成负数。
为什么不能直接用WHILE循环实现双倍余额递减法
WHILE在MySQL或SQL Server里容易因收敛判定松散导致多算一期——比如资产原值5000、残值200、年限24，理论应在第24期把剩余账面价值全折完，但WHILE若只判断@book_value > @salvage，最后一步可能算出@dep = 199.99，剩下0.01永远无法清零。
- WHILE不保证迭代顺序与会计期间对齐，尤其跨年时日期计算易错
- 每次SET赋值都触发隐式类型转换，
@book_value DECIMAL(15,2)参与ROUND(@book_value * 2 / 24, 2)后，小数位可能被MySQL自动截断为1位 - 无法天然支持“某期间内折旧”这种VDB函数要求的任意起止区间，得额外维护累计数组
递归CTE怎么安全实现VDB风格折旧
核心是把“是否切换到直线法”这个逻辑拆成两层：先用CTE生成每期账面价值，再用外层SELECT按start_period/end_period切片求和。关键陷阱在于切换点判断必须用精确DECIMAL比较，不能依赖FLOAT中间值。
- 初始折旧率必须显式CAST：
CAST(2 AS DECIMAL(5,2)) * @cost / @life，避免SQL Server把2当INT导致除法截断 - 切换条件不是“余额递减值 ROUND((@book_value - @salvage) / (@life - @period), 2) > ROUND(@book_value * @factor / @life, 2)，且两边都用相同精度DECIMAL
- 最后一期强制兜底：
CASE WHEN @period = @life THEN @book_value - @salvage ELSE [computed_dep] END，防止残值残留
MySQL存储过程调用折旧函数时的精度链断裂
你写了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 - 涉及
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 手动拆解符号 - 但更稳妥的是在CTE里加防护：
ABS(@book_value - @salvage)作为直线法分子，再单独判断@book_value 提前退出 - SQL Server 2022+可用
TRY_POWER()替代POWER()，失败时返回NULL而非中断，配合COALESCE(..., 0)兜底
最易被忽略的是折旧期间单位一致性：CTE里的[Month]字段如果是INT型月份序号，但业务要求按“天”折旧（如半年惯例），就必须在生成序列时用DATEADD(day, n, @start_date)而非简单+1，否则夏令时切换日会少算8小时折旧。这问题不会报错，只会让全年总额差0.03元——够审计追查三天。
