0

Microsoft は、 SQL 2005 パーティションの変更に関するMSDNエントリで、考えられるいくつかのアプローチを挙げています。

  • 目的のパーティション関数を使用して新しいパーティション テーブルを作成し、INSERT INTO...SELECT FROM ステートメントを使用して、古いテーブルのデータを新しいテーブルに挿入します。
  • ヒープ上にパーティション化されたクラスター化インデックスを作成する
  • DROP EXISTING = ON 句を指定した Transact-SQL CREATE INDEX ステートメントを使用して、既存のパーティション インデックスを削除して再構築します。
  • 一連の ALTER PARTITION FUNCTION ステートメントを実行します。

データが 1 ～ 2 年にわたって分散する、レコードの日付に基づくパーティション (毎月のパーティションのようなもの) を持つ大規模な DB (数百万のレコード) にとって最も効率的な方法は何か考えはありますか?

また、最近の情報に (読み取るために) アクセスすることが多い場合、最後の X 日間はパーティションを保持し、残りのデータはすべて別のパーティションにすることは理にかなっていますか? それとも、残りのデータも分割する方がよいでしょうか (日付範囲に基づくランダム アクセスの場合)。

4

1 に答える 1

2

古いテーブルと新しいテーブルを比較する贅沢が得られるため、最初のアプローチ (新しいパーティション テーブルを作成してそこに挿入する) をお勧めします。新しいテーブル設計に切り替える前に、両方のスタイルのテーブルに対してクエリ プランをテストし、クエリが実際に高速かどうかを確認できます。改善が見られない場合や、最終結果に落ち着く前に、いくつかの異なるパーティショニング関数/スキームを試してみたい場合があります。日付範囲以外で分割したい場合があります - 日付は常に有効ではありません。

私は 300 ～ 500m の行テーブルを 6 ～ 7 年にわたって分散させたデータでパーティショニングを行いましたが、そのテーブル挿入アプローチが最も有用であることがわかりました。

パーティション化の方法について質問されましたが、最善の答えは、クエリが単一のパーティションにヒットするようにパーティションを設計することです。クエリを最近のデータに集中させる傾向があり、WHERE 句でその日付フィールドをフィルター処理する場合は、最新の X 日間に別のパーティションを用意します。

where 句でパーティション化されたフィールドを指定する必要があることに注意してください。そのフィールドを指定していない場合、クエリはおそらくすべてのパーティションにアクセスしてデータを取得することになり、その時点でパフォーマンスが向上することはありません。

それが役立つことを願っています! 私は多くのパーティショニングを行ってきました。テーブル構造とクエリの例をいくつか投稿したい場合は、環境により良い答えを得るのに役立ちます.

于 2008-10-19T17:12:12.733 に答える