MySql の JDBC 接続 URL アドレスの設定手順と解決された問題

まず、jdbc URL アドレスを確認します。

 `url: jdbc:mysql://127.0.0.1:3306/test?useAffectedRows=true&autoReconnect=true&useUnicode=true&characterEncoding=utf-8&allowMultiQueries=true&zeroDateTimeBehavior=convertToNull&useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai`

次に、内部の構成と解決された問題を徐々に分析していきます。

1.useAffectedRows=true

更新操作を実行する場合、更新結果に基づいて論理的な判断を下すことがよくあります。たとえば、戻り値が 1 より大きい場合は更新が成功したことを意味し、値が 0 の場合は更新が失敗したことを意味します。
ただし、Mysql ドライバーを使用してデータベースに接続し、更新操作を実行すると、戻り値が期待どおりにならない場合があります。

たとえば、SQL1: update task_info SET task_status=2 where id=?
この SQL を何度実行しても、更新の戻り値が 1 になる場合があります。その理由は、MySQL の接続 URL にあります。
mysqlURL を変更し、パラメータuseAffectedRows=trueを追加します。

jdbc:mysql://127.0.0.1:3306/test?characterEncoding=utf-8&useAffectedRows=true

useAffectedRowsの機能は、データを返すために、見つかった行数の代わりに影響を受けた行数を使用するかどうかです。デフォルトは false です。この値を指定すると、更新時に更新行数が返されますが、SQL1による更新操作でも通常の値、つまり1回目は1、2回目は0が返されます。

2.autoReconnect=true

データベース接続タイムアウトに autoReconnect=true を設定し、デフォルトの再試行回数を調整します。

ドライバーは接続の再確立を試行する必要がありますか? 有効にすると、ドライバーは、現在のトランザクションの一部である古い接続または無効な接続に対して発行されたクエリに対して例外をスローしますが、新しいトランザクションの接続に対して次のクエリが発行される前には例外をスローしません。再接続してみてください。この機能の使用は推奨されません。アプリケーションが例外を適切に処理しない場合、セッション状態とデータの一貫性に副作用が生じるためです。また、アプリケーションが例外を処理するように構成できない場合にのみ使用するように設計されており、結果としてデッド エラーが発生します。古い接続を適切に修復します。また、最後のオプションとして、MySQL サーバー変数「wait_timeout」をデフォルトの 8 時間よりも大きい値に設定することを検討してください。

3.useUnicode=true&characterEncoding=utf-8

mysql データベースは gbk エンコーディングを使用し、プロジェクトの mysql データベースは utf-8 エンコーディングを必要とするため、URL の後に useUnicode=true&characterEncoding=utf-8" を追加して、データベースにデータを保存するときに UTF-8 形式が使用されることを示します。データをバイトコードに変換し、デコードされたバイトコードを再利用して、GBK エンコードを使用してデータベースに保存します。データベースからデータを取得するとき、データは GBK 形式のバイトコードにデコードされ、その後バイトコードがバイトコードにデコードされます。データを UTF-8 形式で再エンコードし、クライアントに返します。

4.allowMultiQueries=true

MySQL がデータベースに接続するとき、ステートメントを追加します: " allowedMultiQueries=true ". 機能:
1. SQL ステートメントの後にセミコロンを付けると、複数ステートメントの実行を実現できます。
2. バッチ処理を実行し、複数の SQL 文を同時に発行できます。
ここに画像の説明を挿入します

5.zeroDateTimeBehavior=convertToNull

Mysql データベースにクエリを実行すると、例外が発生することがあります。

値「0000-00-00 00:00:00」は java.sql.Timestamp として表すことができません。スタックトレースは次のようになります。

java.sql.SQLException: 値 '0000-00-00 00:00:00' は java.sql.Timestamp として表すことができません


Datetimes with all-zero components (0000-00-00 ...): These values cannot be represented reliably in Java. Connector/J 3.0.x always converted them to NULL when being read from a ResultSet. 

重要なのは、Mysql では 0000-00-00 00:00:00 が有効である可能性がありますが、Java ではそのような変換は無効であるということです。

したがって、Java は日付形式 0000-00-00 00:00:00 を認識しないため、Mysql JDBC ドライバーは java.sql.SQLException をスローします。

6.useSSL=false

SSL 暗号化プロトコル
ここに画像の説明を挿入します

MySQL 5.7 より前のバージョンは安全性が低く、誰でも接続できるテスト ライブラリがあったことが判明したため、公式はバージョン 5.7 でプライバシー保護を強化しました。また、データベースの任意の変更を防ぐためにデフォルト値 useSSL = true が採用されていますが、バージョン 8.0 でも SSL は保持されており、デフォルト値は true なので、URL テーブル名の後に "?useSSL= false" を追加するだけです。

7.allowPublicKeyRetrieval=true

ユーザーがsha256_password認証を使用する場合、パスワードは送信中にTLSプロトコルによって保護される必要がありますが、RSA公開キーが使用できない場合は、サーバーによって提供される公開キーを使用できます。サーバーのRSA公開キーはServerRSAPublicKeyFile
で指定できます。接続で、またはAllowPublicKeyRetrieval=Trueパラメータを使用すると、クライアントがサーバーから公開キーを取得できるようになりますが、AllowPublicKeyRetrieval=Trueを使用すると、悪意のあるエージェントが侵入者経由で平文のパスワードを取得する可能性があることに注意してください。ミドルアタック ( MITM ) であるため、デフォルトではオフになっており、明示的にオンにする必要があります。

8.serverTimezone=アジア/上海

タイムゾーン設定が不適切であると、さまざまな問題が発生する可能性があります。以下に、いくつかの一般的な問題と解決策を示します。

8.1 MySQL の内部時刻が北京時間ではない

このような問題が発生した場合は、システム時刻とタイムゾーンが正しいかどうかを確認してから、MySQL のタイムゾーンを確認し、タイムゾーンを「+8:00」に変更することをお勧めします。

8.2 Java プログラムがアクセスする時刻とデータベース内の時刻には 8 時間の差があります。

この問題の最も可能性の高い原因は、プログラムのタイム ゾーンがデータベースのタイム ゾーンと一致していないことです。双方のタイムゾーンを確認できます。北京時間を統一して使用したい場合は、jdbc 接続文字列にserverTimezone=Asia/Shanghai を追加し、MySQL で time_zone を「+8:00」に変更することもできます。

8.3 プログラム時間とデータベース時間の差は 13 時間または 14 時間です

8 時間の差はそれほど驚くべきことではありませんが、13 時間の差には頭を悩ませる人も多いかもしれません。この問題の原因は、JDBC と MySQL で「CST」タイム ゾーンのネゴシエーションが一貫していないことです。CST タイム ゾーンは非常にわかりにくいタイム ゾーンであるため、次の 4 つの意味があります。

中部標準時 (米国) UTC-05:00 または UTC-06:00 中部
標準時 (オーストラリア) UTC+09:30 中国
標準時 UTC+08:00 キューバ
標準時 UTC -04:00
MySQL では、time_zone がデフォルトの SYSTEM の場合値を指定すると、タイム ゾーンはシステム タイム ゾーン CST として継承されます。これは、MySQL によって内部的に UTC+08:00 とみなされます。また、jdbc では CST を米国中部時間とみなすため、時差は 13 時間、冬時間の場合は 14 時間になります。

この問題を解決する方法も非常に簡単です。誤解を招く CST を使用せずに、MySQL データベースのタイム ゾーンを明確に指定できます。time_zone を '+8:00' に変更し、serverTimezone=Asia/Shanghai を追加することもできます。 jdbc 接続文字列に。

おすすめ

転載: blog.csdn.net/qq_45442178/article/details/130748033