MySQL データベースに 2000 万のレコード テーブルがあります。適切なインデックスを設定したため、SELECT は非常に高速に動作しますが、INSERT および UPDATE 操作は非常に遅くなります。データベースは、負荷の高い Web アプリケーションのバックエンドです。このテーブルには 5 つのインデックスがあり、現在のインデックス サイズは約 1GB であるため、INSERT と UPDATE は非常に低速です。計算に時間がかかると思います。
この問題を解決するために、テーブルを分割することにしました。私は MySQL 4 を実行しており、アップグレードできません (サーバーを直接制御できない) ため、手動でパーティショニングを行い、セクションごとに個別のテーブルを作成します。
データセットは、約 18000 の異なる論理スライスから構成されており、完全に個別にクエリを実行できます。したがって、(maindata1、maindata2 など) という名前の 18000 個のテーブルを作成できました。しかし、これが最適な方法であるかどうかはわかりませんか？手動で何かをしたいときはいつでも、管理ツールで 18000 項目をブラウズしなければならないという明らかな事実に加えて、ファイル システムのパフォーマンスが心配です。ファイルシステムはext3です。36000 個のファイル (データ ファイルとインデックス ファイルがあります) を含むディレクトリ内のファイルを見つけるのがどれほど速いかはわかりません。
これが問題になる場合は、データの一部を結合して同じテーブルにすることができます。例: maindata10、maindata20 など。maindata10 にはスライス 1、2、3...10 が含まれます。10 の「グループ」を使用する場合、テーブルは 1800 しかありません。20 個をグループ化すると、900 個のテーブルが得られます。
このグループ化の最適なサイズ、つまりディレクトリ内のファイルの数とテーブルのサイズはどうなるのだろうか?
編集:複数の別々のデータベースを使用してファイルをグループ化することも良い考えではないかと思います. したがって、18000 個のテーブルがあったとしても、それらを 600 個のテーブルを持つ 30 個のデータベースにグループ化できます。これでだいぶ管理しやすくなりそうです。複数のデータベースを使用することで、パフォーマンスやメモリ フットプリントが増減するかどうかはわかりません (ただし、バックアップと復元が複雑になります)。