私は何千人ものユーザーが頻繁に使用するUbuntuのmysql 5.6 DBを持っています。 10日間実行した後、次の値を取得しました。
| Created_tmp_disk_tables | 894170 |
| Created_tmp_files | 26068 |
| Created_tmp_tables | 914511 |
私の設定値は:
| tmp_table_size | 268435456 |
| max_heap_table_size | 1073741824 |
私がtmp_table_size = 16MBとmax_heap_table_size = 16MBを持っているとき、それは同じでした。私はそれをtmp_table_size = 256MBとmax_heap_table_size = 1GBに変更しましたが、Created_tmp_disk_tablesは成長を止めませんでした。レートはまったく同じです。
26GBのヒープがあります。すべてのテーブルはINNODBです。
何が欠けていますか?
ありがとう
「26GBヒープ」とはどういう意味ですか?
_tmp_table_size = 256M
_は危険です。複数の接続がtmpテーブルを必要とする場合、RAMが不足する可能性があります。スワップは悪いさまざまな設定を下げるよりもパフォーマンスが向上します。
Tmpテーブルは、多くの状況で必要です。それらを恐れないでください。しかし、それらを確認してください。
DISTINCT
、_GROUP BY
_、_ORDER BY
_およびUNION
はしばしばrequire tmpテーブルです。 tmpテーブルがmin(tmp_table_size, max_heap_table_size)
に収まる場合、tmpテーブルmayはRAM using _Engine=MEMORY
_を使用)になります。それより大きい場合、その場合、tmpテーブルは_Engine=MyISAM
_で低速ですMyISAMを使用する理由は他にもありますが、特にTEXT
フィールドを選択しているためです 詳細 。
もう1つの一般的な「エラー」は、VARCHAR(255)
とutf8を盲目的に使用することです。 MEMORYを使用すると、それは765バイトのCHAR
になり、MyISAMへの変換を早めます。
あなたが与えた数字...
tmp_table_size
_が十分に大きくないか(私は疑問です)、またはMEMORYを使用できないことを意味します(私はそう思います)。私の分析では、20%を上回っています。Long_query_time = 1を設定し、SlowLogをオンにします。できればFILEにします。 1日待ってから、slowlogでpt-query-digestを使用して、「最悪の」クエリを見つけます。それらを改善する方法がわからない場合は、お問い合わせください。
私は2つの項目でRolandoに同意しません。
OPTIMIZE TABLE
_が役立つことはほとんどなく、質問にはあまり関係がありません。レートがまったく同じ場合は、クエリまたは構成を調整する必要があります。どうして ?
tmp_table_size と max_heap_table_size の調整については前に説明しました
Nov 25, 2014
: インデックスを追加せずにパフォーマンスを向上 (RAMディスクディスカッション)Feb 06, 2014
: MariaDB:開始後のCreated_tmp_disk_tablesが高いApr 18, 2013
: 最適化テーブルに関するアイデアが必要join_buffer_size および sort_buffer_size (2番目の投稿を見てください)