2011-03-03 10 views
2

MySQLのバックグラウンドはありません。MySQLのクエリオプティマイザとディスクアクセスのコストに与える影響を誰にでも分かりやすく知りたいクエリ実行のクエリプラン。 ディスクアクセス時に収集された統計情報が、固定された一連のクエリのクエリ実行計画に影響を与えるかどうかに関心があります。特に、さまざまなパフォーマンスの異なるドライブに存在する同じデータベース・イメージに対して同じ一連の照会を実行する場合。 (MySQLの観点から見ると、これは同じデータベースであり、データディレクトリは単純に、MySQLの "下位"に知られていない別のドライブに置かれています)。観察されたディスクパフォ​​ーマンスの変化は、クエリオプティマイザが実行時に行うクエリプランの決定に影響を与える可能性がありますか? ディスクアクセスを考慮する前にオプティマイザが行うことができるSQL自体には、他にも多くのことがあると思いますが、私よりもクエリオプティマイザの方がずっと経験が豊富です。MySQLのクエリオプティマイザがディスクへのアクセスにかかる時間

ありがとうございました!

+0

残念ながら、私はそれを確認するためにソースしていないが、私は、そのような統計は、MySQLのによって収集されていないことはほぼ確信しています。私が知る限り、mysqlperformanceblog.comには、SSDドライブへのMySQLオプティマイザの時代遅れのアプローチに関する記事がありました(彼らは、ランダムI/Oの書き込み/読み込みコストはMySQLソースでハードコードされていると述べました)。 – matt

答えて

1

MySQLでのpyhsical I/Oアクセスの最適化についてはわかりません。 しかし、クエリオプティマイザは、クエリの実行に必要なI/O(ブロック数など)を最小限に抑えようとします。

メモリとセカンダリI/Oシステム間の速度のギャップは非常に大きいため、メモリ内に有効なキャッシュを保持することは、ほとんどのリレーショナルデータベースシステムでパフォーマンスの重要な問題です。

したがって、クエリー計画では、必要なI/Oをできるだけ少なくする必要がありますが、デバイスはすばやくあります。

<Query Result> <--[Logical I/O]-- <Main Memory> <--[Physical I/O]-- <Secondary I/O System>

+0

さて、クエリオプティマイザでは、ディスクI/Oについて多くの前提が必要です。少なくとも古いルール "行の1/3以上がwhere句でヒットしたように見える場合は、索引を使用せず、代わりに全表スキャンを実行します"ランダムアクセスのy個のブロックよりも "。クエリプランの他の部分も異なるはずです。 –

関連する問題