クエリの最適化で等深度ヒストグラムが果たす役割を理解できません。誰かが私に良いリソースへのいくつかのポインタを教えてもらえますか、または誰かが説明できますか？私はいくつかの研究論文を読みましたが、それでも等深度ヒストグラムの必要性と使用について自分を納得させることができませんでした。それで、誰かが例で等深さのヒストグラムを説明できますか？
また、ヒストグラムのバケットをマージして、ヒストグラムが十分に小さくなり、ディスク上の1ページに収まるようにすることもできますか？
また、等深度ヒストグラムのバケット境界とは何ですか？
警告：私はデータベース内部の専門家ではないので、これは一般的な答えであり、具体的な答えではありません。
クエリコンパイラは、通常SQLで指定されるクエリを、結果を取得するためのプランに変換します。計画は、データベースエンジンへの低レベルの「指示」で構成されます。テーブルTをスキャンして、列Cの値Vを探します。テーブルTのインデックスXを使用して、値Vを見つけます。等
クエリの最適化とは、（潜在的に巨大な）代替クエリプランのセットのどれが最小コストであるかをコンパイラが決定することです。コストには、実時間、IO帯域幅、中間結果ストレージスペース、CPU時間などが含まれます。概念的には、オプティマイザーは代替プランスペースを検索し、検索をガイドするためにそれぞれのコストを評価し、最終的に見つけることができる最も安いものを選択します。
上記のコストは、読み取りおよび/または書き込みが行われるレコードの見積もり、レコードをインデックスで検索できるかどうか、それらのレコードのどの列が使用されるか、データのサイズやディスクページの数によって異なります。彼らは占領します。
これらの量は、多くの場合、テーブルに格納されている正確なデータ値に依存します。たとえば、インデックス付きの列select * from data where pay > 100がどこにあるかを考えてみます。pay支払い列に100を超える値がない場合、クエリは非常に安価です。インデックスの単一のプローブがそれに答えます。逆に、結果セットにはテーブル全体が含まれる可能性があります。
これは、ヒストグラムが役立つところです。（等深さのヒストグラムは、ヒストグラムを維持する1つの方法にすぎません。）前のクエリでは、ヒストグラムはO（1）時間で、それらの行に何が含まれるかを正確に知らなくても、クエリによって生成される行の割合の推定値を提供します。 。
事実上、オプティマイザーはデータの抽象化に対してクエリを「実行」しています。ヒストグラムはその抽象化です。（他の方法も可能です。）ヒストグラムは、クエリプラン操作のコストと結果サイズを見積もるのに役立ちます。たとえば、大量の挿入と削除（一時的なインデックスの生成につながる可能性があります）中の結合結果のサイズとページヒットです。
単純な内部結合の例として、2つのテーブルの整数値の結合列がどのように分散されているかがわかっているとします。
Bins (25% each)
Table A Table B
0-100 151-300
101-150 301-500
151-175 601-700
176-300 1001-1100
表Aの50％と表Bの25％が参加の可能性を反映していることは容易に理解できます。これらが一意の値の列である場合、有用な結合サイズの見積もりはmax（.5 * | A |、.25 * | B |）です。これは非常に単純な例です。多くの（ほとんどの？）ケースでは、分析にははるかに高度な数学的知識が必要です。結合の場合、通常、オペランドのヒストグラムを「結合」することにより、結果の推定ヒストグラムを計算します。これが、文学を非常に多様で、複雑で、興味深いものにしている理由です。
博士論文には、このような技術文献の大部分を、読むのがそれほど難しくない簡潔な形式でカバーする調査が含まれていることがよくあります。（結局のところ、候補者は、彼/彼女が文献検索を行う方法を知っている委員会を説得しようとしています。）これ はそのような例の1つです。