サブテーブルに関する質問

現在、データベースに 500 万を超えるデータを持つ 3 つのフォームがあり、テーブルの 1 つが 1000 万を超えていますが、クエリの速度がどんどん遅くなってきています

専門家に次のことを質問したいと思います。質問

1. 100 万を超えるテーブルを複数のテーブルに分割します。

2. B データ テーブルを 100 万のテーブルに分割すると、テーブル A の ID はテーブル B に 5 個のデータがあり、B のデータ テーブルに分割された 10 個のテーブルに格納されています (問題が発生します。データを読み取るときに、テーブル B 内のすべてのテーブルを読み取ることができません。この 5 個)。のデータが分割テーブルの 5 番目と 6 番目のテーブルに配置される可能性があります。この場合、テーブル B の 5 番目と 6 番目のテーブルを読み取るだけで済みます。前提として、データがどこにあるかはわかりません。全く。）

ディスカッションへの返信 (解決策)

これに続いて、インデックスを追加すると、最大 200W のデータが発生しました。非常に効果的です。プロセスを知りたいです。最適化された単一テーブル データの上限はどれくらいですか?

数百万の通常のクエリ ステートメントがあり、インデックスが追加された場合、クエリ速度は問題ありません。ただし、テーブルまたはサブクエリの結合は遅くなります

水平テーブル シャーディングではターゲット ID の場所を知っている必要があり、そうでない場合は逆効果となり、効率が低下します。
外部キー アルゴリズムに従ってテーブルを分割できるかどうかを確認してください

テーブルの分割は条件付きであり、単純にレコード順に分割されるわけではありません
たとえば、 A と B は id によって関連付けられています。 B は A.id に従って分割されます
このように、A.id がわかっている場合、分割ルールに従って、関連するレコードがどの Bn に表示されるかを推定できます

テーブル間の関係は多対多であるため、テーブルを分割することは無意味です
現時点では、関係を保存するために遷移テーブルを使用する必要があり、クエリはすべてのテーブルを相関させるのではなく 2 段階で実行する必要があります一度に
遷移テーブルは通常 2 列しかありません。レコード数は多いですが、一度にメモリにロードされる可能性が高くなります (複数回ロードする必要がある場合でも、レコードの数は異なります)。毎回ロードできるサイズも非常に大きいです)