2

最悪のシナリオ（可能な限りそれに近い）でSQLクエリのパフォーマンスを経験的にテストするために、いくつかのテーブルに大量のデータを入力したいと思います。

ランダムな値を使用することを検討しました。ただし、これを最悪の場合に近づけるには、手動で調整する必要があります。制約のないランダム値は、ほとんどが一意である傾向があるため、最悪の場合には適していません。この場合、単一の列のインデックスは、複合インデックスとほぼ同じように機能するはずです。一方、小さすぎるセットからランダムな値を選択すると、返される行の大部分が返されます。これは、リストのパフォーマンスほど検索のパフォーマンスを反映していないため、面白くありません。

EXPLAIN PLANだけを見ることも考えましたが、これは経験的なものではなく、最悪の場合ではなく、すでに持っているデータによっても説明が異なります。

特定のSQLクエリ（およびdbスキーマと理想的にはインデックス）を分析し、クエリを可能な限り最悪の場合に近い状態で実行する（特定のサイズの）大きなデータセットを生成するツールはありますか？

どのRDBMSでも問題ありません。

また、最悪の場合の行動についてこのレベルの洞察を得るための代替アプローチにも興味があります。

4

1 に答える 1

2

簡単な答え: 最悪のシナリオはありません。通常、同じ分布のデータを追加するだけで、すべてのケースがさらに悪化する可能性があるためです。

長い答え:

最悪のシナリオを探すのではなく、本番データから開始する「誇張された現実的なシナリオ」を探すことをお勧めします。大量のエンティティを (テーブルごとに個別に) 定義し、係数を掛けます。 2つか3つ、手元にある生産データからデータを生成します。

たとえば、生産データに 150 の自動車メーカーの 1000 の自動車モデルがあり、300 のメーカーの 10000 モデルが必要になると判断した場合、最初に参照テーブル (メーカー) のレコード数を 2 倍にしてから、「コピー」を生成します。既存の 1000 台の車のモデルを使用して、生成されたメーカーを参照して別の 1000 台の車を作成し、既存の車ごとにさらに 4 台の車を生成し、ケースバイケースの決定に基づいて既存の値の分布をコピーするたびに。これは、一部の列に新しい一意の値があり、他の列には単純に値がコピーされていることを意味します。

完了したら、統計を再生成することを忘れないでください。なぜ私はこれを言っているのですか？与えられたクエリ、データ、およびスキーマで可能な限り最適なクエリ プランをテストし、それを最適化したいためです。

根拠: クエリはアルゴリズムではありません。クエリ オプティマイザは、クエリだけでなく、テーブルのおおよその大きさ、インデックス カバレッジ、演算子の選択性などに関する情報にも基づいて、適切なクエリ プランを選択します。どのように選択が不十分な計画や、非現実的にデータが入力されたデータベースの計画が実行されるかを知ることには、あまり関心がありません。これにより、不適切に選択されたインデックスを追加する可能性さえあり、不適切に選択されたインデックスは本番環境のパフォーマンスを低下させる可能性があります。行数が多いにもかかわらず、現実的な最適な計画で何が起こるかを学び、テストしたいと考えています。

1,000,000 の自動車モデルでテストできますが、そのような実稼働コンテンツは、特定のデータベース スキーマとクエリの SF である可能性があります。ただし、データベース内の自動車メーカーの数と同じ数の自動車モデルでテストすることは、さらに役に立ちません。このような分布は、たまたまアプリケーションにとって最悪の分布になる可能性がありますが、メトリクスの基礎からはほとんど何も学べません。

于 2012-06-29T21:35:39.023 に答える