InnoDBを調整する方法は中心にあります
- InnoDBバッファープール：データページとインデックスページをキャッシュします。キャッシュできるデータとインデックスの量は、ディスク領域の制約の関数ではなく、現在InnoDBで使用されている使用可能なメモリとディスク領域の関数です。
- InnoDBメタデータ：デフォルトでは、ファイルibdata1には通常、InnoDBのすべてが格納されています。これには、データページ、インデックスページ、テーブルメタデータ、MVCCデータが含まれます。
InnoDBデータとインデックスページで使用されるディスクスペースに基づいてInnoDBバッファープールを計算するために過去5年間使用してきた式は次のとおりです。
SELECT CONCAT(ROUND(KBS/POWER(1024,IF(Power1024<0,0,
IF(Power1024>3,0,Power1024)))+0.49999),SUBSTR(' KMG',IF(Power1024<0,0,
IF(Power1024>3,0,Power1024))+1,1)) recommended_innodb_buffer_pool_size
FROM (SELECT SUM(data_length+index_length) KBS FROM information_schema.tables
WHERE engine='InnoDB') A,(SELECT 2 Power1024) B;
- バイトには（SELECT 0 Power1024）を使用
- KBには（SELECT 1 Power1024）を使用
- MBには（SELECT 2 Power1024）を使用
- GBには（SELECT 3 Power1024）を使用
- TBには（SELECT 4 Power1024）を使用します（TerraBytesのRAMがある場合はメールで通知します）
もちろん、私は現在InnoDBで使用されている利用可能なメモリとディスク容量の関数について述べました。ここからは常識を働かせてください。上記のクエリからの推奨数は、インストールされているRAMの75％を超えてはいけません!!! これが、InnoDBバッファープールのサイジングの最も単純な経験則です。
InnoDBの安定した同期書き込みを提供するため、innodb_flush_methodをO_DIRECTに設定する必要もあります。また、ディスクストレージをInnoDB用に最適化する方法に関する投稿も書いています。
メッセージTableは最適化をサポートしておらず、代わりに再作成+分析を実行しています。このエラーメッセージが表示されるのは、ストレージエンジンがInnoDBであるためです。機械的には、OPTIMIZE TABLEはテーブルを一時テーブルにコピーし、ANALYZE TABLEを実行するだけです。
実際には、InnoDBに対するANALYZE TABLEはまったく役に立ちません。InnoDBテーブルでANALYZE TABLEを実行した場合でも、InnoDBストレージエンジンは、カーディナリティの近似のためにインデックスに何度もダイブし、コンパイルしたばかりの統計を破棄します。実際、PerconaはANALYZE TABLEでいくつかのテストを実行し、同じ結論に至りました。
InnoDB Tuningについて私が1年にわたって作成した他の投稿は次のとおりです