InnoDBエンジンの行レベルのロック変更テーブルロックケースでのMysqlインデックスの失敗

数日前に、わかりやすくユーモラスな巨大な人工知能学習ウェブサイトを発見しました。みんなと共有せざるを得ません。クリックしてチュートリアルにジャンプします。
最初に準備をして、InnoDBエンジンデータテーブルを作成し、対応するインデックスを追加します。

DROP TABLE IF EXISTS `innodb_lock`;
CREATE TABLE `innodb_lock` (
  `a` int(10) NOT NULL,
  `b` varchar(255) NOT NULL DEFAULT '',
  KEY `index_a` (`a`),
  KEY `index_b` (`b`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;


-- ----------------------------
-- Records of innodb_lock
-- ----------------------------
INSERT INTO `innodb_lock` VALUES ('1', 'b2');
INSERT INTO `innodb_lock` VALUES ('3', '3');
INSERT INTO `innodb_lock` VALUES ('4', '4000');
INSERT INTO `innodb_lock` VALUES ('5', '5000');
INSERT INTO `innodb_lock` VALUES ('6', '6000');
INSERT INTO `innodb_lock` VALUES ('7', '7000');
INSERT INTO `innodb_lock` VALUES ('8', '8000');
INSERT INTO `innodb_lock` VALUES ('9', '9000');
INSERT INTO `innodb_lock` VALUES ('1', 'b1');

次に、2つのMysql端末をそれぞれ開き、自動コミットを0に設定します。つまり、自動コミット機能をオフにすると、トランザクション分離レベルは繰り返し可能な読み取り状態になります。テーブルデータを確認してください。

MySQL [test_db]> set autocommit = 0;
MySQL [test_db]> select * from innodb_lock;
+---+------+
| a | b    |
+---+------+
| 1 | b2   |
| 3 | 3    |
| 4 | 4000 |
| 5 | 5000 |
| 6 | 6000 |
| 7 | 7000 |
| 8 | 8000 |
| 9 | 9000 |
| 1 | b1   |
+---+------+

次に、最初の端末でupdateステートメントを実行します

MySQL [test_db]> update innodb_lock set b ='4001' where a = 4;

次に、2番目の端末がupdateステートメントを実行します

MySQL [test_db]> update innodb_lock set b = '4004' where a = 4;

ここで同じデータ行が変更されているため、2番目の端末がブロック状態になっていることがわかります。最初の端末が送信した後、ロックが解除され、2番目の端末がSQLの実行を終了し、最後に2番目の端末もコミットします。データ送信後のデータ。変更されます。bの値は「4004」です。

私たちは続けます

最初の端末でupdateステートメントを実行します

MySQL [test_db]> update innodb_lock set b='4005' where a = 4;

次に、2番目の端末がupdateステートメントを実行します

MySQL [test_db]> update innodb_lock set b = '9001' where a = 9;

両方のステートメントが正常に実行されたことがわかりました。変更は同じデータ行ではないためです。次に、それらを個別にコミットしてから、データを確認し、データの両方の行が変更されていることを確認します。

MySQL [test_db]> select * from innodb_lock;
+---+------+
| a | b    |
+---+------+
| 1 | b2   |
| 3 | 3    |
| 4 | 4005 |
| 5 | 5000 |
| 6 | 6000 |
| 7 | 7000 |
| 8 | 8000 |
| 9 | 9001 |
| 1 | b1   |
+---+------+

以下は重要なポイントです、2つの端子はまだ別々に異なるラインを操作します。

最初の端末で更新操作を実行します

MySQL [test_db]> update innodb_lock set a = 41 where b =4005;

ここで、where条件b = 4005に注意してください。現在のテーブルのbフィールドは文字列型であり、インデックスが追加されることに注意してください。インデックスが追加された後、クエリ条件が引用符で囲まれていないと、失敗します。

次に、2番目の端末で更新操作を実行します

MySQL [test_db]> update innodb_lock set b='9002' where a = 9;

ブロックされていることが判明したため、行ロックがテーブルロックに変更されました。
インデックスの合理的な使用に注意してください。~~

コンテンツはhttps://www.cnblogs.com/wt645631686/p/8323963.htmlから転送されます

InnoDBエンジンの行レベルのロック変更テーブルロックケースでのMysqlインデックスの失敗

おすすめ