私はフリート管理に取り組んでいます。次の列を持つロケーションテーブルに大量の書き込みがあります
ここでは、このテーブルは3秒ごとに書き込み操作を行います。したがって、その中には何百万ものレコードがあります。したがって、より高速なデータを取得するために、私はパーティションを計画しています。今私の質問：-
何兆もの記録があります
@rc-ありがとうございます。パフォーマンスに影響があります...3秒ごとにデータを挿入しているので、データを挿入するたびにチェック手順を実行する必要があります...パフォーマンスはどうですか？
2>車両番号としてパーティション列に移動したい.....別の方法はありますか...
1.）FKはパーティションテーブルではサポートされていません。
2.）パーティショニングに使用する列は、テーブルへのアクセス方法によって異なります。クエリが常に車両番号に基づいている場合は、その列でハッシュパーティションを作成するのがおそらく理にかなっています。「今月追加された車両」などのクエリやレポートを作成する場合、または特定の年齢になったときにパーティションを「ロールアウト」する場合は、日付でのパーティション分割が最適です。これは、使用法に基づいて決定する必要があるものです。
3.）詳細については、上記のリンクを参照してください。
ユーザーの質問に基づいて編集：
3秒ごとにレコードを挿入することは、多くのスループットではありません。手順内のチェックを効率的に行うために、usersテーブルに主キーがあることを確認してください。（これは、FKがサポートされている場合でも当てはまります）FKがサポートされている場合、DBはバックグラウンドでこのチェックを実行するため、その意味では、害はありません。チェックがボトルネックになってしまった場合は、チェックを削除して、誤ったユーザーIDを夜間のバッチプロセスとして報告する必要があると感じるかもしれませんが、ユーザーテーブルが比較的小さく、正しくインデックス付けされている場合、これは問題。
別のオプションは、パーティション化されたテーブルまたはパーティション化されていないテーブルを使用して手動でパーティション化（つまりシャーディング）を行うことです。もちろん、パーティション化されていないテーブルでは、ネイティブ外部キーを使用できます。たとえば、車両テーブルを次のように複数のテーブルに分割します。（VehicleNoを「キー」として使用する場合）
VehiclesNosLessThan1000
VehiclesNosLessThan2000
VehiclesNosLessThan..。
VehiclesNosLessThanMAX
ここでは、アプリケーション/ユーザーがテーブルについて知る必要がないように、SPを再度使用する必要があります。SPは、渡されたVehicleNoに基づいて正しいテーブルを挿入/更新する責任があります。また、アプリ/ユーザーがどちらかから選択するテーブルを知る必要がないように、データを選択するためのSPが必要です。すべてのデータに簡単にアクセスできるように、すべてのテーブルを結合するビューを作成できます。
これの利点の1つは、現在MyISAMが更新中のパーティションだけでなく、更新中にパーティションテーブル全体をロックすることです。この方法でテーブルをシャーディングすると、テーブル自体が「パーティション」であるため、その競合が軽減されます。
私が行っている限られたデータに基づいて、おそらく2つのストアドプロシージャを作成します。1つはデータの選択用、もう1つはデータの更新/挿入用であり、アプリケーションでそれらをすべてのアクセスに使用します。次に、プロシージャ内でuser_idキーを適用しながら、最初にVehicleNoでハッシュを介して通常のパーティション分割を試みます。これが問題になる場合は、データの取得と更新の方法に関するすべてのロジックがSP内に含まれているため、アプリケーションを変更することなく、複数のテーブルにまたがるデータのシャーディングに簡単に移行できます。