3 
CREATE TABLE index_test
(
  id int PRIMARY KEY NOT NULL,
  text varchar(2048) NOT NULL,
  value int NOT NULL
);
CREATE INDEX idx_index_value ON index_test ( value );
CREATE INDEX idx_index_value_and_text ON index_test ( value, text );
CREATE INDEX idx_index_text_and_value ON index_test ( text, value );
CREATE INDEX idx_index_text ON index_test ( text );

テーブルには 10000 のランダムな行が入力され、「値」列には 0 から 100 までの整数が含まれ、「テキスト」列にはランダムな 128 ビット md5 ハッシュが含まれます。不適切な列名を使用して申し訳ありません。

私の検索は次のとおりです。

select * from index_test r where r.value=56;
select * from index_test r where r.value=56 and r.text='dfs';
select * from index_test r where r.text='sdf';

いつ検索しても...

  1. 「テキスト」および/または「値」列のインデックスのみが表示される場合
  2. 結合された ('text' と 'value' を一緒に) インデックスが表示される場合

...だから、いつでも次の写真を見る：

整数列「値」の検索は

  • もっとゆっくり
  • 2 つの検索から結合されます: *index_test でのビットマップ ヒープ スキャン* および *idx_index_value でのビットマップ インデックス スキャン*

varchar カラム 'text' の検索は

  • もっと早く
  • 常にインデックス スキャンを使用する

String の検索が Integer の検索よりも簡単なのはなぜですか? 検索プランがそのように異なるのはなぜですか? この効果を再現でき、開発者に役立つ同様の状況はありますか?

4

1 に答える 1

4

テキストは定義上一意のハッシュであるため、そのテキストに一致するテーブルの 10,000 行には 1 行しかありません。

56 の値は、10k 行内に約 100 回存在し、テーブル全体に散らばっています。したがって、プランナーは最初にインデックスに移動し、それらの行があるページを見つけます。次に、散らばった各ページにアクセスして、行を取得します。

于 2013-03-18T16:37:18.200 に答える