1.）FKはパーティションテーブルではサポートされていません。
- 1つのオプションは、レコードを挿入/更新するストアドプロシージャを作成し、挿入が行われる前に、渡されたユーザーIDがusersテーブルに存在することをプロシージャ内で確認することです。アプリケーションやユーザーがチェックをバックドアできるように、SPのみが更新および挿入を許可されるように、テーブルのアクセス許可を設定する必要があります。また、usersテーブルからユーザーを削除する際にも注意が必要です。
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内に含まれているため、アプリケーションを変更することなく、複数のテーブルにまたがるデータのシャーディングに簡単に移行できます。