MySql の型変換により行ロックがテーブル ロックにアップグレードされる

MySql の write ステートメントでは、テーブルの列に割り当てられた値がテーブルの型と一致しない場合、MySql の基盤となるオプティマイザーが機能し、強制的な型変換を実行します。このとき、動作は正常ですが、行ロックはテーブル ロックにアップグレードされます。例は次のとおりです。

学生テーブルを例に挙げます。テーブルのフィールド タイプは次のとおりです。
テーブルの内容は次のとおりです。

2 つのセッション セッション ウィンドウを開き、MySql の自動送信モードを変更します。手動送信までの 2 つのセッション ウィンドウ

>set autocommit=false;

はセッション ウィンドウ 1 で更新ステートメントを実行しますが、トランザクションはコミットしません。 age カラムは、テーブルの作成時に int 型として指定されます。文字列 '100' は、Update ステートメントの代入に使用されます。MySql オプティマイザーは、文字列 '100' を整数 100 に自動的に変換し、SQL 検索を実行します。 。

>update student set class=3 where age='100'

次に、セッション ウィンドウ 2 で他の無関係なデータに対して更新操作を実行します

>update student set age=28 where name='lzj';

通常の状況では、2 つの SQL ステートメントによって操作される行データは異なるため、セッションでの更新操作は互いに影響しません。 1 は実際にはブロックされています。セッション 2 の更新操作はセッション 1 で実行されましたが、トランザクションの分離レベルは読み取りコミットされなかったため、セッション 1 の更新結果は実行できません。セッション2で見られました。ただし、セッション 2 の他の行でデータ更新操作を実行すると、ブロッキングが発生しました。セッション 1 での SQL ステートメントの割り当てが強制されたため、セッション 1 の行ロックがテーブル ロックにアップグレードされ、学生テーブル全体がロックされ、その結果、セッション 2 の SQL がブロックされたことがわかります。次に、セッション 1 の更新操作でトランザクションのコミットを実行します。その後、セッション 2 の更新操作が引き続き実行されます
セッション 1 の更新操作で commit を実行します。トランザクションを手動で送信した後、 、セッション 1 生徒のテーブル ロックを解放すると、セッション 2 の更新操作を続行できます。
最後に、セッション 2 の更新に対して commit トランザクションも実行されます。両方の SQL ステートメントが更新されます。student テーブルの内容は次のとおりです。 commit手动提交事务后，会话1释放掉student的表锁，会话2中的更新操作可以继续执行。
最后对会话2中的更新也执行commit
上記のケースから、次のようになります。 SQL ステートメントの割り当てとテーブルの列の型が一致していることを確認してください。不一致がある場合、MySql オプティマイザは一致する型に強制的に変換され、行ロックがテーブル ロックにアップグレードされます。したがって、開発中に型の一致に注意して、行ロックがテーブル ロックにアップグレードされないようにする必要があります。これは同時実行パフォーマンスに影響します。

関連する推奨事項:

MySQL の行レベルのロック、テーブルレベルのロック、およびページレベルのロックの詳細な紹介

MySQL ロックの使用法テーブルレベルのロック

以上がMySql の型変換により行ロックがテーブル ロックにアップグレードされるの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。