web-dev-qa-db-ja.com

10 ^ 37/1が算術オーバーフローエラーをスローするのはなぜですか？

私の最近の傾向 大きな数字で遊ぶ を続けて、私は最近発生したエラーを次のコードに沸騰させました：

DECLARE @big_number DECIMAL(38,0) = '1' + REPLICATE(0, 37);

PRINT @big_number + 1;
PRINT @big_number - 1;
PRINT @big_number * 1;
PRINT @big_number / 1;

このコードの出力は次のとおりです。

10000000000000000000000000000000000001
9999999999999999999999999999999999999
10000000000000000000000000000000000000
Msg 8115, Level 16, State 2, Line 6
Arithmetic overflow error converting expression to data type numeric.

何ですか？

最初の3つの操作は機能するが最後は機能しないのはなぜですか？そして、@big_numberが明らかに@big_number / 1の出力を格納できる場合、算術オーバーフローエラーが発生する可能性がありますか？

sql-serversql-server-2008datatypes
11
Nick Chammas

算術演算のコンテキストでの精度とスケールの理解

これを分解して、除算の詳細を詳しく見てみましょう 算術演算子 。これは、MSDNが 除算演算子 の結果タイプについて述べなければならないことです。

結果のタイプ

優先順位の高い引数のデータ型を返します。詳細については、「 データ型の優先順位（Transact-SQL） 」を参照してください。

整数被除数が整数除数で除算された場合、結果は、結果の小数部が切り捨てられた整数になります。

_@big_number_はDECIMALです。 SQL Serverは_1_をどのデータ型にキャストしますか？それをINTにキャストします。 SQL_VARIANT_PROPERTY() を使用してこれを確認できます。

_SELECT
      SQL_VARIANT_PROPERTY(1, 'BaseType')   AS [BaseType]  -- int
    , SQL_VARIANT_PROPERTY(1, 'Precision')  AS [Precision] -- 10
    , SQL_VARIANT_PROPERTY(1, 'Scale')      AS [Scale]     -- 0
;
_

キックの場合、元のコードブロックの_1_を_DECLARE @one INT = 1;_のような明示的に入力された値に置き換えて、同じ結果が得られることを確認することもできます。

したがって、DECIMALとINTがあります。 DECIMALはINTよりも データタイプの優先順位 が高いため、除算の出力はDECIMALにキャストされることがわかります。

では、問題はどこにあるのでしょうか？

問題は、出力のDECIMALのスケールにあります。 SQL Serverが算術演算から取得した 結果の精度とスケール をどのように決定するかについてのルールの表を次に示します。

_Operation                              Result precision                       Result scale *
-------------------------------------------------------------------------------------------------
e1 + e2                                max(s1, s2) + max(p1-s1, p2-s2) + 1    max(s1, s2)
e1 - e2                                max(s1, s2) + max(p1-s1, p2-s2) + 1    max(s1, s2)
e1 * e2                                p1 + p2 + 1                            s1 + s2
e1 / e2                                p1 - s1 + s2 + max(6, s1 + p2 + 1)     max(6, s1 + p2 + 1)
e1 { UNION | EXCEPT | INTERSECT } e2   max(s1, s2) + max(p1-s1, p2-s2)        max(s1, s2)
e1 % e2                                min(p1-s1, p2 -s2) + max( s1,s2 )      max(s1, s2)

* The result precision and scale have an absolute maximum of 38. When a result 
  precision is greater than 38, the corresponding scale is reduced to prevent the 
  integral part of a result from being truncated.
_

この表の変数には、次のようなものがあります。

_e1: @big_number, a DECIMAL(38, 0)
-> p1: 38
-> s1: 0

e2: 1, an INT
-> p2: 10
-> s2: 0

e1 / e2
-> Result precision: p1 - s1 + s2 + max(6, s1 + p2 + 1) = 38 + max(6, 11) = 49
-> Result scale:                    max(6, s1 + p2 + 1) =      max(6, 11) = 11
_

上記の表のアスタリスクのコメントに従って、DECIMALの最大精度は38です。したがって、結果の精度は49から38に削減され、「対応するスケールは結果の整数部分が切り捨てられないように縮小されます」。このコメントからは明らかではありません方法スケールが縮小されますが、私たちはこれを知っています：

表の式によれば、2つのDECIMALsを除算した後の最小可能なスケールは6です

したがって、結果は次のようになります。

_e1 / e2
-> Result precision: 49 -> reduced to 38
-> Result scale:     11 -> reduced to 6  

Note that 6 is the minimum possible scale it can be reduced to. 
It may be between 6 and 11 inclusive.
_

これがどのように算術オーバーフローを説明するか

今の答えは明白です：

除算の出力はDECIMAL(38, 6)にキャストされ、DECIMAL(38, 6)は10を保持できません37。

これで、結果canがDECIMAL(38, 6)に収まるようにすることで、成功する別の除算を構築できます。

_DECLARE @big_number    DECIMAL(38,0) = '1' + REPLICATE(0, 37);
DECLARE @one_million   INT           = '1' + REPLICATE(0, 6);

PRINT @big_number / @one_million;
_

結果は次のとおりです。

_10000000000000000000000000000000.000000
_

小数点以下の6つのゼロに注意してください。上記のようにDECIMAL(38, 6)を使用すると、結果のデータ型がSQL_VARIANT_PROPERTY()であることを確認できます。

_DECLARE @big_number   DECIMAL(38,0) = '1' + REPLICATE(0, 37);
DECLARE @one_million  INT           = '1' + REPLICATE(0, 6);

SELECT
      SQL_VARIANT_PROPERTY(@big_number / @one_million, 'BaseType')  AS [BaseType]  -- decimal
    , SQL_VARIANT_PROPERTY(@big_number / @one_million, 'Precision') AS [Precision] -- 38
    , SQL_VARIANT_PROPERTY(@big_number / @one_million, 'Scale')     AS [Scale]     -- 6
;
_

危険な回避策

では、どうすればこの制限を回避できますか？

まあ、それは確かにあなたがこれらの計算をしていることに依存します。すぐにジャンプできるソリューションの1つは、計算のために数値をFLOATに変換し、完了したらそれらをDECIMALに戻すことです。

これは状況によってはうまくいくかもしれませんが、それらの状況が何であるかを理解するように注意する必要があります。ご存知のように、FLOATとの間で数値を変換することは危険であり、予期しない結果や不正確な結果をもたらす可能性があります。

この例では、10を変換します37FLOATとの間で、単純なwrongの結果を取得します。

_DECLARE @big_number     DECIMAL(38,0)  = '1' + REPLICATE(0, 37);
DECLARE @big_number_f   FLOAT          = CAST(@big_number AS FLOAT);

SELECT
      @big_number                           AS big_number      -- 10^37
    , @big_number_f                         AS big_number_f    -- 10^37
    , CAST(@big_number_f AS DECIMAL(38, 0)) AS big_number_f_d  -- 9999999999999999.5 * 10^21
;
_

そして、そこにあります。私の子供達、注意深く分けてください。

18
Nick Chammas