合計時間の75％を使用するクエリ「Creating Sort Index」のMySQLプロファイル

クエリを最適化する方法（約100ミリ秒かかる）と、合計時間Creating Sort Indexを使用して表示される実行プロファイルを理解しようとしています75%。まず、ソートインデックスの作成に正確に影響するものは何ですか。disk / ioですか？

次に、クエリ自体に最適化できるものはありますか？

SELECT r.`id`, 
       r.name, 
       r.public_uri, 
       rv.version, 
       rv.interpreter, 
       rv.notes, 
       rv.content, 
       r.added, 
       r.added_by, 
       r.modified, 
       r.modified_by, 
       r.public, 
       r.public_by
  FROM recipe_heads rh, 
       recipes r, 
       recipe_versions rv
 WHERE rh.recipe = r.`id` 
   AND rh.recipe_version = rv.`id` 
   AND r.`id` = rv.recipe
ORDER BY r.added DESC

説明：

巨大なクエリについても同様の問題がありました。多くの場合、クエリは、4億行のDBの負荷に応じて、数時間（最大7〜8）実行されました。ただし、私たちの目標は、select col1、col2、col3、count（1）、count（distinct col4）などのグループ結果をテーブルグループから1,2,3で達成することでした。

根本的な問題はあなたの問題と同じですが、どちらの場合もDBは結果を内部的にソート（順序付け）します。

• ソートインデックスの作成方法。mysqlのWebサイトでは、「スレッドは内部一時テーブルを使用して解決されるSELECTを処理しています」と述べています。私のアルゴリズムの理解によれば、システムはおそらくデータをチャンクに分割し、ディスクからこのチャンクを1つずつ読み取り、個々のチャンクを並べ替え、一時的なディスク領域に戻すなどです。システムはすべてのチャンクに対してこれを行い、最終的にマージソートを実行します。これには、広範な読み取り/書き込みが含まれます。

可能な解決策は、DBのメモリを増やす（メモリ内に留まることができる大きなチャンクを作成できるようにする）か、他のどこかに大きなメモリがある場合は、DBからストリーミングすることでソリューションをプログラムできます。これはnlogn時間で達成できます。

プログラム的には、時間を平均2時間から一貫して7.5分に短縮できました。

「ソートインデックスの作成」は、「order by」句に基づいて戻り値の順序を決定するデータベースです。ここでの主な制限は、使用可能なCPU / CPU速度、およびメモリ帯域幅です。少なくともこの小さなクエリでは、データがすべてメモリに格納されるまで、並べ替えは行われません。クエリをプロファイリングすると、リソースの待機が表示されますか？

このクエリを高速化するには、「r.added」にインデックスを追加することを検討してください。説明によると、インデックスが存在しないようです。