総評
以上,
- 結論1:とりあえずB-treeインデックスを使って大敗することはない。
B-treeはバランスのとれたオールラウンダーですので,
一方,
- 結論2:等値条件で性能を追求したいならハッシュを使いなさい。ただし大敗も覚悟しなさい。
ハッシュが効果を発揮するのは,
ハッシュを使うときは,
終わりに
さて,
これはちょっと酷い問いに聞こえるかもしれませんが,
逆に言うと,
でも,
では最後に,
演習問題
- 演習1.
多くのDBでは,
主キーや一意キー制約を作成すると, 対象の列にB-treeインデックスが暗黙に作成されます。これはなぜでしょう。 - 演習2.
もしハッシュ関数が不運にもすべてのキーについて衝突を起こした最悪の場合,
検索にかかる計算量はどうなるでしょう。 - ※ 回答は,
筆者のWebページ内にある “ 「SQLアタマアカデミー」 ”サポートページ に掲載しています。
- ※ 回答は,
- 注5)
- 「試験の結果,
PostgreSQLのハッシュインデックスの性能はB-treeインデックスより悪く, また, ハッシュインデックスのインデックスサイズと構築時間もかなり劣っていることが分かりました。……これらの理由により, ハッシュインデックスの使用は現在お勧めできません。」 (「11. 2. インデックスの種類」 『PostgreSQL8. 3.6文書』) - 注6)
- ときどき,
インデックスを何十個も作成しているシステムを見かけることがありますが, 無目的にインデックスを乱発するのは, かえってDBのオプティマイザを混乱させ, 更新処理に無用の負荷をかける愚行です。
参考資料
- R.
Bayer 『B-tree and UB-tree』 - B-tree とB+tree の考案者Bayer 自ら監修した,
ScholarpediaのB-treeについての記事です。発明者本人の説明ですので, 正確でわかりやすく, B-treeインデックスについて学びたい人すべてにお勧めです (でも 「B」 がどういう意味かはやっぱり教えてくれない)。本稿のBayerの言葉はすべて, この記事からの引用です。 - Postgre SQLグローバル開発グループ
『Postgre SQL 8. 3.6文書』 - 「第11章 インデックス」
には, Postgre SQLに限らず, 一般的に当てはまるインデックスについてのコンパクトな解説があり, 有用です。