私はかつて、非常に大規模な（Terabyte +）MySQLデータベースを使用していました。私たちが持っていた最大のテーブルは、文字通り10億行を超えていました。
機能した。 MySQLはほとんどの場合データを正しく処理しました。しかし、それは非常に扱いにくいものでした。
データをバックアップして保存するだけでも課題でした。必要に応じて、テーブルを復元するのに数日かかります。
1,000万から1億の行範囲に多数のテーブルがありました。テーブルへの重要な結合は時間がかかりすぎて、永遠にかかります。そこで、テーブルを「ウォーク」し、「id」の範囲に対して結合を処理するストアドプロシージャを作成しました。このようにして、一度に10〜100,000行のデータを処理します（IDの1〜100,000、次に100,001〜200,000などに対して結合します）。これは、テーブル全体に対して結合するよりも大幅に高速でした。
主キーに基づかない非常に大きなテーブルでインデックスを使用することも、はるかに困難です。 Mysqlは、インデックスを2つの部分に格納します。つまり、インデックス（プライマリインデックス以外）をプライマリキー値へのインデックスとして格納します。したがって、インデックス付きルックアップは2つの部分で実行されます。最初にMySQLがインデックスに移動し、そこから検索する必要のある主キー値を取得し、次に主キーインデックスで2回目のルックアップを実行して、それらの値がどこにあるかを検索します。
これの正味は、非常に大きなテーブル（1〜2億以上の行）の場合、テーブルに対するインデックス付けがより制限されることです。必要なインデックスは少なく、単純です。また、インデックスに直接存在しない単純なselectステートメントを実行しても、二度と戻ってこない場合があります。 Where句は必須 インデックスをヒットするか、忘れてください。
しかし、そうは言っても、物事は実際に機能しました。これらの非常に大きなテーブルでMySQLを使用し、計算を行って正しい答えを得ることができました。