tmp_table_sizeおよびmax_heap_table_size MySQLプロパティの経験則
タイトルは質問自体をかなり要約しています：tmp_table_sizeおよびmax_heap_table_size MySQLプロパティの値に関する経験則はありますか？
MySQLがディスクスペースを使用してJOIN結果をファイルソートするという事実が原因で、パフォーマンスが大幅に低下しました。
tmp_table_sizeとmax_heap_table_sizeを3Gに増やすと問題が解決しましたが、これは試行錯誤によるアプローチです。
これらの2つの適切な値を計算するより確実な方法はありますか？
それぞれにメモリの1％をお勧めします。
_
max_heap_table_size_は、_ENGINE=MEMORY_テーブルのCREATEに対する制限です。そのエンジンを使用する人は多くありません。使用する場合は、作成を行う直前に最大サイズを設定してください。LEAST(max_heap_table_size, tmp_table_size)は、特定の暗黙的な一時テーブルを取得できる大きさの上限です。これらは、_GROUP BY_、_ORDER BY_、サブクエリなどを処理するためにSELECTs（など）内で使用されるテーブルです。
これらの一時テーブルはすべての接続で作成でき、クエリごとに複数の一時テーブルを作成できるため、RAMの1％はかなり「安全な」制限です。MySQLでRAMが不足すると、OSがスワップします。事-MySQLの交換はパフォーマンスのためにひどいです。
また、これらを大きく設定しすぎると、他の用途（たとえば、buffer_pool）からRAM=）を盗むため、すべてのクエリが遅くなる可能性があります。
その他 親指のルール
_SQL_BIG_RESULT_も参照してください。
tmp_table_size（およびその依存関係、max_heap_table_size IF MEMORYが一時メモリエンジンに使用されている場合-最新バージョンではなくInnoDBを使用）を可能な限り長くするのは魅力的です。結局のところ、より大きなテーブルサイズで同じクエリを実行すると、おそらく高速になります。
ただし、これを実行しない2つの理由が考えられます。
- 一時テーブルが巨大になる場合は、メモリに行を挿入する時間を浪費し、それをディスクにコピーしてから、行の挿入を続行します。クエリによっては、できるだけ早くディスクに書き込む方が速い場合があります。
- 大きなバッファを設定することは良い考えのように思えるかもしれませんが、無限のメモリはありません。したがって、すべてのクエリ/接続が3Gのメモリを使用する場合、メモリが不足し、仮想メモリスワッピングのためにディスクへの書き込みを開始する可能性があります。 （メモリ不足エラーが原因でMySQLがクラッシュするか、非常に遅くなる可能性があります）。
ここで、単一のクエリを実行しているだけで、複数の同時実行ではなく（したがって、これらの問題が発生しない）、それがはるかに速くなるように機能する場合は、遠慮なく増やしてください（ただし、おそらくそれを変更したい場合があります）セッションのみなので、前述のリグレッションを取得する可能性のある他のクエリには影響しません）。
適切な値を計算するには、クエリで使用するメモリの最大量を選択します（join_buffer_size、sort_buffer_size、read_buffer_size、およびその他のバッファにもメモリが必要になることに注意してください）。または生成する最大の一時テーブル。
Created_tmp_disk_tables変数とCreated_tmp_tables変数を使用して、グローバルスコープで作成しているディスク上の一時テーブルと一時テーブルの数を知ることができます（ただし、いくつかは不可避ですが、たとえば、ヒープテーブルではBLOBが許可されていません。一部のクエリでは、インデックス付けに関係なく、常に一時テーブルが必要になります）。