ITエンジニアの成長ブログ

ITエンジニアとして行う勉強の発信&日々の生活で体験した楽しいことをゆるく発信

JDBCを用いてSQL Serverに接続するときの文字列パラメータについて注意すること

お恥ずかしながら、最近知ったことを備忘録として残しておきます。

詳しいことは、すべてここのMicrosoftのブログに記載されています。
DO's&DONT's #2: 絶対にやらなければいけないこと - データ型を一致させる | Microsoft Docs

SQL Serverでデータの比較をするとき、型が異なる場合はデータ型の優先順位に従いどちらかの型が優先順位の高い型に変換されます。

たとえば、VARCHARカラムとNVARCHARのカラムで比較をした場合は、VARCHARのカラムが暗黙的にNVARCHARに型変換されることになります。

データ型の優先順位の詳細は、以下のMicrosoftのページで確認できます。
データ型の優先順位 (Transact-SQL) - SQL Server | Microsoft Docs

それで、最近知ったのですがタイトルの通り、JDBCを用いてSQL Serverに接続するときに文字列パラメータがUnicode となるのか、非 Unicode となるのかは、接続文字列プロパティ「sendStringParametersAsUnicode」で指定する仕組みのようです。

この接続文字列パラメータは、デフォルトで"true"です。つまり、何もしなければ(設定しなければ)文字列パラメータはUnicodeで扱われることになります。

ここが今回のブログで注意しておくことなのですが、この文字列パラメータがデフォルトでUnicodeで扱われることにより、テーブルのデータ型でCHARやVARCHARを使っていた場合は暗黙の型変換が発生してしまうということです。

暗黙の型変換は、パフォーマンスの悪化につながるため適切な設定をしてあげる必要があります。テーブルのデータ型でCHARやVARCHARを使っている場合は、JDBC接続文字列プロパティ「sendStringParametersAsUnicode」を"false"に設定することで、文字列パラメータは非Unicodeとして扱われて結果的に暗黙の型変換が不要になります。

自分は最近、デッドロックの調査で色々と調べていたところ、このことについて知ることができましたが、もしかしたら一生知らないままになっていたかもしれません...笑

最近は、もちろんUnicodeで統一する流れですのでデフォルトUnicodeが当然かもしれませんが、ややはまりどころのような気がします。

それでは、最後までお読みいただきありがとうございました。今回はこの辺で失礼いたします。