mysqlのロックとインデックスの間の接続

通常、データベースを初めて使用する場合、ロックの効率性を考慮することはほとんどありませんが、データの量が増加するにつれて、同時実行性を防止するという目的のみを達成する必要があることがわかります。使用する必要のある SQL は非常に最適化されていますが、それでも非常に遅い場合があり、現時点では、それが mysql ロックによって引き起こされているかどうかを検討する必要があります。

まず、新しいデータテーブルを作成します:

ここで、主キーにはデフォルトでインデックスが付けられています

次に、テストのために 2 つのプロセスを開きます :

まず、インデックス ロックを含まない where 条件を追加します。

次に、2 番目のウィンドウでこの行のデータを更新すると、この操作がスタックすることがわかります

。

次に、トランザクションを送信すると、2 番目のウィンドウのデータがすぐに実行されることがわかります。

上記のことから、これで問題がないようです。ただし、同じロックを追加して、以下で実行したデータなどの他のデータの更新を試みることはできます:

上記の 3 つの状況はすべて同じプロセスを使用してテストされましたが、すべてスタックするため、問題が発生します。実際、name='test name' をロックする場合、id=133 と id=134 の 2 つの行のみをロックする必要がありますが、135、136、137 はロックしたくないのですが、これら 3 つの行にはアクセスできません。私たちのロックは 1 つのテーブル ロックであるため、ロックを使用するときにインデックスが使用される別の状況を試してみましょう:

上記のロックを使用するときにインデックスが使用されますが、データを更新するときにまだスタックします。インデックスは実際には役に立たないと感じますが、同じロックに遭遇してデータを更新するときにインデックスを使用すると、その効果がわかります:

これがロックによってスタックされていないことがわかります

以下 要約すると、ロックがインデックスを使用する場合は行ロック、インデックスを使用しない場合はテーブル ロックですが、操作するデータはロックを使用する必要があります。

なぜこれが当てはまるのかについて話しましょう:

まず第一に、インデックスがない場合、テーブルロックを形成するフルテーブルスキャンの形式でデータの選択または位置決めを実行することがわかります。インデックスがある場合は、指定された行が直接配置されます。つまり、行ロックが形成されますが、データを更新するときにインデックスを使用しない場合、ロックされた行がテーブル全体にスキャンされることに注意してください。スキャンするとロックされるため、望ましい効果は得られません

関連する推奨事項:

mysql ロック機構_MySQL

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

MySQL ロックを最適化する方法

以上がmysqlのロックとインデックスの間の接続の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。