0

A、B、C の 3 つの列があるとします。それぞれに、x、y、zの 可能な値の範囲があります。

3 つの列すべてのインデックスのサイズは x * y * z に比例しますか?

4

1 に答える 1

0

いいえ。 のサイズINDEXは (概算)

  N * L + overhead

N = テーブル全体の行数。
L = インデックスのすべての列の値の長さ (バイト単位) と、PRIMARY KEY.
オーバーヘッド = さまざまなポインター、長さ、パディングなど

例: CREATE TABLE ... id INT PRIMARY KEY, A INT, INDEX(A) ...

INT4 バイトのデータ型です。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% の余分な量と、いくらかの「オーバーヘッド」があります。

于 2021-01-21T17:59:40.363 に答える