暗黙的な型変換を避ける

このドキュメントでは、TiDB における暗黙的な型変換のルールと考えられる結果、および暗黙的な型変換を回避する方法を紹介します。

変換ルール

SQL ステートメント内の述語の両側のデータ型が一致しない場合、TiDB は片側または両側のデータ型を述語操作用の互換性のあるデータ型に暗黙的に変換します。

TiDB における暗黙的な型変換のルールは次のとおりです。

  • 一方または両方の引数がNULLの場合、比較の結果はNULLになります。 NULL セーフ<=>等価比較演算子は、 NULL <=> NULL の結果がtrueになるため、変換する必要はありません。
  • 比較演算の両方の引数が文字列である場合、それらは文字列として比較されます。
  • 両方の引数が整数の場合、それらは整数として比較されます。
  • 数値との比較が行われない場合、16 進値はバイナリ文字列として扱われます。
  • 引数の 1 つが 10 進数値の場合、比較はもう 1 つの引数に依存します。もう一方の引数が 10 進数値または整数値の場合、引数は 10 進数値と比較されます。もう一方の引数が浮動小数点値の場合、その引数は浮動小数点値と比較されます。
  • 引数の 1 つがTIMESTAMP列またはDATETIME列で、もう 1 つの引数が定数の場合、その定数は比較が実行される前にタイムスタンプに変換されます。
  • それ以外の場合はすべて、引数は浮動小数点数 (タイプDOUBLE ) として比較されます。

暗黙的な型変換によって引き起こされる結果

暗黙的な型変換により、人間とコンピューターの対話の使いやすさが向上します。ただし、次の問題が発生する可能性があるため、アプリケーション コードでの暗黙的な型変換の使用は避けてください。

  • インデックスの無効性
  • 精度の低下

インデックスの無効性

次の場合、 account_idが主キーで、そのデータ型はvarcharです。実行プランでは、この SQL ステートメントには暗黙的な型変換があり、インデックスを使用できません。

DESC SELECT * FROM `account` WHERE `account_id`=6010000000009801; +-------------------------+----------------+-----------+---------------+------------------------------------------------------------+ | id | estRows | task | access object | operator info | +-------------------------+----------------+-----------+---------------+------------------------------------------------------------+ | TableReader_7 | 8000628000.00 | root | | data:Selection_6 | | └─Selection_6 | 8000628000.00 | cop[tikv] | | eq(cast(findpt.account.account_id), 6.010000000009801e+15) | | └─TableFullScan_5 | 10000785000.00 | cop[tikv] | table:account | keep order:false | +-------------------------+----------------+-----------+---------------+------------------------------------------------------------+ 3 rows in set (0.00 sec)

実行結果の簡単な説明: 上記の実行計画から、 Castの演算子が表示されます。

精度の低下

次の場合、 aフィールドのデータ型はdecimal(32,0)です。実行プランでは、暗黙的な型変換が発生し、10 進数フィールドと文字列定数の両方が double 型に変換されます。 double 型の精度は 10 進数ほど高くないため、精度が失われます。この場合、SQL ステートメントは範囲外の結果セットを誤ってフィルター処理します。

DESC SELECT * FROM `t1` WHERE `a` BETWEEN '12123123' AND '1111222211111111200000'; +-------------------------+---------+-----------+---------------+-------------------------------------------------------------------------------------+ | id | estRows | task | access object | operator info | +-------------------------+---------+-----------+---------------+-------------------------------------------------------------------------------------+ | TableReader_7 | 0.80 | root | | data:Selection_6 | | └─Selection_6 | 0.80 | cop[tikv] | | ge(cast(findpt.t1.a), 1.2123123e+07), le(cast(findpt.t1.a), 1.1112222111111112e+21) | | └─TableFullScan_5 | 1.00 | cop[tikv] | table:t1 | keep order:false, stats:pseudo | +-------------------------+---------+-----------+---------------+-------------------------------------------------------------------------------------+ 3 rows in set (0.00 sec)

実行結果の簡単な説明: 上記の実行計画から、 Castの演算子が表示されます。

SELECT * FROM `t1` WHERE `a` BETWEEN '12123123' AND '1111222211111111200000'; +------------------------+ | a | +------------------------+ | 1111222211111111222211 | +------------------------+ 1 row in set (0.01 sec)

実行結果の簡単な説明: 上記の実行では間違った結果が得られます。

このページは役に立ちましたか?

Playground
新規
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Cloud
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.