私はmySQLデータベースを作成し始めたばかりで、私が理解しようとしている質問の1つは、「テーブルの更新を時間枠に分割する必要があるか」です。それ以外の場合、5年後にクエリを実行すると、はるかに大きなテーブルからクエリを実行します。SQLがクエリをどのように実行するかについては正確にはわかりません。また、テーブルをそのままにしておくことで重大な問題が発生するかどうかもわかりません...
現状では、テーブルには候補キーの一部である日付列があり、日付範囲クエリを実装していますが、すべてを1つのテーブルに残すのは悪いことですか？（私は少なくとも3NF-4NF形式の複数のテーブルを持っています）
また、この質問に対する回答を調べましたが、回答はあまり詳細ではなく、比較的サポートされている回答である以外は多くの説明をすることができませんでした。
この問題に関していくつかの重要なポイントとプロセスがあります。私はいくつかの主要な古風なパターンを調べてみます。
SQLの問題は、約5M以上の大きな行数で始まります。問題は通常slowqueryです。データベースを継続的に更新する必要がある場合、たとえば1秒あたり2000〜3000ヒットの場合、サーバーがクラッシュする可能性があります。
非常に遅いクエリを回避するには、共通のテーブル関数をマップし、それらを一般にSELECTとINSERT/UPDATEに分割する必要があります。
SELECTの場合、テーブルロックを回避するためにINNODBテーブルを使用することをお勧めします。また、ライフタイムテーブルよりも短い期間を保持する小さなテーブルを作成するChronプロシージャ（サーバー上で自動的に実行されるスクリプト）の実行を検討してください。これにより、高速で動作する小さなサイズのテーブルが確保されます。
たくさんのヒットを計画している場合。このアイデアをお勧めします。メインテーブルのサイズを15GB未満に保ち、この時点からアーカイブDBを作成する時間枠を決定します。メインテーブルからアーカイブに毎日小さなチャンクでコピーします。アーカイブのサイズが制限されていないことを確認してください（適切なサービスを選択してください。たとえば、AmazonのS3はSQLダンプファイルの保存に最適です。ただし、これは開くことができないSQLサーバーではないため、SQLに解凍する必要があります。これには時間がかかる可能性があるため、アーカイブはSQLサーバーである必要があります）アーカイブパターン-大量のRAM（128〜256 GB）4〜8 CPUを備えたSQLサーバーを使用し、テーブルを時間枠の表に分割します。それぞれ2000万行に保つようにしてください。
。メインテーブルへのレプリケーションプロセスを作成します->ユーザーの読み取り許可のみを持つスレーブDB。これで、この設定により、テーブルがヒットし、バックアップが作成され、すべてのデータがアーカイブに保持されるようになります。もう1つの優れた機能は、すべてのSELECTQUERIESをスレーブDBに送信できることです。これにより、SQLがスタックしないようになり、これを使用して、テーブルサイズに関係なく、YEAR、MONTH、DAYAggreagateクエリを作成できます。
このプランは、MYSQLの無料バージョンと私が知っているすべてのサーバーで機能します。
よりロボストなソリューションが必要で、時間がシステムの主な問題ではない場合は、GOOGLEアプリエンジン\AMAZONクラウドをお勧めします。無制限のストレージとコンピューティングのために。
遅いクエリログでパフォーマンスを確認し、SQLを高速化するためにDBを変更してより多くのテーブルを保持することができます。複数のユーザーに同じテーブルを使用する場合は、データを何度も表示し、DBに接続してクエリを実行する時間を節約できるMemcashソリューションを調べることができると思います。
主な奴隷関係に関するもう少しのポイント：
スレーブ（読み取りユーザー）から削除できないため、データを削除するには、メインテーブルからこれをクリーンアップする必要があります。以前は明確ではなかったかもしれませんが、アーカイブにデータを取り込むときに、スレーブからデータを選択し（ここでも重い選択をロードしないように）、これをコピーしてから、このデータをメインテーブルから削除します。レプリケーションプロセスはこれをスレーブからも削除します。したがって、これがアーカイブプロセスである場合を除いて、メインとスレーブはほぼ常に同じです。もう1つのポイントは、トラフィックコストです。スレーブとメインが同じサーバー上にある場合は安価になりますが、サーバーがダウンした場合は、それらを一緒に失うことになります。うまくいけば、アーカイブを別のサーバーに配置します。トラフィックが少ない場合は、別のサーバーでスレーブを使用し、データを表示するために常に完全バックアップをとることができます。
この助けを願っています。
非常に大きなデータセットや5年間触れられないシステムを扱っている場合を除いて、問題が発生するまでにデータベースエンジンを変更し、データをさらにシャーディング/パーティション化する必要があります。
ただし、これはデータセットのコンテキストを知らなくても...