タイトルは質問自体をかなり要約しています: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つの理由が考えられます。
ここで、単一のクエリを実行しているだけで、複数の同時実行ではなく(したがって、これらの問題が発生しない)、それがはるかに速くなるように機能する場合は、遠慮なく増やしてください(ただし、おそらくそれを変更したい場合があります)セッションのみなので、前述のリグレッションを取得する可能性のある他のクエリには影響しません)。
適切な値を計算するには、クエリで使用するメモリの最大量を選択します(join_buffer_size
、sort_buffer_size
、read_buffer_size
、およびその他のバッファにもメモリが必要になることに注意してください)。または生成する最大の一時テーブル。
Created_tmp_disk_tables
変数とCreated_tmp_tables
変数を使用して、グローバルスコープで作成しているディスク上の一時テーブルと一時テーブルの数を知ることができます(ただし、いくつかは不可避ですが、たとえば、ヒープテーブルではBLOBが許可されていません。一部のクエリでは、インデックス付けに関係なく、常に一時テーブルが必要になります)。