1

私はmysql innodbテーブルを持っています -

create table data (
    `sha256` CHAR(64) NOT NULL,
    'created` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    <some other fields>
    PRIMARY KEY (`sha256`),
)

mysqld_slow_query で最も遅いクエリの 1 つは、

select * from data where created between "2013-02-01" and "2013-03-01";

このクエリの実行を改善するために、2 つのオプションがあります。

オプション 1: 作成時にインデックスを追加する

オプション 2: ('created', 'sha256') を主キーにし、sha256 にインデックスを追加します。

ここでの考え方は、1 か月で収集されるデータのように、多数の行を選択する場合に、アクセスされる B-tree ブロックの数を減らしたいということです。インデックスを介してこれらのレコードにアクセスする場合 (オプション 1)、レコードごとに異なるブロックにアクセスする可能性があります。代わりに、タイムスタンプで並べ替えられたレコードをプライマリ/クラスター化キーとして保存すると (オプション 2)、同じ B ツリー ブロック内に多数のレコードが見つかり、ディスクの読み取りが減少します。

しかし、何らかの理由で、オプション 1 ではパフォーマンスが向上しますが、オプション 2 ではパフォーマンスがそれほど向上しません。理由はありますか？そして、他の提案はありますか？前もって感謝します。

4

1 に答える 1

1

InnoDB はクラスター化されたプライマリ インデックスを使用CHAR(64)し、非常に大きなプライマリ キーを作成するため、大きなプライマリ キーに特に敏感です。AUTOINCREMENT主キーとして id 列を追加しsha256、一意のインデックスを指定することをお勧めします。インデックスがオンになっているものは、createdすべてのパフォーマンスに役立つはずです。のルックアップsha256はわずかに遅くなりますが、それ以外はすべて高速になります。のランダムな値によってデータをシフトする必要がないため、挿入も高速になりますsha256。

単一のインデックスの方がはるかに高速だった理由は完全にはわかりませんが、クラスター化されたインデックスであるにもかかわらず、複合インデックスが非常に大きいことに関係している可能性があります。

于 2013-04-09T21:36:56.133 に答える