2

これがシナリオです。古いデータベースにはこの種の設計があります

dbo.Table1998
dbo.Table1999
dbo.Table2000
dbo.table2001
...
dbo.table2011

1998年から2011年までのすべてのデータをこのテーブルdbo.TableAllYearsにマージしました

現在、これらは両方とも「アプリケーション番号」でインデックス付けされており、同じ列数（実際には56列）になっています。

今私が試したとき

select * from Table1998

と

select * from TableAllYears where Year=1998

最初のクエリの行数は139669行@13秒ですが、2番目のクエリの行数は同じですが@30秒です

だから皆さんにとって、私は何かが足りないのですか、それとも複数のテーブルが単一のテーブルよりも優れていますか？

4

4 に答える 4

2

テーブルを年ごとに分割する必要があります。これは、年ごとに異なるテーブルを持つこととほとんど同じです。このようにして、年ごとにクエリを実行すると、単一のパーティションに対してクエリが実行され、パフォーマンスが向上します。

于 2011-04-15T04:00:38.093 に答える
0

1998年のデータを探している場合は、1つのテーブルに1998年のデータのみを含めるのが最善の方法です。これは、データベースがレコードを「検索」する必要はないが、このテーブルのすべてのレコードが1998年のものであることを認識しているためです。Table1998テーブルに「WHEREYear = 1998」句を追加してみると、わずかに良い比較。

個人的には、特にデータが特に大きなデータセットであり、古いデータに対して頻繁にクエリを実行する必要がない場合は、データを複数のテーブルに保持します。その場合でも、複数のテーブルにクエリを実行する代わりに、すべてのテーブルデータを使用してビューを作成し、そのデータでレポートを実行することを検討することをお勧めします。

于 2011-04-15T03:45:27.970 に答える
0

検索している各列にインデックスをドロップしてみてください（where句）。これにより、クエリが大幅に高速化されます。

したがって、この場合、フィールドYearの新しいインデックスを追加します。

于 2011-04-15T03:51:14.370 に答える
0

1つのテーブルを使用する必要があると思います。必然的に、複数年にわたるデータのクエリが必要になり、データを複数のテーブルに分割することが問題になります。クエリとテーブル構造を最適化して、テーブルに何百万もの行を含めることができ、それでも優れたパフォーマンスを維持できるようにすることは非常に可能です。年の列にインデックスが付けられ、クエリに含まれていることを確認してください。データサイズの制限に実際に遭遇した場合は、MySQL 5のパーティショニング機能を使用して、テーブルデータを複数のテーブルであるかのように複数のファイルに保存し、1つのテーブルのように見せることができます。

それにもかかわらず、140k行は何もありません。複数のテーブルに分割するのは時期尚早の最適化である可能性が高く、複数年にわたってデータをクエリする必要がある場合は、パフォーマンスが大幅に低下する可能性があります。

于 2011-04-15T03:51:41.837 に答える