performance - すべて同じ列で始まる複数のインデックスがあると、Sybaseオプティマイザの速度または精度に悪影響がありますか？

Question

たとえば、5つのインデックス（1つはクラスター化）を含むテーブルがあります。

質問：5つのインデックスすべてが同じ正確なフィールドで始まる場合、オプティマイザーのパフォーマンス（インデックス選択の速度または精度）に何らかの悪影響を及ぼしますか？（他のすべてのものは等しい）。

会社の誰かから、パフォーマンスに悪影響を与える可能性があることが示唆されたため、インデックスの1つで最初の2つのフィールドを切り替える必要があります。

彼らは事実/理由で彼らの主張を裏付けなかったので、私は必要がなければ変更を避けたいと思いますが、その男は私が彼の提案を真剣に検討する傾向があるほど年配で賢いです。

注1：「where句と全体的なクエリに合わせてインデックスを調整する」という基本的な答えは役に立ちません。変更されるインデックスは、それを使用する唯一のクエリのカバーされたインデックスであり、したがって、その中のフィールドの順序はIO量には影響しません。その主張を確認するためだけに、別のSO質問をしました。

注2：そのフィールドはレコードが挿入された日付であり、これが重要な場合はテーブルがかなり大きくなります。約100日間のデータがあり、日付ごとの行数はほぼ同じです。最初のインデックスは、その日付フィールドで始まるクラスター化インデックスです。

Answer 1

オプティマイザは、インデックスが5つある場合に、どのインデックスを使用するかについてさらに検討する必要があります。そのコストは通常​​それほど悪くはありませんが、それはあなたがそれを求めているクエリに依存します。原則として、クエリが最適化されると、クエリの実行にかかる時間はほぼ同じになります。複数の用途のためにSELECTステートメントを準備している場合、それはそれほど重要ではありません。すべてのクエリが新たに準備され、再利用されない場合、オーバーヘッドがシステムパフォーマンスの低下になる可能性があります。特に、ほとんどのクエリで実際にどのインデックスが使用されているかは問題ではないことが判明した場合は、中程度の危険性があります。 5つのインデックスはすべて同じ先頭の列を共有します）。

データが変更された場合のメンテナンスコストもあります。5つのインデックスの更新には、1つのインデックスよりも著しく長い時間がかかります。さらに、5つのインデックスに1つのインデックスの約5倍のディスクストレージを使用しています。

Answer 2

私はあなたの先輩の同僚のために話すことを望んでいませんが、あなたは彼が言ったことを誤解したか、あなたが理解するのに十分なほど明確に自分自身を表現していないと思います。

設計が不十分でパフォーマンスが低いテーブルで際立っている点の1つは、テーブルに多くのインデックスがあり、インデックスの先頭の列がすべて同じであるということです。毎回。

したがって、すべて同じ先頭の列を持つインデックスのサーバーコストがあるかどうかは、無意味な議論です（議論はあまりにも孤立しています）。問題は、無数の方法でそれ自体を公開する不十分に設計されたテーブルです。これは、すべてのアクセスで莫大なサーバーコストになります。それがあなたの尊敬する同僚の出身だったのではないかと思います。

インデックスの単調な列は、インデックスの選択としては非常に不適切です（理解されているように、少なくとも1つは必要です）。しかし、その単調な列を使用して、他のインデックスで一意性を強制する場合、それ以外の場合は無関係になります（SexCodeなどのカーディナリティが低いため）。これは、私にとってもう1つの危険信号です。関連性のないインデックスをわずかに関連性のあるものにするように強制しただけです）。対象となる単一のクエリを除いて、クエリは、主キーを介した最も単純な選択以外のクエリではパフォーマンスが低下します。

「対象インデックス」というものはありませんが、あるクエリが対象クエリとして実行されるようにインデックスを追加しました。別の旗。

私はミッチと一緒ですが、あなたが彼のドリフトを得るかどうかはわかりません。

最後に、質問に個別に回答し、先頭の列がすべて同じである5つのインデックスを使用しても、テーブルデザインが不十分なためにすでに発生している問題を超えて、「パフォーマンスの問題」は発生しませんが、不安と不必要な手作業が発生します。 「オプティマイザーがクエリにindex_1を使用したのに、今日はindex_4を使用しているのはなぜですか？」などの奇妙な動作を追跡している開発者向けです。

あなたの言語は一貫して（そして特にコメントで）問題を分離して扱う方法を示しています。サーバーとデータベースの概念は、それが共有の中央リソースであり、分離とは正反対であるということです。単独で「解決」された問題は、通常、その隔離されたスペースの外にいるすべての人にパフォーマンスへの悪影響をもたらします。

問題を本当に処理したい場合は、CREATETABLEステートメントを完全に投稿してください。

Answer 3

SELECTのパフォーマンスに大きな影響を与えるとは思えません。

ただし、おそらく、これらのインデックスを（代表的なクエリワークロードに基づいて）再編成して、クエリをより効率的に処理できることを意味します。

Answer 4

私はSybaseの最近のバージョンに精通していませんが、一般にすべてのSQLサーバーで、パフォーマンスに影響を与える主な（そしてほとんど）唯一のインデックスは、INSERT、DELETE、およびUPDATEクエリを使用することです。基本的に、データベースを変更するたびに、データテーブル自体（またはクラスター化インデックス）とすべてのインデックスを更新する必要があります。

SELECTクエリに関しては、「多すぎる」インデックスを使用すると、たとえば、キャッシュ用に競合するハードディスクページを導入するなど、パフォーマンスにわずかな影響を与える可能性があります。しかし、ほとんどの場合、これが重要な問題になるとは思えません。

これらすべてのインデックスの最初の列が日付であり、日付値の一般的に単調な進行を想定しているという事実は、インデックステーブルを分割/バランス調整する必要性を維持するため（CRUD操作に関して）ポジティブなことです。最小限。（ほとんどの場合、インデックスの最後に挿入されるため）。

また、このテーブルは十分に小さいように見えます（ "big"は相対的な単語です;-)）。パフォーマンスの問題をより体系的に主張するための実験は、本番環境にあまり干渉することなく、比較的安全かつ簡単に実行できる可能性があります。（10k程度のレコードが非常に広い場合、または1秒あたりのクエリ率が高い場合などを除きます。）