innodb_buffer_poolを設定する理由とその理由

170GBのInnoDBインデックスとデータがあります。

パフォーマンスを向上させるために、innodb_buffer_poolサイズを再調整する必要があります。InnoDBテーブルの最大テーブルサイズ（インデックス+データ）は28GBです。

そのため、innodb_buffer_poolの最適なサイズはどうでしょうか。

更新

このローカルデータベースをec2に移行するので、innodbの現在の統計に従ってRAMを設定します。そのため、使用可能なRAMを確保するためにバッファープールのサイズが必要です。

テーブルごとのファイルが有効になっています。

Linuxマシンを使用しています。

所有する最大のテーブルは、合計データの16.47％（28/170）を占めています。テーブルが高度に書き込まれ、高度に読み取られた場合でも、特定の瞬間にテーブルのすべての28Gがバッファプールにロードされるわけではありません。計算する必要があるのは、現在のDBサーバーで任意の瞬間にロードされるInnoDBバッファープールの量です。

現在のDBサーバーのInnoDBバッファープールに現在ロードされているデータセットを指定して、新しいDBサーバーのinnodb_buffer_pool_sizeを決定するより詳細な方法を次に示します。

現在のMySQLインスタンス（移行元のサーバー）で次を実行します

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_data';  -- IBPDataPages 
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_total'; -- IBPTotalPages
SHOW GLOBAL STATUS LIKE 'Innodb_page_size'; -- IPS

式を実行しますIBPPctFull = IBPDataPages * 100.0 / IBPTotalPages。

SET @IBPDataPages = (SELECT VARIABLE_VALUE FROM information_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_pages_data'); -- SELECT @IBPDataPages;
SET @IBPTotalPages = (SELECT VARIABLE_VALUE FROM information_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_pages_total'); -- SELECT @IBPTotalPages;
SET @IBPPctFull = CAST(@IBPDataPages * 100.0 / @IBPTotalPages AS DECIMAL(5,2));
SELECT @IBPPctFull;

IBPPctFullが95％以上の場合、innodb_buffer_pool_sizeをDBサーバーのRAMの75％に設定する必要があります。

IBPPctFullが95％未満の場合、次の式を実行しますIBPSize = IPS X IBPDataPages / (1024*1024*1024) X 1.05。

SET @IBPSize = (SELECT VARIABLE_VALUE FROM information_schema.global_status WHERE VARIABLE_NAME = 'Innodb_page_size'); -- SELECT @IBPSize;
SET @IBPDataPages = (SELECT VARIABLE_VALUE FROM information_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_pages_data'); -- SELECT @IBPDataPages;
SET @IBPSize = concat(ROUND(@IBPSize * @IBPDataPages / (1024*1024*1024) * 1.05, 2), ' GB' );
SELECT @IBPSize;

IBPSizeの数値（GB）は、実際の作業データセットにより近い数値です。

最大のAmazon EC2 RAM構成に対してIBPSizeがまだ大きすぎる場合は、Amazon EC2 DBサーバー用にRAMの75％を使用してください。

この回答は、以下のローランドの回答の補足情報として提供しています。

サーバーが実稼働する前

MySQLで最も頻繁に使用される最大のテーブルに基づいて、innodb_buffer_pool_sizeを計算します。データベース内のサイズに基づいて最大のテーブルを識別するには、次のスクリプトを使用できます。

select table_schema, table_name, round(data_length/1024/1024,2) as size_mb 
from information_schema.tables where table_schema like 'my_database' 
order by size_mb desc;


+--------------+-------------------------+---------+
| table_schema | table_name              | size_mb |
+--------------+-------------------------+---------+
| heavybidder     | user                 |   522.55|
| heavybidder     | bid                  |   121.52|
| heavybidder     | item_for_sale        |    10.52|
| heavybidder     | account_user         |    5.02 |
| heavybidder     | txn_log              |    4.02 |
| heavybidder     | category             |    0.02 |
+--------------+-------------------------+---------+

データベースで最大のテーブルがわかったので、最も頻繁に使用されるテーブルを決定する必要があります。そのためには、Jet Profiler（JP）などのプロファイリングプログラムを使用して、最もアクセスされているテーブルを調べます。JPは、どのテーブルが最も頻繁にアクセスされているかを示します。以下は、JPのそのセクションのスクリーンショットです

このことを念頭に置いて、ユーザーと入札テーブルは約640MBのディスク容量を必要とし、JPによると非常に頻繁に使用されることを知っています。彼のコメントで以下に言及しています。

MySQLに、最大で最も頻繁に使用されるテーブルのデータを格納するのに十分なメモリがあることを確認するには、640MBでinnodb_buffer_pool_sizeを定義します。

追加の考慮事項がいくつかありますが、それらはinnodb_buffer_pool_sizeには適用されません。

これは32ビットまたは64ビットのシステムですか？32ビットシステムでは、PAEをアクティブにしない限り4GBに制限されます。Windowsでは、これはWindows EnterpriseまたはDatacenterエディションを実行することを意味します。

システムで実行されている他のプロセスに必要なメモリはどれくらいですか？専用のMySQLサーバーでは、OSに5〜10％を割り当てます。Windowsでは、Process Explorerを使用してメモリ使用量を分析できます。Linuxでは、sysstat、free、htop、top、vmstatがあります。

データベースはInnodbテーブルのみで構成されていますか、またはInnodbとMyISAMの混合物ですか？2つが混在している場合は、key_cache、join変数、クエリキャッシュなどのメモリを確保します。サーバーが実稼働状態になったら、後でMyISAMヒット率を計算できます。

サーバーの運用後

Innodbの現在のヒット率は？

1-（innodb_buffer_pool_reads / innodb_buffer_pool_read_requests）。

キーキャッシュヒット率とは

1-（Key_reads / Key_read_requests）

通常、比率を可能な限り100％に近づけようとします。

テーブルがバッファプールにどれだけ収まるか

また、このリンクを参照することで、テーブルデータがbuffer_poolにどれだけ収まるかを確認できます。これにより、「特定のテーブルのバッファプールにあるページ数（cnt）、それらのページ数がダーティ（ダーティ） 、およびメモリに収まるインデックスの割合（fit_pct）。」 Perconaサーバーにのみ適用

http://www.mysqlperformanceblog.com/2010/12/09/how-well-does-your-table-fits-in-innodb-buffer-pool/