データベースが独自のインデックスを自動的に作成しないのはなぜですか？

データベースは、頻繁に発生するものについて十分に認識し、非常に要求されたデータにインデックスを追加することを決定できるという下に置かれた要求に対応できると考えていたでしょう。

更新

これは、SQL Server Azureに実装されました。推奨事項を生成します

また、インデックス管理を自動に構成できます。

自動インデックス管理を有効にする

SQL Database Advisorを設定して、推奨事項を自動的に実装できます。推奨事項が利用可能になると、それらが自動的に適用されます。サービスが管理するすべてのインデックス操作と同様に、パフォーマンスへの影響がマイナスの場合、推奨事項は元に戻ります。

元の回答

一部のデータベースでは、すでに（種類の）インデックスが自動的に作成されます。

SQL Serverでは、RDBMSが動的にデータのインデックス付きコピーを作成するインデックススプール演算子を実行計画に含めることができます。ただし、このスプールはソースデータと同期して保持されるデータベースの永続的な部分ではなく、クエリの実行間で共有できません。つまり、そのようなプランの実行は、同じデータの一時インデックスの作成と削除を繰り返し行う可能性があります。

おそらく将来的には、RDBMSには、ワークロードに応じて永続的なインデックスを動的に削除および作成する機能が搭載される予定です。

インデックス最適化のプロセスは、最終的には単なる費用便益分析にすぎません。原則として、ワークロードでのクエリの相対的な重要性について人間がより多くの情報を持っている可能性があるのは事実ですが、オプティマイザーがこの情報を利用できない理由はありません。SQL Serverには、優先度に応じて異なるリソース割り当てを持つ異なるワークロードグループにセッションを分類できるリソースガバナーが既にあります。

Kennethが言及した欠落インデックスDMVは、特定のクエリに対する利点のみを考慮し、他のクエリに対する潜在的なインデックスのコストを考慮に入れないため、盲目的に実装することを意図していません。同様の欠落しているインデックスも統合しません。例えば、このDMVの出力は上のインデックスが不足して報告することがありますA,B,Cし、A,B INCLUDE(C)

アイデアに関するいくつかの現在の問題は

• 実際にインデックスを作成しない自動分析の品質は、原価計算モデルの精度に大きく依存します。
• 自動分析の分野内であっても、オフラインソリューションはオンラインソリューションよりも徹底的であることができます。オンラインソリューションは、ライブサーバーにオーバーヘッドを維持する大きな本を追加し、クエリを実行する主な目的を妨げるべきではないためです。
• ワークロードに応じて自動的に作成されるインデックスは、それらが有用であることがわかったクエリに応じて必ず作成されるため、事前にインデックスを作成するソリューションよりも遅れます。

原価計算モデルの精度が時間の経過とともに向上することを期待することはおそらく合理的ですが、ポイント2は解決が難しく見え、ポイント3は本質的に不溶性です。

それでもおそらく、インストールの大部分は、ワークロードの変化を継続的に監視、診断、予測（または少なくとも反応）する熟練したスタッフがいる理想的な状況ではありません。

Microsoft Research のAutoAdminプロジェクトは1996年から実行されています

このプロジェクトの目標は、ワークロードの知識を活用して、データベースを自己調整および自己管理することです。

プロジェクトのホームページには、いくつかの興味深いプロジェクトがリストされています。ここでの質問に特に関連するのは

別の興味深い問題は、DBAが利用できない場合に発生します（組み込みデータベースや小規模企業など）。このようなシナリオでは、低タッチの連続インデックスチューニングアプローチが重要になる場合があります。ソリューションを調査しました... [in] ICDE 2007の「物理設計チューニングへのオンラインアプローチ」。

著者は述べています

オンラインインデックスのようなますます一般的なDBMS機能により、最先端の技術を進歩させる物理設計の問題に対するより自動化されたソリューションを探求することは魅力的です。

論文ではアルゴリズムを紹介しています

主な特徴は次のとおりです。

• クエリが最適化されると、パフォーマンスを改善する関連する候補インデックスのセットを特定します。この機能により、クエリ処理は、バックグラウンドで構築されたインデックスと並行して続行できます。
• 実行時に、このような候補インデックスがないことによって失われる潜在的な利点を追跡し、クエリ、更新、およびスペースの制約がある場合に既存のインデックスの有用性も追跡します。
• 物理的な設計変更が有益となる十分な「証拠」を収集した後、インデックスの作成または削除を自動的にトリガーします。
• 私たちの問題のオンライン性は、将来を知っている最適なソリューションに一般的に遅れることを意味します。ただし、エビデンスを慎重に測定することにより、「後期」の決定に著しく影響されないようにし、発生する損失の量を制限しています。

アルゴリズムの実装により、サーバーの負荷の変化に応じた調整が可能になります。また、作成中にワークロードが変化し、期待されるメリットが価値があると見なされるポイントを下回る場合、インデックスの作成を中止できます。

オンライン対従来の物理的チューニングのトピックに関する著者の結論。

この作業のオンラインアルゴリズムは、DBAがワークロードの将来の動作について不明な場合、または包括的な分析やモデリングを行う可能性がない場合に役立ちます。DBAがワークロードの特性に関する完全な情報を持っている場合、既存のツール（例[2、3]）による静的分析と展開がより良い代替手段となります。

ここでの結論は、別の論文「自律クエリ駆動型インデックスチューニング」の結論と似ています。

ワークロード全体が事前にわかっている場合、このアプローチはインデックスアドバイザーに勝るものはありません。ただし、ワークロードが進化および変化する動的環境では、クエリ駆動型アプローチの方が優れた結果をもたらします。

適切なインデックスデザインは、科学というよりも芸術のようなものです。RDBMSは、一般的なワークロードを取り込んで、スマートなインデックス作成戦略を設計するほどスマートではありません。ワークロードを分析し、最適なアプローチを決定するのは人間の介入です（DBAを参照）。

インデックスを作成してもペナルティがなければ、無限数のインデックスを追加するだけのショットガンアプローチになります。ただし、データの変更（INSERTS、UPDATES、およびDELETES）はテーブルで有効なインデックスに影響を与えるため、これらのインデックスの変数オーバーヘッドが発生します。

データ変更のオーバーヘッドを最小限に抑えながら、読み取りパフォーマンスを最大化するインデックスをスマートに作成するには、人間の設計と戦略が必要です。

実際、これを行うデータベースがいくつかあります。たとえば、GoogleのBigTableとAmazonのSimpleDBは自動的にインデックスを作成します（どちらもRDBMSのインデックスではありません）。これを行う少なくとも1つのMySQL RDBMSエンジンもあります。SQL Server は、作成する必要があると考えているインデックスも追跡しますが、実際にインデックスを作成することはありません。

問題を修正するのは驚くほど難しいので、ほとんどのデータベースが自動的に作成しないのも不思議ではありません（BigTable / SimpleDBは、任意の結合を許可しないため、問題を大幅に軽減します）。また、インデックスをオンザフライで作成することは、テーブル全体への排他的アクセスを必要とする時間のかかるプロセスです。テーブルがオンラインの間に起こることは間違いありません。

ただし、インデックスが何であるかさえ知らないアマチュアによって書かれたLAMP Webアプリケーションの数を考えると、この機能は一部の人々にとって有益だと思います。

すでにいくつかの広範な答えがありますが、彼らは本当の答えを回避しているようです：インデックスは常に望ましいとは限りません。

コメントで言及された車の類推で、なぜすべての車が極端なスポーツパッケージに適合していないのかを言った方が良いでしょうか？部分的には費用がかかりますが、多くの人がロープロファイルタイヤやロックハードサスペンションを必要としない、または欲しくないという事実もあります。不必要に不快です。

挿入ごとに1,000回の読み取りがあるとしたら、自動作成されたインデックスがないのはなぜですか？テーブルの幅が広く、クエリがさまざまな場合は、複数のクエリがないのはなぜですか？たぶん、コミットは時間的に重要であり、読み取りはそうではありません。状況によっては、挿入を遅くすることは受け入れられないかもしれません。たぶんあなたは限られたディスクスペースで作業していて、あなたが持っているスペースに食い込む追加のインデックスを持つ余裕がないかもしれません。

ポイントは、インデックスはすべてに対する答えではないため、自動的に作成されないことです。インデックスの設計は、単に「これで私の読み取りが高速化される」と言うだけの場合ではなく、考慮すべき他の要因があります。

過去のクエリを分析し、インデックスを提案/作成することはできますが、インデックスがバランスをとって最適化を高速化するためにコストがかかり、サーバーが意図を認識できないため、これは最適に機能しません。

スマートではなく、コードの一部です。データベースに新しいデータを入力するたびに、データベースに新しい場所と、要求されたときにそれを見つけるためのマップを見つける必要があります。インデックス作成はそれよりも簡単に聞こえますが、新しいデータのチャンクに新しい番号を付けるだけですか？さて、次のクエリがデータの最後のチャンクではなく、約36271チャンク前の場合はどうでしょうか。インデックスで簡単に見つけることができますよね？しかし、1997年に作成された古い36271チャンクで見つかった「fishing」などの単語がクエリに含まれている場合はどうでしょうか。ほ？古い記事には釣りについての言葉はありません。

データが1つずつデータベースに届くと、そのようにインデックスを付けることができます。しかし、単純な索引付けでは、結果が間違ったり、パフォーマンスが遅くなったりすることがあります...