どのように一般的なインデックスとユニークインデックスを選択するには？| CSDNボーウェン選択

著者| NY＆XX

Zebian |郭ルイ

制作| CSDNブログ

インターネットは、一意のインデックスと一般的な指標についての違いの多くは、ここでは詳細に説明されていないされている、と我々は一般的なインデックスはインデックスのみで選択する必要があり、どのように異なるビジネス・シナリオの深さで議論します。このような、社会保障の担当者を社会保障行政のシステムを維持するよう、それぞれが固有のID番号を持っており、サービスコードは、2つのID番号を繰り返さないようにするために書かれています。システムは、クエリ名に基づいてID番号を必要とする場合は、このSQL文を実行します：

select name from suser where id_card = ‘xxxxxxxxxxx’;

だから、一般的にid_cardフィールドにインデックスを構築することを検討してください。ID番号フィールドが比較的大きいので、主キーのため、インデックスは今2つの選択肢があり、どちらかid_cardフィールドに一意のインデックスを作成し、いずれかの共通のインデックスを作成するためには適していません。ビジネスは、コードが重複したIDカードの番号に書き込まれたことを確認していない場合は、これら2つのオプションのロジックが正しいです。しかし、考慮すべき観点アップのパフォーマンスの点から、どのような基準で、選ぶべきなのでしょうか？ここでは、クエリプロセスを分析し、どちらのインデックスからの更新プロセスのパフォーマンスに影響を与えます。

クエリの操作

我々は、InnoDBのインデックス組織を見て行うものと：

select id from t where a=3

次のようにインデックスツリープロセスで見つけるために、このクエリは次のようになります。

まず、データ・ページを検索するリーフノードに層方式による検索を横断、ルートからB +ツリーによって開始されます。
バイナリ検索でレコードを検索するには。

（例えば（3300））エントリの条件を満たすように最初に見つけた後、一意のインデックスのための検索を中止します。一般的な索引の検索の後、彼はエントリの最初の条件を満たしていない= 3に来るまでのエントリーの条件は検索を続ける満たすことができます。

彼らはギャップが最小となるパフォーマンスをもたらす異なります。InnoDBテーブルを読み書きするために、ページ単位のデータに基づいてエントリがディスクから読み取られていない場合、エントリを読んだとき、それは、されているので、しかし、ページ単位で、メモリへの全体的な読み取り。それはメモリ内のデータ・ページを持っているあなたが見つけたときにそうすることを、ページ単位で読み書きするためにストレージエンジン=エントリ3、以来。次に、あなただけの「見つけると、エントリ条件を満たすかどうかを判断」ん、通常のインデックス操作に必要なポインタ操作や計算時間を必要としています。

更新

当需要更新一个数据页时，如果数据页在内存缓冲池（buffer pool）中就直接更新，并同时记录redo log,但是如果这个数据页不在内存中的话。在不影响一致性的前提下，InnoDB会将更新操作缓存在写缓冲（change buffer）中，同时记录redo log。

写缓冲(change buffer)

那什么是change buffer呢？

它的主要目的是将对二级索引的数据操作缓存下来，以此减少二级索引的随机IO，并达到操作合并的效果。

在MySQL5.5之前的版本中，由于只支持缓存insert操作，所以最初叫做insert buffer，只是后来的版本中支持了更多的操作类型（操作类型包括insert、update、delete）缓存，才改叫change buffer。

change buffer的数据结构上是一颗b+树，存储在ibdata系统表空间中，根页为ibdata的第4个page(FSP_IBUF_TREE_ROOT_PAGE_NO)。

将change buffer中的操作应用到原数据页从而得到最新结果的过程被称为merge。merge 的时候才是是真正进行数据更新的时刻，change buffer 将条目的变更动作进行缓存。在一个数据页做 merge 之前，change buffer 记录的变更越多（也就是这个页面上要更新的次数越多),收益就越大。

一般来说，触发merge的操作主要有以下几种：

访问这个数据页；
master thread线程每秒或每10秒进行一次merge insert buffer的操作；
在数据库正常关闭的时候。

此外，虽然名字叫做change buffer，但实际上它是可以持久化的数据，也就说它在内存中有拷贝，也会被写入到磁盘上。

change buffer状态查看

seg size 为插入缓冲区的总大小（页的数量X16KB）；
merges表示已经合并的merge的数量；
merged operations: insert 插入记录被merge的次数；
delete mark 删除操作被merge的次数；
delete 更新操作被merge了多少次。

change buffer占用buffer pool

数据读入内存是需要占用buffer pool的，采用这种方式能够避免占用内存，提升内存利用率。

change buffer用的是buffer pool的内存，因此不能无线增大，它通过参数innodb_change_buffer_max_size来设置，这个参数表示占用内存的比例，默认是25%，最大值为50%，一般在写多读少的场景下才需要设置。

change buffer带来什么好处？

如果MySQL承担大量的DML操作，则change buffer是必不可少的，他的存在就是尽量减小I/O的消耗，通过内存进行数据的合并操作，将多次操作操作尽量变为少量的I/O操作，从而提升了更新操作的速度。

什么场景适合开启change buffer？

change buffer只限于普通索引的场景下，不适用与唯一索引。为什么呢？

因为，假设要插入(3, 300)这个条目，首先要判断这个条目是否在表中出现过。而这必须要将数据页读入内存才能判断。如果都已经读入到内存了，那直接更新内存会更快，就没必要使用 change buffer 了。

那么InnoDB中插入的条目（3,300）的流程是如何的呢？

如果这个条目要更新的数据页在内存中：

对于唯一索引，找到2和4的位置，判断没有冲突后，插入这个值，执行结束
对于普通索引，找到2和4的位置，插入这个值，执行结束

如果这个条目要更新的数据页不在内存中：

对于唯一索引，需要将数据页读入内存，然后判断有没有冲突，然后进行插入。
对于普通索引，只需要将条目更新操作记录在change buffer就执行结束了。

不是所有场景都可以用change buffer

普通索引并不是所有场景使用change buffer都能受益，对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时 change buffer 的使用效果最好。

但是假设一个业务的更新模式是写入之后马上会做查询，那么即使满足了条件，将更新先记录在change buffer，但之后由于马上要访问这个数据页，会立即触发 merge 过程。这样随机访问 IO 的次数不会减少，反而增加了 change buffer 的维护代价。所以，对于这样类似的业务模式来说，change buffer 反而起到了副作用。

举个例子：

假设要执行insert into t values(id1,a1),(id2,a2);

假设a1 所在的数据页在内存 (InnoDB buffer pool) 中，a2 所在的数据页不在的话，如图所示：