A、B、C の 3 つの列があるとします。それぞれに、x、y、zの 可能な値の範囲があります。
3 つの列すべてのインデックスのサイズは x * y * z に比例しますか?
A、B、C の 3 つの列があるとします。それぞれに、x、y、zの 可能な値の範囲があります。
3 つの列すべてのインデックスのサイズは x * y * z に比例しますか?
いいえ。 のサイズINDEX
は (概算)
N * L + overhead
N = テーブル全体の行数。
L = インデックスのすべての列の値の長さ (バイト単位) と、PRIMARY KEY
.
オーバーヘッド = さまざまなポインター、長さ、パディングなど
例: CREATE TABLE ... id INT PRIMARY KEY, A INT, INDEX(A) ...
INT
4 バイトのデータ型です。40 億を超える個別の値を保持できます。テーブルに 100 行ある場合、secondary を保持する BTree を見てみましょうINDEX(A)
。
N = 100
L = 4 + 4 -- that bytes, not billions of bytes
N * L = 800 ですが、オーバーヘッドが追加され、ブロッキングを使用すると、16KB かかります。(注: InnoDB は、データとインデックスを 16KB の「ブロック」に割り当てます。)
そのテーブルに追加します
city VARCHAR(100), -- average length 10 characters
INDEX(city, A)
N = 100 -- still assuming 100 rows
L = (2+10) + 4 + 4 = 16
total = again, only 1-2 blocks.
The (2+10)
: 2 文字列の「長さ」; 実際の文字列の場合、平均で 10 です。(場合によっては、「2」が実際には「1」であり、utf8 を使用している場合、各文字が複数バイトになる可能性があります。)
そのテーブルが 100 万行に成長した場合、インデックスは 50MB を消費する可能性があり、その多くは避けられない「オーバーヘッド」です。
主な例外:
InnoDB の場合PRIMARY KEY
、データで「クラスター化」されているため、サイズは事実上ゼロです。実際には、その BTree の非リーフ ノードには約 1% の余分な量と、いくらかの「オーバーヘッド」があります。