MySQL の単一テーブル データは 500 万行を超えてはなりません。これは経験値ですか、それとも黄金律ですか?

今日は、興味深いトピックについてお話しましょう。単一の MySQL テーブルをデータベースとテーブルに分割する前に、考慮する必要があるデータの量はどれくらいですか? 2,000 万行という人もいれば、500 万行という人もいます。では、この値はどれくらいが適切だと思いますか?

かつて中国のインターネット技術界では、「単一テーブルのデータ量が 2,000 万行を超えると、MySQL のパフォーマンスが大幅に低下する」という格言がありました。実はこの噂は百度から出たものだと言われています。具体的な状況はおそらく次のとおりで、DBA が MySQL のパフォーマンスをテストしたところ、1 つのテーブルのサイズが 2000 万行に達すると SQL 操作のパフォーマンスが急激に低下することがわかったので、このような結論になります。その後、百度のエンジニアが同業他社に転職してその情報を持ち込んだため、この言葉が業界に広まったと言われています。

その後、Alibaba の「Java 開発マニュアル」では、データベースとテーブルのシャーディングは、単一テーブルの行数が 500 万を超える場合、または単一テーブルの容量が 2GB を超える場合にのみ推奨されると提案されました。これはアリババの黄金の鉄則によってサポートされているため、多くの人がビッグ データ ストレージを設計するとき、これを標準としてテーブル操作を実行します。

それでは、適切な値はどれくらいだと思いますか?なぜ 300 万行や 800 万行ではなく、500 万行なのでしょうか?おそらくこれがアリの最高の実戦値であると言えるでしょうか？では、この値はどのように評価されるのでしょうか?という疑問が再び生じます。ちょっと待ってください、ちょっと考えてください。

実際、この値は実際のレコード数とは関係なく、MySQL の構成とマシンのハードウェアに関連しています。パフォーマンスを向上させるために、MySQL はテーブルのインデックスをメモリにロードするためです。 InnoDB のバッファ サイズが十分であれば、メモリに完全にロードでき、クエリに問題はありません。ただし、単一テーブル データベースが一定の大きさの上限に達すると、メモリにインデックスを保存できなくなり、後続の SQL クエリでディスク IO が発生し、パフォーマンスが低下します。もちろん、これは特定のテーブル構造の設計にも関係しており、最終的な問題はメモリの制限です。ここで、ハードウェア構成を増やすと、すぐにパフォーマンスが向上する可能性があります。

したがって、サブデータベースとサブテーブルに関する私の見解は、実際のニーズと組み合わせる必要があり、過度に設計すべきではないということです。プロジェクトの開始時に使用されていましたが、ビジネスが成長するにつれて使用できなくなります。最適化が継続する場合は、システムのパフォーマンスを向上させるためにデータベースとテーブルをシャーディングすることを検討してください。これに関して、アリババの「Java 開発マニュアル」には、データ量が 3 年以内にこのレベルに達しないことが予想される場合は、テーブルを作成するときにデータベースをテーブルに分割しないでくださいと追加されています。それで、最初の質問に戻りますが、適切な値はどれくらいだと思いますか?ご提案としては、ご自身のマシンの状況を踏まえて総合的に判断して、基準が決まっていない場合は、比較的妥協できる値である500万行を暫定的に統一基準として採用してはいかがでしょうか。

MySQL 関連の技術記事の詳細については、MySQL チュートリアル 列にアクセスして学習してください。

以上がMySQL の単一テーブル データは 500 万行を超えてはなりません。これは経験値ですか、それとも黄金律ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。