私はシステムを設計しており、数字を深く掘り下げていくと、年間 54,240,211,584 レコード (およそ) のテーブルが存在する可能性があることに気付きました。おお！！！！
それで、私はそれを 73,271,952 レコード/年 (概算) に分解します。
次の場合に何が起こるかをExcelで実行して数値を取得しました：
a）成功なし= 87ユーザー、
b）低モデレート成功= 4300ユーザー、
c）高モデレート成功= 13199ユーザー、
d）成功= 55100ユーザー
e）信じられない成功＝いや
テーブルが SELECT、INSERT、UPDATE & JOIN ステートメントに使用されること、およびこれらのステートメントがシステムにログインしているすべてのユーザーによって毎時/毎日/毎週実行されることを考慮してください (履歴データはオプションではありません)。
質問 1: パフォーマンスがほとんど影響を受けないように、2 番目の量は MySQL エンジンに適していますか?
質問 2: テーブルを InnoDB として設定しましたが、JOINS を使用してすべてのステートメントを処理し、4GB 制限の問題に直面しても構わないと考えているという事実を考えると、InnoDB は有用ですか?
表の概要:
表 #1: ユーザー/イベントの購入。最大 15 列、一部は VARCHAR。
表 2: 購入によるチケット。最大 8 列、TINYINT のみ。主キー INT。各テーブル #1 の挿入で挿入される 4 ～ 15 行。
表 #3: チケット別のアイテム。4 列、TINYINT のみ。主キー INT。テーブル #2 の挿入ごとに 3 行挿入されます。別のテーブルとして保管したいのですが、誰かが死ぬ必要がある場合は...
表 3 が質問の対象です。2 番目の数量に減らす方法は、各テーブル #3 の行をテーブル #2 の列にすることでした。
私がやりたくないことですが、必要に応じて、テーブルを週ごとに分割し、アプリケーションにロジックを追加することです。
すべての回答が役に立ちますが、次のような回答の方がより役に立ちます
。
ii) 3,375,424,021,158: いいえ、最後の数字は省略します。
iii) 337,542,402,115: いいえ、最後の数字を削除しましょう。「まあ、それは多くの要因に依存します...」のようなものが得られるまで、などです。
「パフォーマンスへの影響が少ない」とは何ですか??? 最大 1,000,000 レコード、クエリの実行に 3 秒もかかりません。33,754,240,211,584 件のレコードに約 10 秒かかるとすれば、それは私にとって素晴らしいことです。
自分でテストしてみませんか？私はそのようなテストを行う能力がないと思います。私がすることは、その量の行を挿入して何が起こるかを見ることです。私は、似たようなことをすでに知っている人の視点を最初に好みます。覚えておいてください、私はまだ設計段階です
前もって感謝します。