SQL Server存储过程变量声明必须与目标字段精度严格一致，如目标为DECIMAL(12,2)，变量须声明为DECLARE @val DECIMAL(12,2)，否则链式计算易触发算术溢出；所有赋值、运算、类型转换均需显式CAST控制中间精度。
存储过程变量声明必须和目标字段精度完全一致
SQL Server 存储过程中，@param 或 @var 的类型定义不是“大概够用就行”，而是必须和最终要 INSERT/UPDATE 的目标列的 DECIMAL(p,s) 或 INT 等类型严格匹配。哪怕只差 1 位精度，链式计算中就可能触发 Arithmetic overflow error converting numeric to data type numeric。
- 目标字段是
DECIMAL(12,2)，变量就得声明为DECLARE @val DECIMAL(12,2)，不能写DECIMAL(18,6)或MONEY -
MONEY类型在除法中会隐式转成DECIMAL(19,4)，再存进DECIMAL(10,2)字段时必崩；FLOAT则有精度丢失风险，禁用 - 参数传入后别直接参与运算，先显式强转：
SET @val = CAST(@input AS DECIMAL(12,2))，而不是SET @val = @input / 100.0
SELECT INTO 或赋值时必须显式 CAST 源字段
从表里查出数据赋给变量，或用 SELECT @var = col FROM ...，如果 col 是 DECIMAL(20,6) 而 @var 是 DECIMAL(10,2)，SQL Server 不会在赋值前自动截断——它先按源类型算中间值，再尝试转换，溢出就发生在转换那一刻。
- 避免：
SELECT @amount = price FROM orders WHERE id = 1（price 是DECIMAL(19,4)） - 改为：
SELECT @amount = CAST(price AS DECIMAL(10,2)) FROM orders WHERE id = 1 - 批量赋值（如游标 FETCH）也适用：FETCH NEXT INTO @id,
CAST(@price AS DECIMAL(10,2))，但注意语法限制，更稳妥是 FETCH 后立刻 CAST
除法运算最容易暴露精度不匹配问题
/ 运算符是 SQL Server 隐式类型提升的重灾区。哪怕所有输入都是整数，只要分母带小数点，结果就会跳升到高精度 DECIMAL 类型，而这个中间类型往往远超目标字段容量。
-
SELECT 100 / 3→ 结果是INT（3）；但SELECT 100 / 3.0→DECIMAL(10,1)；SELECT @a / 100.0（@a 是INT）→DECIMAL(13,3)左右 - 不要用
100.0这类字面量，改用CAST(100 AS DECIMAL(12,2))控制分母类型 - 比例缩放优先用乘法：
@val * 0.01比@val / 100.0更可控，乘法精度推导更线性，不易层层叠加溢出
调试时必须查 TYPE_NAME 和 PRECISION，不能只看数值
值看起来正常，不代表类型安全。一个 99.99 显示没问题，但它背后可能是 DECIMAL(27,6)，一塞进 DECIMAL(10,2) 就崩。光 SELECT 值没用，得确认 SQL Server 实际生成的中间类型。
- 临时加一句：
SELECT TYPE_NAME(@val) AS tname, PRECISION(@val) AS prec, SCALE(@val) AS scale - 对表达式也有效：
SELECT TYPE_NAME(@a + @b), TYPE_NAME(@a / CAST(100 AS DECIMAL(12,2))) - 特别注意：
CONVERT和CAST返回的类型就是你指定的，但括号外再套运算（比如CAST(a+b AS DECIMAL(10,2)) * 1.0），后续又会重新推导类型
最常被忽略的是变量声明那行——很多人改完 INSERT 目标字段类型，却忘了同步改 DECLARE，导致源头就溢出。类型匹配不是“写完能跑通”就行，而是每一步中间结果都得落在预期精度内。
