頻繁な挿入と読み取りに使用される INT(4B) PK を使用して、200 万行を超える 8 つのテーブルがあります。データの古い 9/10 は時々読み取られ、アクセスにどれだけ時間がかかってもかまいませんが、新しい 1/10 は INSERT と SELECT の両方で高速でなければなりません。表は、要件の 2 つのカテゴリに分けられます。
innodb_buffer_pool_size を 32M に設定して作業する必要があり、古いデータは重要ではないため、週に 1 回、各テーブルの古い半分を大きなアーカイブ テーブルにコピーすることをお勧めします。さらに、現在のトランザクションの代わりに infile 挿入を使用する必要があります。それは良い解決策ですか？この問題に関するアドバイスとリンクをいただければ幸いです。
InnoDB を使用している場合、データはテーブルの PRIMARY KEY を使用して自然に「クラスター化」されます。定義した場合 (つまり、「id INT NOT NULL PRIMARY KEY AUTO_INCREMENT」)、データは ID によってグループ化されます (そのままになります)。仕方）。
そのため、最新の INSERT されたデータは自然にいくつかの InnoDB バッファーにグループ化され、古いアーカイブ データはまったく問題になりません。データをアーカイブテーブル/データベースと最近のテーブルに分割しても、すべてがより複雑になることを除いて、メリットがあるとは思いません!
InnoDB での挿入/更新/削除を高速化するには、InnoDB ログ ファイルの物理的な場所を考慮する必要があります。InnoDB は操作を実行するために変更をログ ファイルに挿入する必要があります (明示的なトランザクションであるか暗黙的なトランザクションであるかに関係なく!)。 、データまたはインデックスがディスクに戻されるのを待ちません。これは、MyISAM とはかなり異なる戦略です。
したがって、InnoDB ログ ファイル、10krpm+ ハード ドライブまたは SSD に高速シーケンシャル ストレージを割り当て、ibdata を別のドライブまたは RAID アレイに保持できれば、非常に多くの DB 変更を維持できます。IO バウンドです。 InnoDB ログ ファイル (update/delete で複雑または重い where 句を使用する場合を除く)。