私は現在、GPS追跡用の大規模なデータベースを持っています。新しい人が私に場所を送信し始めるたびに、私は一意の名前で新しいデータベースを作成します。次に、このテーブルに行を追加し始めます。高度、経度、緯度などの列があります。
状況は、これらのテーブルの一部に100,000を超える場所（行）が含まれている可能性があることです。現在、データベースには約600のテーブルがあります。これらすべてのテーブルを検索するのは非常に困難です。「SHOWtables」クエリを実行してから、各テーブルに対してクエリを実行して、必要なデータを取得する必要があります。
質問はこれに分解されます：これらすべてのテーブルを1,000,000行を超える可能性のある1つの巨大なテーブルに結合する必要があります。次に、1つの列を追加して、さまざまなユーザーを分離します。複数ではなく単一のクエリが必要になるため、クエリの実行がはるかに簡単になります。
これにより、システムが速くなりますか、それとも遅くなりますか？この質問に答えるために、より多くの情報が必要ですか？
適切なインデックスを付けた1,000,000行以上は問題なく機能する可能性がありますが、行がどんどん上がっていくので、すぐにクエリの実行を待つことになります。本当にいい考えではないと思います。あなたができることは、そのようなテーブルを作成し、それにすべての行を挿入し、それに対していくつかのクエリを試すことです。あなたはそれがどれほどうまく機能するかを自分で見るでしょう。そして、念のために、ランダムなデータを生成して、数百万（予想されるサイズまで）増やします。それでもうまく機能する場合は、答えがあります。クエリの速度はハードウェアにも大きく依存するため、このような質問に答えるのは簡単ではありません。いくつかのテストを試してみてください。
すべてのテーブルを同時に定期的に検索する場合は、テーブルを組み合わせてユーザーID列を追加することをお勧めします。このテーブルにインデックスを追加すると（定期的に検索する列の場合）、パフォーマンスが大幅に向上します。
特に結果を並べ替える場合は、ほとんどの場合、単一のクエリの方が、異なるテーブルにまたがる複数のクエリよりも高速になります。
location_id、高度、経度、緯度のテーブルがないのはなぜですか。高度、経度、緯度を組み合わせた一意のキーを用意します。
user_idとlocation_idを持つ別のテーブル（おそらくuser_location）があります。ここでのlocation_idは、上記のテーブルの外部キーです。
user_idとlocation_idは、それぞれのテーブルの主キーであり、自動的にINDEXEDされることを意味するため、問題はありません。
また、ロケーションテーブルはしばらく飽和状態になります。