この問題は、mysql データベースのデータ ストレージ構造によって発生します。Mysql は、B+ ツリー構造を使用してデータを保存します。主な理由は、B+ ツリーのクエリ効率が安定しているためです。最大 IO 数はツリーの高さであり、同じ高さの B+ ツリーは B+ ツリーよりも効率的です。ツリーの方がより多くのデータを保存できるため、疑問が生じます。B+ ツリーの高さが一定の場合、B+ ツリーの幅は広いほど良いのでしょうか? この質問に答えるには、まず B+ ツリーの幅を増やすことの影響を理解する必要があります。
まず、ツリーの幅を増やすとデータのサイズに影響しますが、ツリーの幅が増えるということはサブツリーが増加したことを意味し、格納されるデータも増加します。クエリの効率に影響するでしょうか? 答えは「いいえ」です。B+ ツリーの非リーフ ノードには次のレベルのノードのインデックスとポインタが格納されているためです。クエリを実行すると、最初にルート ノードが読み取られ、次のレベルのノードのアドレスが読み取られます。レベル ノードはインデックス比較に基づいて直接決定され、次のレベル ノードが読み取られ、リーフ ノードが見つかるまで比較されます。たとえば、クエリを実行する必要があります 59
1) 初めてディスクにアクセスしたときに、最初の層にアクセスし、キー (主キー) の ID 値 59 と 97 を見つけました。アクセスされた 59 が左ノードの最大数で、97 が最大数です。右ノードの数。アクセスされた要素が 59 以下であるかどうかを判断し、そうである場合は、左ノードに移動して 2 番目のレベルに到達します。
2) 第 2 層アクセス時に、アクセスキーの ID 値が 15、44、59 であることが判明し、keyID 値 59 が 44 より大きく 59 以下であることが判明しました (バイナリ)ここでは検索が使用されます)、3 番目の子ノードがアクセスされました
3) 3 番目の層のリーフ ノードにアクセスするとき、keyid 値 51 と 59 を見つけて、順次検索を実行し、内部で検索を横断して、キーの id 値に対応するデータを見つけます。
したがって、データ ボリュームのサイズとツリーの幅はクエリの効率に影響を与えません。
この場合、ツリーの幅が無限に増加すると、データベースの容量は無限になるのではありませんか? もちろんそうではありません。最大幅はどのくらいですか? これは、単一ノードのサイズから始まります。ノード情報を読み取るとき、実際には、ディスクから読み取ります。データをメモリにロードします。ここで知っておくべきことの 1 つは、メモリがロードされるとき、ページに従ってロードされるということです。デフォルトでは 1 ページは 16k で、B+ ツリーのノードはデフォルトで 1 ページのメモリを占有しますこれは、基本的に 1 ページで満たされるため、ほとんどのデータ要件は満たされますが、2 ページを占有すると、ノードが読み取られるたびに 2 つの IO が必要となり、クエリ効率が低下するだけでなくメモリの無駄も増加します。したがって、B+ ツリーのノードのサイズはページ サイズと同じ 16k です。この数値とデータのサイズを組み合わせることで、基本的に各ノードが保存できるデータ量を計算できます。 bigint インデックスに従って計算すると、キー値は 8 バイトを占めます。インデックス ポインタは 6 バイトを占め、つまり 14 バイトです。そのルート ノードは最大 16*1024/14=1170 個のインデックスを格納できるため、B+ ツリーの第 2 レベルは最も幅が広いのは 1170 サブツリーで、3 番目のレベルが最も幅が広くなります。1170*1170 ノード
結論: B+ ツリーの高さが一定の場合、幅が広いほど多くのデータを保存でき、ディスクをフルに活用できるため無駄が減り、クエリ効率には影響しませんが、幅には上限があります。最大幅に達すると、時間を増やすことができなくなります。