MySQLのエンコードの不一致によって発生する可能性のある問題

ストアドプロシージャとコーディング

MySQL ストアド プロシージャでは、テーブルとデータのエンコーディングがデータベースとストアド プロシージャのデフォルトのエンコーディングと異なる場合、MySQL は条件列のデータに対して対応するエンコーディング変換を実行するため、SQL はインデックスを使用しない場合があります。たとえば、次のテーブル データは latin1 であり、MySQL パーサーは何らかの変換を実行します。

... WHERE namecolumn = NAME_CONST('in_namecolumn',_utf8'MP201022' COLLATE 'utf8_general_ci')

ストアド プロシージャで対応するエンコード変換 (通常は varchar/char フィールドの変更) を実行すると、インデックスを正常に使用できるようになります。詳細については、mysql-slow-when-run-as-stored-proc を参照してください。

... WHERE namecolumn = convert(in_namecolumn using latin1) collat​​e latin1_swedish_ci

SQLを実行するためのJDBC直接接続

jdbc 接続を介して SQL を実行するときに、エンコーディングが一貫していない場合は、次に示すように、varchar および char 型も変換する必要があります。

... WHERE namecolumn = convert(in_namecolumn using latin1) collat​​e latin1_swedish_ci

そうしないと、次のエンコード不整合エラーが発生する可能性があります (mysql-connector のバージョンに応じて動作が異なる場合があります)。

SQL 状態 [HY000]: エラー コード [1267]: 演算 '=' の照合順序 (latin1_swedish_ci、IMPLICIT) と (utf8mb4_general_ci、COERCIBLE) の組み合わせが不正です

jdbc useSSL パラメータの変更

mysql-connector-java 構成では、useSSL パラメータに次の違いがあります。5.1.38 以降、useSSL は MySQL 5.5.45+、5.6.26+、または 5.7.6+ でデフォルトで有効になります。対応する requireSSL および verifyServerCertificate パラメータも有効になります。

< 5.1.38:
 ConnectionProperties.useSSL=サーバーとの通信時にSSLを使用する(true/false)、デフォルトは「false」

>= 5.1.38
 ConnectionProperties.useSSL=サーバーとの通信時にSSLを使用する(true/false)。MySQL 5.5.45+、5.6.26+、または5.7.6+に接続する場合のデフォルトは「true」、それ以外の場合のデフォルトは「false」です。

MySQL 5.7.x 以降では、SSL がデフォルトで有効になり、明示的に暗号化しないように指定しない限り、クライアントは接続時に自動的に暗号化をネゴシエートします。mysql-connector-java は、5.1.38 以降、useSSL をデフォルトで有効にしています。そのため、jdbc の下位バージョンで MySQL 5.7.x に接続する場合は暗号化の問題は発生しませんが、jdbc の上位バージョンで 5.7.6+ に接続する場合は暗号化の問題が発生します。useSSL=false を明示的に指定する必要があります。そうすれば、jdbc の上位バージョンで MySQL 5.5、5.6 に接続する場合は暗号化の問題は発生しません。

これで、一貫性のない MySQL エンコーディングによって発生する可能性のあるいくつかの問題についての記事は終わりです。一貫性のない MySQL エンコーディングによって発生する問題の詳細については、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM を応援していただければ幸いです。