InnoDBのNext-Keylockについて

最近は新入社員研修の材料を準備していて、コンセプトを紹介しておけばOKと思っていたのですが、事務の章を書いた以上、特にロックを紹介したくて、ロックを紹介したので、思わずNext-Key Lockを紹介したくなりました.
ご存知のように、標準的な事務隔離レベルはREAD UNCOMMITTED、READ COMMITTED、REPEATED READ、SERIALIZABLEです.ここでInnoDBはデフォルトでREPEATED READレベルを実現しており、このレベルでは非整合性読みの問題を解決できるが、幻読みの問題は解決できないが、InnoDBはNext Key Lockアルゴリズムを採用し、このレベルでは幻読み保護を実現している.
幻読とは何か、この概念は公式ドキュメントで答えを見つけることができ、ここではこれ以上説明しません.
まず例を見て、次のルールに従って表を作成します.

CREATE TABLE `test` (
  `id` int(11) DEFAULT NULL,  KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into test values (1), (3), (5), (8), (11);

ここでidにはインデックスがあります.このアルゴリズムは常にインデックスレコードをロックするからです.
インデックスがロックされる範囲は次のようになります.
     (-∞, 1], (1, 3], (3, 5], (5, 8], (8, 11], (11, +∞)
このとき,次の表の順序で2つのセッションを開くと,セッションBが6ステップ目まで実行されるまで成功し,6ステップ目がブロックされ,8ステップ目が正常に実行される.これにより、SessionAのSQLが実際に1つの範囲にロックされていることがわかり、8が存在する(5,8)区間のほかに、次の区間:(8,11)も同時にロックされているので、挿入12はロック範囲内ではありません.
ここで私はまだはっきりしていない问题があって、どうして5を挿入してまたブロックされて、もし谁が知っているならば伝言を残して教えて、ありがとうございます、私自身も资料を探して研究します.
Order
Session A
Session B
1
begin;
2
select * from test where id = 8 for update;
3
begin;
4
insert into test select 1;
5
insert into test select 4;
6
insert into test select 5;
7
insert into test select 9;
8
insert into test select 12;
上記の状況は、補助インデックスであり、一意ではない場合のロックです.唯一のインデックスなら?
id列をプライマリ・キーに変更すると、上記の表では、SessionBの4番目と6番目のプライマリ・キーが競合していることは言うまでもなく、他のステップは成功し、(5,8)、(8,11)の2つの区間内のすべての値(プライマリ・キーが競合していない)がテーブルに正常に挿入されます.この現象の原因は,インデックスが唯一で,InnoDBがロックをRecord Lockに降格し,レコードを1つロックするだけで,同時性を向上させることができるからである.
Next Key Lockにより、InnoDBはREPEATABLE READレベルで、幻読み保護を実現できる.
 
参照先:http://www.cnblogs.com/zhoujinyi/p/3435982.html