MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ | mond

MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ 端的に言うと性能が良いからです。 これを理解するにはバッファプールへの理解が必要です。ディスク指向のデータベースの上では有限のメモリを最大限活用することでメモリに入り切らない巨大なデータ群に対して良好な参照性能を出す必要があります。バッファプールとはディスク上のデータの羅列を固定サイズのページ（InnoDBの場合16KB）の羅列であるとして読み書きに必要な分だけをメモリに移し取り複数の書き込みをできる限りメモリ内で受け止めて後でまとめてディスクに書き戻すという、ライトバック型のキャッシュのような機構です。 この中においてバッファプールは有限のサイズしか無いので適宜プール内のデータを書き戻して入れ替えながら上手くやっていく必要があります。 さてB+treeとB-treeの最大の違いは木のリ

[zoidstown]

“メモリの価格が劇的に安くなったのでメモリに乗り切らないデータは扱わないと初めから割り切ったインメモリDBも台頭。何なら世の中のDBの9割は5GB未満しか保存していないなんて与太話もある”

[rgfx]

そういやB+Tree動画を見ていたところだった https://www.youtube.com/watch?v=O3itc2Z1zhI

[beerbeerkun]

全く関係ない話ではあるがOracleが持ってる古い特許が切れて、OSSのDBで回避してたことによる非効率な実装が可能になるって話が随分前にあったな。あれどうなったんだろう。

[NetPenguin]

これ系の話で、インメモリ？SSD？前提のDBだと、読み出し回数を増やして、CPUによる比較回数を減らすみたいな話を昔に見た気がするな。

[yarumato]

“B+treeの方がディスクシークが少ない。MySQL設計時のHDDが遅い時代の設計。最近は事情が違う。ディスクシークはNVMeで速くなった。B+treeは無駄が多い。メモリが劇的に安くなりインメモリDBも台頭”

[uesima]

mysql

[fn7]

興味深し。

[pekee-nuee-nuee]

なんかさっきもB木の話あったな