データベースが独自のインデックスを自動的に作成しないのはなぜですか？
データベースは、頻繁に遭遇することについて十分に理解しており、要求の多いデータにインデックスを追加することを決定できるという、それらが課されている要求に応答できると思っていただろう。
更新
これはSQL Server Azureに実装されています。推奨事項を生成します
インデックス管理 自動に設定できます 。
自動インデックス管理を有効にします
SQL Database Advisorを設定して、推奨事項を自動的に実装できます。推奨事項が利用可能になると、それらは自動的に適用されます。サービスによって管理されるすべてのインデックス操作と同様に、パフォーマンスへの影響がマイナスの場合、推奨は元に戻されます。
元の回答
一部のデータベースは、インデックスを（自動的に）作成しています。
SQL Serverでは、実行プランに Index Spool 演算子を含めることができ、RDBMSがデータのインデックス付きコピーを動的に作成します。ただし、このスプールは、ソースデータとの同期を維持するデータベースの永続的な部分ではなく、クエリの実行間で共有することはできません。つまり、そのようなプランの実行は、同じデータに対して一時的なインデックスを繰り返し作成および削除することになります。
おそらく将来のRDBMSは、ワークロードに応じて永続的なインデックスを動的に削除および作成する機能を持つでしょう。
インデックスの最適化のプロセスは、最終的には単なる費用対効果の分析です。人間がワークロード内のクエリの相対的な重要性についてより多くの情報を持っている可能性があることは事実ですが、オプティマイザがこの情報を利用できない理由はありません。 SQL Serverには既にリソースガバナーがあり、セッションを優先順位に従って異なるリソース割り当てで異なるワークロードグループに分類できます。
Kennethによって言及された欠落したインデックスDMVは、特定のクエリの利点のみを考慮し、他のクエリに対する潜在的なインデックスのコストを考慮に入れないため、盲目的に実装することを意図していません。また、同様の欠落したインデックスを統合することもしません。例えばこのDMVの出力は、_A,B,C_およびA,B INCLUDE(C)で欠落しているインデックスを報告する場合があります
アイデアに関するいくつかの現在の問題は
- 実際にインデックスを作成しない自動分析の品質は、原価計算モデルの精度に大きく依存します。
- 自動化された分析の分野でも、オフラインのソリューションはオンラインソリューションよりも徹底することができます。オンラインソリューションは、ライブサーバーに大きな本を保管するオーバーヘッドを追加し、クエリを実行する主な目的を妨げないようにする必要があるためです。
- ワークロードに応じて自動的に作成されたインデックスは、それらが有用であると判断されたクエリに対応して必ず作成されるため、事前にインデックスを作成するソリューションよりも遅れます。
時間の経過とともにコストモデルの精度が向上することを期待するのはおそらく妥当ですが、ポイント2は解決が難しく、ポイント3は本質的に不溶性です。
それにもかかわらず、インストールの大部分は、ワークロードの変化を継続的に監視、診断、および予測（または少なくともそれに対応）する熟練したスタッフによる理想的な状況ではないでしょう。
Microsoft Researchの AutoAdminプロジェクト は、1996年から実行されています
このプロジェクトの目標は、ワークロードの知識を活用して、データベースを自動調整および自動管理できるようにすることです
プロジェクトのホームページには、いくつかの興味深いプロジェクトがリストされています。 1つは特にここの質問に関連しています
別の興味深い問題は、DBAが利用できない場合に発生します（たとえば、組み込みデータベースや小規模ビジネス）。このようなシナリオでは、ロータッチの連続インデックスチューニングアプローチが重要になる場合があります。 ICDE 2007でソリューションを調査しました... [in]「 物理設計調整へのオンラインアプローチ 」。
著者は述べる
オンラインインデックスなどのDBMS機能がますます一般的になっているため、最新の技術を進歩させる物理的な設計問題の自動解決策を模索することは魅力的です。
論文はアルゴリズムを紹介します
主な特徴は次のとおりです。
- クエリが最適化されると、パフォーマンスを向上させる候補となるインデックスの関連セットが特定されます。この機能により、バックグラウンドで構築されたインデックスと並行してクエリ処理を続行できます。
- 実行時に、そのような候補インデックスがないことによって失う潜在的な利益と、クエリ、更新、およびスペース制約がある場合の既存のインデックスの有用性を追跡します。
- 物理的な設計変更が有益であるほどの「証拠」を収集したら、インデックスの作成または削除を自動的にトリガーします。
- 私たちの問題のオンラインの性質は、将来を知る最適なソリューションよりも一般的に遅れることを意味します。ただし、証拠を慎重に測定することにより、「後期」の決定に大きく影響されないようにし、発生する損失の量を制限します。
アルゴリズムの実装により、サーバーの負荷の変化に応じてスロットリングが可能になり、作成中にワークロードが変更され、期待されるメリットが価値があると見なされるポイントを下回った場合に、インデックスの作成を中止できます。
オンライン対従来の物理的チューニングのトピックに関する著者の結論
この作業のオンラインアルゴリズムは、DBAがワークロードの将来の動作について不明な場合、または包括的な分析やモデリングを行う可能性がない場合に役立ちます。 DBAがワークロードの特性に関する完全な情報を持っている場合は、静的分析と既存のツール（[2、3]など）による展開がより良い代替手段となります。
ここでの結論は、別の論文の結論と同様です 自律型クエリ駆動型インデックスチューニング
ワークロード全体が事前にわかっている場合、私たちのアプローチはインデックスアドバイザーに勝るものはありません。ただし、ワークロードが進化および変化する動的環境では、クエリ駆動型のアプローチがより良い結果を生み出します。
配置したインデックスのデザインは、科学というよりアートのようなものです。 RDBMSは、一般的なワークロードを処理し、スマートなインデックス作成戦略を設計するには十分にスマートではありません。ワークロードを分析し、最適なアプローチを決定するのは、人間の介入（読み取り：DBA）です。
インデックスを使用することによるペナルティがない場合、無限のインデックスを追加するだけのショットガンアプローチになります。ただし、データの変更（INSERTS、UPDATES、およびDELETES）は、テーブルで有効になっているインデックスに影響を与えるため、これらのインデックスのオーバーヘッドが変動することになります。
データ変更のオーバーヘッドを最小限に抑えながら、読み取りパフォーマンスを最大化するインデックスをスマートに作成するには、人間の設計と戦略が必要です。
実際、これを行うデータベースがいくつかあります。たとえば、 GoogleのBigTable および AmazonのSimpleDB は、自動的にインデックスを作成します（どちらもRDBMSではありません）。これを行う 少なくとも1つのMySQL RDBMSエンジン もあります。 SQL Serverも 作成する必要があると考えるインデックスを追跡します ですが、実際に作成するまではいきません。
この問題を修正するのは驚くほど難しいので、ほとんどのデータベースが自動的に作成しないことは不思議ではありません（BigTable/SimpleDBは、任意の結合を許可しないため、事態を大幅に容易にします）。また、オンザフライでインデックスを作成するのは時間のかかるプロセスであり、テーブル全体に排他的にアクセスする必要があります。テーブルがオンラインのときに発生することは間違いありません。
しかし、どのようなインデックスも知らないアマチュアによって書かれたLAMP Webアプリケーションの数isを考えると、この機能は一部の人にとっては有益だと思います。
すでにいくつかの広範な回答がありますが、それらは実際の回答を回避しているようです：インデックスは必ずしも望ましいとは限りません
コメントで言及された自動車の類推で、なぜすべての自動車がエクストリームスポーツパッケージを装備しているわけではないのかを言う方が良いでしょう。それは費用の一部ですが、多くの人々がロープロファイルタイヤとロックハードサスペンションを必要としないか、または望んでいないという事実にかかっています。不必要に不快です。
つまり、挿入ごとに1,000回の読み取りがある場合、自動作成されたインデックスがないのはなぜですか？テーブルの幅が広く、クエリが多様である場合、いくつかあるのではないでしょうか。おそらく、コミットはタイムクリティカルであり、読み取りはそうではありません。状況によっては、挿入速度を遅くすることは許容できない場合があります。たぶんあなたは限られたディスクスペースで作業していて、あなたが持っているスペースに追加のインデックスを食べる余裕はありません。
重要なのは、インデックスはすべてに対する答えではないため、自動的に作成されないということです。インデックスを設計することは、単に「これで私の読み込みが速くなる」と言うだけではなく、考慮すべき他の要因があります。
彼らは過去のクエリを分析し、インデックスを提案/作成できますが、インデックスは最適化したいものをスピードアップするためにバランスをとるコストでであり、サーバーはあなたの意図を知ることができないため、これは最適に機能しません。