MySQLは64 GBのRAMを効果的に利用できますか？

約5,000万行があり、インデックスサイズが4 GB（テーブルサイズが約6 GB）のテーブルを照会すると、データベースサーバーがメモリをスワップし、劇的にスローダウンするという問題に直面しています。これは、一時テーブルのサイズが超過し、ディスクにスワップされることに関係していると確信しています。

データベースサーバーを32 GBのRAMから64 GBのRAMにアップグレードした場合、MySQLデータベースがスワップではなくこの追加メモリを完全に利用できるかどうか疑問に思います。いくつかの変数（例：KEY_BUFFER_SIZEなど）を調べましたが、64 GBを超える値の設定をサポートしているようです。ただし、MySQLのドキュメントには、tmp_table_sizeが4 GBで最大になると書かれています。

それで、メモリのアップグレードは価値がありますか？「querying-large-table」問題はこれの恩恵を受けるのでしょうか、それとも4 GBの制限のために助けになりませんか テーブルをさまざまな方法でパーティション分割するなど、他のソリューションが潜在的にあることを知っていますが、テーブルについて何も変更せずに、追加のメモリが役立ちますか？

また、一般的に、32 GBから64 GBのRAMに移動するときにMySQLが利用できないメモリ関連の変数は他にありますか？

データベースサーバーとして64ビットLinux（Ubuntu）を使用しています。

ありがとう、ガレン

InnoDBを使用している場合、設定する最も重要な変数はinnodb_buffer_pool_sizeです。システムメモリの約80％に設定します。使用後にキャッシュがウォームアップされると、最もアクティブなデータ（作業データセット）はメモリ（innodb_buffer_pool_size）に格納され、その操作は非常に高速になります。64GBのメモリを使用すると、確実に多くのメモリを収容できます。メモリは、DBサーバーにとって常に良い買い物です。

はい-InnoDBを使用し、読み取り集中型のワークロードがある場合、大量のRAMを絶対に活用できます（データセットがmemに収まると仮定すると、サーバーは非常に高速になります）。

8-16 GBサーバーのInnoDBストレージでMySQLを使用し、ワーキングセットがメモリに適合しています。

おそらく、メモリにお金をかける前にシステムがスワップする原因を調査するために、余分な時間と労力を費やす価値があるでしょうか？

32GBのメモリでは、テーブル全体、インデックス、および最大temp_tableをメモリにロードした後でも、十分なメモリが残っています。クイック検索により、関連する可能性のある次の2つのドキュメントが表示されました。

• MySQLが内部一時テーブルを使用する方法
• MySQLがメモリを使用する方法

非常に大きな一時テーブルが作成されていることが原因だと思われる場合は、クエリを改善して一時テーブルを回避する方法を検討することをお勧めします。

Stackoverflowに、スキーマ、クエリ、説明計画、問題の詳細を含む投稿を投稿できます。