データベースクエリオプティマイザーはストレージパフォーマンスの違いを認識していますか？

私が理解しているように、SQL Server（または実際には他のRDBMS）のクエリオプティマイザーは、データベースの下のストレージのパフォーマンスを認識せず、すべてのストレージのコストが等しいかのように判断します。それは正確ですか、または考慮に入れられているストレージパフォーマンスの知識はありますか？

完全に不自然な例で、テーブルの行が瞬時のアクセス時間でSANのSSDドライブに保存されているとしましょう。インデックスは極端に過負荷のSASドライブに保存されているため、ディスクが飽和状態になり、ディスクキューが一定になります。RDBMSが実行プランを生成するとき、インデックス操作よりもテーブルスキャンを優先する可能性が高いですか（または、SASディスクでのIOが少ないため、カバーするインデックスとは対照的に、スキニーインデックスおよび関連するテーブルルックアップ）。

その答えは確かなものだと思いますが、「オプティマイザが賢くなったり、ディスクパフォ​​ーマンスを認識したりする可能性はない」と思いますが、そこにいる誰かが確かに知っているかどうかを確認したかっただけです。SQL Serverを使用していますが、どのデータベースシステムにも興味があります。

SQLサーバーのクエリオプティマイザーは、クエリプランのコンパイル時にディスクパフォ​​ーマンスの変動を考慮しません。ポールホワイトは、SQL Serverのコストベースのオプティマイザの優れた概要をここに示します。

https://sqlkiwi.blogspot.com/2010/09/inside-the-optimizer-plan-costing.html

主なポイントは次のとおりです。

• オプティマイザはプランの正確なコストを計算しようとはしていません。それはいくつかの選択肢の中で相対的に最低のコストで計画を選択しようとしています。

• それは現実を単純化した見方です。サーバーが320 io /秒を実行でき、そのCPUパフォーマンスが10年以上増加していないことを前提としています。

• 今日のサーバーのパフォーマンス特性は大きく異なりますが、ほとんどの場合、オプティマイザは依然として非常に優れています。

では、なぜマイクロソフトはオプティマイザに追加のインテリジェンスを追加しないのですか？ただし、将来的には、個々のイテレータのコストを少し調整する可能性が高くなります。現在、そのメリットを正当化するためのメリットはありません。

ドキュメントに記載されていないdbcc呼び出しを使用して、クエリオプティマイザーの想定の一部を変更できます。これらを本番サーバーで使用しないでください

DBCC SETIOWEIGHT(<multiplier>)
DBCC SETCPUWEIGHT(<multiplier>)

どちらもデフォルト値は1です。それらを試して、ほとんどの場合に一貫してより良い計画を生成するさまざまな値を考え出せるかどうかを確認してください。小さな変更では大部分の計画は変更されず、大きな変更では本当に奇妙な計画が生成されることがわかります。

SQLはプランのコンパイル時にioのパフォーマンスを考慮しませんが、プランの実行中はioのパフォーマンスに応答します（ioが飽和している場合は先読みを制限します）。

Db2 for LUWクエリオプティマイザーは、それが実行されているマシンのハードウェアパフォーマンス特性を認識し、それらを考慮に入れます。

具体的には、各テーブルスペースには、基になるストレージパフォーマンスを反映する2つの数値パラメーターがありますoverhead。これは、I / Oコントローラーのオーバーヘッドとディスクシークと待ち時間（ミリ秒）を反映し、transferrate1つのテーブルスペースページをディスクからメモリに転送するのに必要な時間を示します。

これらのパラメーターは、表スペースの作成時に指定して、ヒューリスティックに導出されたデフォルト値をオーバーライドできます。

I / Oパフォーマンスパラメーターは、cpu_speedデータベースマネージャーレベルのパラメーターと共に、オプティマイザーによって各クエリプランオペレーターのI / OおよびCPUコストを計算するために使用されるため、最終的に選択されるプランに影響します。その後、あなたのシナリオはDb2で完全にもっともらしくなります。同様に、CPU速度が非常に高く、ディスクパフォ​​ーマンスが非常に高いシステムでは、オプティマイザはI / O集約型の演算子（インデックスベースのテーブルアクセスなど）よりもCPU集約型の演算子（テーブルスキャンと並べ替えなど）を優先する場合があります。

Db2 for z / OSも、基盤となるハードウェアパフォーマンス特性を同様に考慮し、データベース構成の一部としてではなく、ストレージ管理レイヤーから取得すると思います。