データベースの行数が多すぎますか？

1,000,000レコードのMySQLInnoDBテーブルがあります。これは多すぎますか？または、データベースはこれ以上を処理できますか？一部のクエリ（たとえば、テーブルから最後の行を取得する）は、100行のテーブルよりも100万行のテーブルの方が遅い（秒）ことに気付いたので、質問します。

1000000レジスタのMySQLInnoDBテーブルがあります。これは多すぎますか？

いいえ、1,000,000行（別名レコード）はデータベースには多すぎません。

一部のクエリ（たとえば、テーブルの最後のレジスタの取得）が、100のレジスタよりも100万のレジスタのテーブルの方が遅い（秒）ことに気付いたので、私は尋ねます。

その声明では説明すべきことがたくさんあります。通常の容疑者は次のとおりです。

1. 不十分に書かれたクエリ
2. テーブルに主キーが存在することを前提として、主キーを使用しない
3. 設計が不十分なデータモデル（テーブル構造）
4. インデックスの欠如

97,000,000レコード（30GBデータファイル）を超えるデータベースがあり、問題はありません。

テーブルインデックスを定義して改善することを忘れないでください。

したがって、1,000,000が多くないことは明らかです！（ただし、インデックスを作成しない場合は、はい、多くなります）

'explain'を使用してクエリを調べ、クエリプランに問題がないかどうかを確認します。

これはよくある誤解だと思います。データベースのスケーラビリティに関しては、サイズは方程式の一部にすぎません。難しい（または難しい）他の問題があります：

• ワーキングセットの大きさ（つまり、メモリにロードしてアクティブに処理する必要のあるデータの量）。データを挿入して何もしない場合、実際には簡単に解決できます。

• どのレベルの並行性が必要ですか？挿入/読み取りを行うユーザーは1人だけですか、それとも何千ものクライアントを同時に操作していますか？

• どのレベルの約束/耐久性とパフォーマンスの一貫性が必要ですか？各コミットを尊重できることを確認する必要がありますか？平均的なトランザクションが高速であるかどうか、またはすべてのトランザクションが確実に高速であることを確認する必要がありますか（http://www.mysqlperformanceblog.com/2010/06/07/performance-optimization-のようなシックスシグマの品質管理）および-six-sigma /）。

• テーブルスキーマのALTERなど、運用上の問題を実行する必要がありますか？InnoDBではこれは可能ですが、フォアグラウンドで一時テーブルを作成する必要がある（すべての接続をブロックする）ため、非常に遅くなります。

したがって、2つの制限の問題は次のようになると述べます。

• クエリを書く/良いインデックスを持つあなた自身のスキル。
• ALTERTABLEステートメントを待つのにどれだけの苦痛を許容できるか。

100万行を意味する場合、それはインデックス作成の方法とハードウェアの構成によって異なります。エンタープライズデータベースや、まともな機器の開発データベースにとって、100万行は大量ではありません。

100万列を意味する場合（MySQLでも可能かどうかはわかりません）、はい、これは少し大きいように思われ、おそらく問題を引き起こすでしょう。

登録？記録という意味ですか？

最近のデータベースでは、100万レコードはそれほど大きな問題ではありません。問題が発生した場合は、データベースシステム自体ではなく、それを実行しているハードウェアである可能性があります。ほとんどの場合、ハードウェアが不足する前にDBで問題が発生することはありません。

明らかに、一部のクエリは他のクエリよりも低速ですが、2つの非常に類似したクエリが大幅に異なる時間に実行される場合は、データベースの実行プランを把握して最適化する必要があります。つまり、正しいインデックス、適切な正規化などを使用します。

ちなみに、テーブルには「最後の」レコードのようなものはありません。論理的な観点からは、固有の順序はありません。

分析作業のために自己結合した、数十億（インデックス付き）のレコードを持つパーティション化されていないテーブルを見てきました。最終的には分割しましたが、正直なところそれほど大きな違いは見られませんでした。

そうは言っても、それはOracleにあり、MySQLでその量のデータをテストしていません。インデックスはあなたの友達です:)

「レコード」を「レジスタ」で意味すると仮定すると、それほど多くはありません。MySQLは非常に適切にスケーリングされ、ハードディスクの空き容量と同じ数のレコードを保持できます。

明らかに、検索クエリは遅くなりますが。フィールドに適切なインデックスが付けられていることを確認する以外に、これを回避する方法は実際にはありません。

テーブルが大きくなるほど（テーブル内の行が増えるほど）、インデックスがない場合、通常はクエリの実行が遅くなります。適切なインデックスを追加すると、クエリのパフォーマンスが向上するか、少なくともテーブルが大きくなるほど低下しないはずです。ただし、テーブルが大きくなるにつれてクエリ自体がより多くの行を返す場合は、再び劣化が見られるようになります。

100万行はそれほど多くはありませんが、DBサーバーにあるメモリの量にも依存します。テーブルが大きすぎてサーバーがメモリにキャッシュできない場合、クエリは遅くなります。

提供されたクエリの使用は、データの並べ替えに並べ替えマージメソッドを使用するため、非常に遅くなります。

インデックスを使用してデザインを取得するようにデザインを再考するか、並べ替えが不要になるように既にその方法で並べ替えられていることを確認することをお勧めします。