パーティション テーブルとパーティション インデックスPartitioned Tables and Indexes

適用対象: ○SQL Server ○Azure SQL Database XAzure SQL Data Warehouse XParallel Data WarehouseAPPLIES TO: yesSQL Server yesAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

SQL ServerSQL Server では、テーブルおよびインデックスのパーティション分割をサポートします。supports table and index partitioning. パーティション テーブルとパーティション インデックスのデータは、データベース内の複数のファイル グループに分散できるように、複数の単位に分割されます。The data of partitioned tables and indexes is divided into units that can be spread across more than one filegroup in a database. 行のグループが各パーティションにマップされるように、データは行方向にパーティション分割されます。The data is partitioned horizontally, so that groups of rows are mapped into individual partitions. 1 つのインデックスまたはテーブルのすべてのパーティションは、同じデータベース内に存在する必要があります。All partitions of a single index or table must reside in the same database. データに対するクエリまたは更新の実行時は、テーブルやインデックスが 1 つの論理エンティティとして扱われます。The table or index is treated as a single logical entity when queries or updates are performed on the data. SQL Server 2016 (13.x)SQL Server 2016 (13.x) SP1 より前では、パーティション テーブルとパーティション インデックスは、SQL ServerSQL Server のすべてのエディションで使用できるわけではありません。Prior to SQL Server 2016 (13.x)SQL Server 2016 (13.x) SP1, partitioned tables and indexes were not available in every edition of SQL ServerSQL Server. SQL ServerSQL Server の各エディションでサポートされる機能の一覧については、「Editions and Supported Features for SQL Server 2016」 (SQL Server 2016 のエディションとサポートされる機能) を参照してください。For a list of features that are supported by the editions of SQL ServerSQL Server, see Editions and Supported Features for SQL Server 2016.

重要

SQL Server 2017SQL Server 2017 では、既定で最大 15,000 個のパーティションをサポートします。supports up to 15,000 partitions by default. SQL Server 2012 (11.x)SQL Server 2012 (11.x) 以前のバージョンでは、パーティションの数は既定で 1,000 に制限されていました。In versions earlier than SQL Server 2012 (11.x)SQL Server 2012 (11.x), the number of partitions was limited to 1,000 by default. x86 ベースのシステムでは、パーティション数が 1,000 を超えるテーブルまたはインデックスを作成できますが、サポートされていません。On x86-based systems, creating a table or index with more than 1,000 partitions is possible, but is not supported.

パーティション分割の利点Benefits of Partitioning

大きなテーブルやインデックスをパーティション分割することで、次のような管理上およびパフォーマンス上の利点が得られます。Partitioning large tables or indexes can have the following manageability and performance benefits.

  • データ コレクション全体の整合性を保ちながら、データ サブセットの転送やアクセスを迅速かつ効率的に行うことができるようになります。You can transfer or access subsets of data quickly and efficiently, while maintaining the integrity of a data collection. たとえば、OLTP システムから OLAP システムへのデータの読み込みなどの操作は、データがパーティション分割されていない場合は数分から数時間かかりますが、数秒で実行されるようになります。For example, an operation such as loading data from an OLTP to an OLAP system takes only seconds, instead of the minutes and hours the operation takes when the data is not partitioned.

  • 1 つまたは複数のパーティションでのメンテナンス操作をより迅速に実行できます。You can perform maintenance operations on one or more partitions more quickly. テーブル全体ではなく、これらのデータ サブセットのみを対象にできるので、操作がより効率化されます。The operations are more efficient because they target only these data subsets, instead of the whole table. たとえば、1 つまたは複数のパーティションでデータを圧縮するか、インデックスの 1 つまたは複数のパーティションを再構築するかを選択できます。For example, you can choose to compress data in one or more partitions or rebuild one or more partitions of an index.

  • 頻繁に実行するクエリの種類とハードウェア構成に基づいて、クエリのパフォーマンスを改善できる場合があります。You may improve query performance, based on the types of queries you frequently run and on your hardware configuration. たとえば、クエリ オプティマイザーで 2 つ以上のパーティション テーブル間の等結合クエリを行う場合、そのパーティション分割列が、テーブルが結合される列と同じであれば、処理がより高速になります。For example, the query optimizer can process equi-join queries between two or more partitioned tables faster when the partitioning columns are the same as the columns on which the tables are joined. 詳細については、下の「クエリ」をご覧ください。See Queries below for further information.

SQL ServerSQL Server により I/O 操作用にデータの並べ替えが実行される場合、まずパーティションでデータが並べ替えられます。When SQL ServerSQL Server performs data sorting for I/O operations, it sorts the data first by partition. SQL ServerSQL Server では、一度に 1 つのドライブにしかアクセスできないので、パフォーマンスが低下することがあります。accesses one drive at a time, and this might reduce performance. データの並べ替えのパフォーマンスを向上させるには、RAID を構成して複数のディスク間でパーティションのデータ ファイルをストライプします。To improve data sorting performance, stripe the data files of your partitions across more than one disk by setting up a RAID. この方法を使用すると、 SQL ServerSQL Server では今までどおりデータがパーティションで並べ替えられますが、すべてのドライブの各パーティションに同時にアクセスできるようになります。In this way, although SQL ServerSQL Server still sorts data by partition, it can access all the drives of each partition at the same time.

さらに、テーブル全体ではなくパーティション レベルでのロックのエスカレーションを有効にしてパフォーマンスを向上させることができます。In addition, you can improve performance by enabling lock escalation at the partition level instead of a whole table. これにより、テーブルでのロックの競合を減らすことができます。This can reduce lock contention on the table. パーティションへのロックのエスカレーションを有効にしてロックの競合を減らすには、ALTER TABLE ステートメントの LOCK_ESCALATION オプションを AUTO に設定します。To reduce lock contention by allowing lock escalation to the partition, set the LOCK_ESCALATION option of the ALTER TABLE statement to AUTO.

コンポーネントおよび概念Components and Concepts

テーブルおよびインデックスのパーティション分割に関連する用語を次に示します。The following terms are applicable to table and index partitioning.

パーティション関数Partition function

テーブルまたはインデックスの行を、パーティション分割列と呼ばれる特定の列の値に基づいて、一連のパーティションにマップする方法を定義するデータベース オブジェクト。A database object that defines how the rows of a table or index are mapped to a set of partitions based on the values of certain column, called a partitioning column. つまり、テーブルのパーティションの数とパーティションの境界の定義方法は、パーティション関数によって定義されます。That is, the partition function defines the number of partitions that the table will have and how the boundaries of the partitions are defined. たとえば、販売注文データを格納するテーブルの場合、販売日などの datetime 列に基づいて、月別の 12 のパーティションに分割できます。For example, given a table that contains sales order data, you may want to partition the table into twelve (monthly) partitions based on a datetime column such as a sales date.

パーティション構成Partition scheme

パーティション関数のパーティションを一連のファイル グループにマップするデータベース オブジェクト。A database object that maps the partitions of a partition function to a set of filegroups. パーティションを別々のファイル グループに配置する主な理由は、パーティションのバックアップ操作を個別に実行できるようにすることです。The primary reason for placing your partitions on separate filegroups is to make sure that you can independently perform backup operations on partitions. これは、バックアップを個別のファイル グループで実行できるからです。This is because you can perform backups on individual filegroups.

パーティション分割列Partitioning column

パーティション関数が、テーブルまたはインデックスをパーティション分割するために使用するテーブルまたはインデックスの列。The column of a table or index that a partition function uses to partition the table or index. パーティション関数に参加する計算列は、明示的に PERSISTED とマークされている必要があります。Computed columns that participate in a partition function must be explicitly marked PERSISTED. timestamp型を除き、インデックス列として使用できるすべてのデータ型をパーティション分割列として使用できます。All data types that are valid for use as index columns can be used as a partitioning column, except timestamp. ntexttextimagexmlvarchar(max)nvarchar(max) 、または varbinary(max) データ型を指定することはできません。The ntext, text, image, xml, varchar(max), nvarchar(max), or varbinary(max) data types cannot be specified. また、Microsoft .NET Framework 共通言語ランタイム (CLR) ユーザー定義型の列とエイリアス データ型の列を指定することはできません。Also, Microsoft .NET Framework common language runtime (CLR) user-defined type and alias data type columns cannot be specified.

固定されたインデックスAligned index

対応するテーブルと同じパーティション構成に基づいて構築されたインデックス。An index that is built on the same partition scheme as its corresponding table. テーブルとインデックスが固定されている状態では、両者のパーティション構造を保ったまま SQL ServerSQL Server がパーティションをすばやく効率的に切り替えることができます。When a table and its indexes are in alignment, SQL ServerSQL Server can switch partitions quickly and efficiently while maintaining the partition structure of both the table and its indexes. ベース テーブルに固定させるために、インデックスを同じ名前のパーティション関数に加える必要はありません。An index does not have to participate in the same named partition function to be aligned with its base table. ただし、インデックスとベース テーブルのパーティション関数が次の点で基本的に同じでなければなりません。However, the partition function of the index and the base table must be essentially the same, in that:

  1. パーティション関数の引数に同じデータ型が含まれている。The arguments of the partition functions have the same data type.
  2. 同数のパーティションが定義されている。They define the same number of partitions.
  3. パーティションに同じ境界値が定義されている。They define the same boundary values for partitions.

クラスター化インデックスのパーティション分割Partitioning Clustered Indexes

クラスター化インデックスをパーティション分割するときは、クラスター化キーにパーティション分割列を含める必要があります。When partitioning a clustered index, the clustering key must contain the partitioning column. 一意でないクラスター化インデックスをパーティション分割するとき、クラスター化キーでパーティション分割列を明示的に指定しない場合は、SQL ServerSQL Server の既定動作によりクラスター化インデックスのキーの一覧にパーティション分割列が追加されます。When partitioning a nonunique clustered index, and the partitioning column is not explicitly specified in the clustering key, SQL ServerSQL Server adds the partitioning column by default to the list of clustered index keys. クラスター化インデックスが一意である場合、クラスター化インデックス キーにパーティション分割列を含めるように明示的に指定する必要があります。If the clustered index is unique, you must explicitly specify that the clustered index key contain the partitioning column.

非クラスター化インデックスのパーティション分割Partitioning NonClustered Indexes

一意の非クラスター化インデックスをパーティション分割するときは、インデックス キーにパーティション分割列を含める必要があります。When partitioning a unique nonclustered index, the index key must contain the partitioning column. 一意でない非クラスター化インデックスをパーティション分割するときは、ベース テーブルにインデックスを固定するため、SQL ServerSQL Server の既定動作によりパーティション分割列がインデックスの非キー (付加) 列として追加されます。When partitioning a nonunique, nonclustered index, SQL ServerSQL Server adds the partitioning column by default as a nonkey (included) column of the index to make sure the index is aligned with the base table. 既にパーティション分割列がインデックスに存在している場合、SQL ServerSQL Server は追加を行いません。SQL ServerSQL Server does not add the partitioning column to the index if it is already present in the index.

固定されていないインデックスNon-aligned index

対応するパーティション テーブルから個別に分割されたインデックス。An index partitioned independently from its corresponding table. つまり、インデックスのパーティション構成が異なっているか、インデックスがベース テーブルとは別のファイル グループに配置されています。That is, the index has a different partition scheme or is placed on a separate filegroup from the base table. 次のような場合、固定されていないパーティション インデックスをデザインすると便利です。Designing an non-aligned partitioned index can be useful in the following cases:

  • ベース テーブルがパーティション分割されていない。The base table has not been partitioned.
  • インデックス キーが一意であり、テーブルのパーティション分割列を含んでいない。The index key is unique and it does not contain the partitioning column of the table.
  • 異なる結合列を使用して多くのテーブルが併置されている結合にベース テーブルを加える。You want the base table to participate in collocated joins with more tables using different join columns.

パーティションの解消Partition elimination

クエリ オプティマイザーがクエリのフィルター条件を満たすために、関連するパーティションのみにアクセスするときに使用されるプロセス。The process by which the query optimizer accesses only the relevant partitions to satisfy the filter criteria of the query.

パフォーマンスに関するガイドラインPerformance Guidelines

新しいパーティション数の制限が 15,000 になったことは、メモリ、パーティション インデックス操作、DBCC コマンド、およびクエリに影響します。The new, higher limit of 15,000 partitions affects memory, partitioned index operations, DBCC commands, and queries. ここでは、パーティション数が 1,000 を超えた場合のパフォーマンスへの影響について説明し、必要に応じた回避策を示します。This section describes the performance implications of increasing the number of partitions above 1,000 and provides workarounds as needed. パーティション数の上限が 15,000 になると、データを保存できる期間が長くなります。With the limit on the maximum number of partitions being increased to 15,000, you can store data for a longer time. ただし、データの保持期間は必要最小限とし、パフォーマンスとパーティション数とのバランスをとる必要があります。However, you should retain data only for as long as it is needed and maintain a balance between performance and number of partitions.

プロセッサのコアとパーティションの数に関するガイドラインProcessor Cores and Number of Partitions Guidelines

並列操作でのパフォーマンスを最大化するには、プロセッサのコアと同じ数 (SQL ServerSQL Server で利用できる並列処理プロセッサの最大数である 64 個まで) のパーティションを使用することをお勧めします。To maximize performance with parallel operations, we recommend that you use the same number of partitions as processor cores, up to a maximum of 64 (which is the maximum number of parallel processors that SQL ServerSQL Server can utilize).

メモリ使用量とガイドラインMemory Usage and Guidelines

使用するパーティション数が多い場合は、16 GB 以上の RAM を使用することをお勧めします。We recommend that you use at least 16 GB of RAM if a large number of partitions are in use. システムに十分なメモリがない場合は、データ操作言語 (DML) ステートメント、データ定義言語 (DDL) ステートメント、およびその他の処理においてメモリ不足によるエラーが発生する場合があります。If the system does not have enough memory, Data Manipulation Language (DML) statements, Data Definition Language (DDL) statements and other operations can fail due to insufficient memory. 16 GB の RAM を搭載したシステムでメモリを集中的に使用するプロセスが多数実行される場合は、多数のパーティションで実行される操作でメモリが不足する可能性があります。Systems with 16 GB of RAM that run many memory-intensive processes may run out of memory on operations that run on a large number of partitions. したがって、メモリを 16 GB よりも大きくするほど、パフォーマンスとメモリの問題が少なくなります。Therefore, the more memory you have over 16 GB, the less likely you are to encounter performance and memory issues.

SQL ServerSQL Server でパーティション インデックスを作成するパフォーマンスは、メモリにより制限される場合があります。Memory limitations can affect the performance or ability of SQL ServerSQL Server to build a partitioned index. テーブルに既にクラスター化インデックスが適用されている場合、パーティション インデックスがベース テーブルまたはクラスター化インデックスに固定されていないとメモリによる制限を特に受けます。This is especially the case when the index is not aligned with its base table or is not aligned with its clustered index, if the table already has a clustered index applied to it. この場合、index create memory サーバー構成オプションを増やすと便利な場合があります。In this case, it may be useful to increase the index create memory Server Configuration Option. 詳細については、「index create memory サーバー構成オプションの構成」を参照してください。For more information, refer to Configure the index create memory Server Configuration Option.

パーティション インデックス操作Partitioned Index Operations

固定されていないインデックスをパーティションが 1, 000 個以上あるテーブルに作成または再構築することは可能ですが、サポートされていません。Creating and rebuilding non-aligned indexes on a table with more than 1,000 partitions is possible, but is not supported. このような操作を行うと、操作中にパフォーマンスが低下したりメモリが過度に消費される可能性があります。Doing so may cause degraded performance or excessive memory consumption during these operations.

固定されたインデックスの作成および再構築にかかる時間は、パーティション数が増えるにつれて長くなります。Creating and rebuilding aligned indexes could take longer to execute as the number of partitions increases. パフォーマンスおよびメモリの問題を回避するために、インデックスの作成および再構築の複数のコマンドを同時に実行しないことをお勧めします。We recommend that you do not run multiple create and rebuild index commands at the same time as you may run into performance and memory issues.

SQL ServerSQL Server でパーティション インデックスを作成するための並べ替えを実行するとき、最初にパーティションごとに 1 つの並べ替えテーブルが作成されます。When SQL ServerSQL Server performs sorting to build partitioned indexes, it first builds one sort table for each partition. 次に、各パーティションのそれぞれのファイル グループ、または SORT_IN_TEMPDB インデックス オプションが指定されている場合は tempdb で並べ替えテーブルが作成されます。It then builds the sort tables either in the respective filegroup of each partition or in tempdb if the SORT_IN_TEMPDB index option is specified. 1 つの並べ替えテーブルを作成するために最低限必要なメモリの量が決まっています。Each sort table requires a minimum amount of memory to build. ベース テーブルに固定するパーティション インデックスを作成すると、並べ替えテーブルは一度に 1 つずつ作成されるのでメモリの消費を抑えることができます。When you are building a partitioned index that is aligned with its base table, sort tables are built one at a time, using less memory. しかし、固定されないパーティション インデックスを作成すると、複数の並べ替えテーブルが同時に作成されます。However, when you are building a nonaligned partitioned index, the sort tables are built at the same time. そのため、このように同時に並べ替えを行うには十分なメモリが必要です。As a result, there must be sufficient memory to handle these concurrent sorts. パーティションの数が多いと、必要なメモリも増えます。The larger the number of partitions, the more memory required. 1 つの並べ替えテーブル、つまりパーティションあたり最低必要なサイズは 40 ページ (1 ページは 8 KB) です。The minimum size for each sort table, for each partition, is 40 pages, with 8 kilobytes per page. たとえば、100 個のパーティションから構成される固定されないパーティション インデックスは、同時に 4,000 (40 * 100) ページを同時に並べ替えることができるメモリが必要です。For example, a nonaligned partitioned index with 100 partitions requires sufficient memory to serially sort 4,000 (40 * 100) pages at the same time. これだけのメモリを使用できれば、作成操作は成功しますがパフォーマンスが低下する場合があります。If this memory is available, the build operation will succeed, but performance may suffer. これだけのメモリを使用できない場合、作成操作は失敗します。If this memory is not available, the build operation will fail. 一方、100 個のパーティションから構成される固定されたパーティション インデックスは、複数の並べ替えが同時に行われることがないので、40 ページを並べ替えることができるメモリがあれば十分です。Alternatively, an aligned partitioned index with 100 partitions requires only sufficient memory to sort 40 pages, because the sorts are not performed at the same time.

固定されたインデックス、固定されないインデックスを問わず、SQL ServerSQL Server がマルチプロセッサ コンピューターで 2 次以上の並列処理によって作成操作を実行している場合、メモリの要件がさらに高くなる場合もあります。For both aligned and non-aligned indexes, the memory requirement can be greater if SQL ServerSQL Server is applying degrees of parallelism to the build operation on a multiprocessor computer. これは並列処理の次数が多いと、メモリの要件も高くなるためです。This is because the greater the degrees of parallelism, the greater the memory requirement. たとえば、SQL ServerSQL Server の並列処理の次数が 4 に設定されている場合、100 個のパーティションから構成される固定されないパーティション インデックスは、同時に 4 基のプロセッサで 4,000 ページを並べ替えるために 16,000 ページ分のメモリが必要です。For example, if SQL ServerSQL Server sets degrees of parallelism to 4, a nonaligned partitioned index with 100 partitions requires sufficient memory for four processors to sort 4,000 pages at the same time, or 16,000 pages. パーティション インデックスが固定されている場合、4 基のプロセッサで 40 ページを並べ替えるため、メモリの要件は 160 (4 * 40) ページまで下がります。If the partitioned index is aligned, the memory requirement is reduced to four processors sorting 40 pages, or 160 (4 * 40) pages. MAXDOP インデックス オプションを使用して、手動で並列処理の次数を減らすことができます。You can use the MAXDOP index option to manually reduce the degrees of parallelism.

DBCC コマンドDBCC Commands

パーティション数が多い場合、DBCC コマンドの実行にかかる時間は、パーティション数が増えるほど長くなります。With a larger number of partitions, DBCC commands could take longer to execute as the number of partitions increases.

クエリQueries

パーティションの解消を使用するクエリは、パーティション数が多くなると、それに応じてパフォーマンスが向上する可能性があります。Queries that use partition elimination could have comparable or improved performance with larger number of partitions. パーティションの解消を使用しないクエリの場合、その実行にかかる時間は、パーティション数が増えるほど長くなります。Queries that do not use partition elimination could take longer to execute as the number of partitions increases.

たとえば、テーブルの行数が 10 億で、 AB、および Cの列があるとします。For example, assume a table has 100 million rows and columns A, B, and C.

  • シナリオ 1 では、テーブルが列 Aで 1,000 個のパーティションに分割されますIn scenario 1, the table is divided into 1000 partitions on column A.
  • シナリオ 2 では、テーブルが列 Aで 10,000 個のパーティションに分割されますIn scenario 2, the table is divided into 10,000 partitions on column A. A でフィルタリングする WHERE 句を持つテーブルでのクエリは、パーティションの解消を実行し、1 つのパーティションをスキャンします。A query on the table that has a WHERE clause filtering on column A will perform partition elimination and scan one partition. シナリオ 2 の場合は、パーティション内でスキャンする行数が少ないので、同じクエリがより高速に実行される可能性があります。That same query may run faster in scenario 2 as there are fewer rows to scan in a partition. 列 B でフィルタリングする WHERE 句を持つクエリは、すべてのパーティションをスキャンします。A query that has a WHERE clause filtering on column B will scan all partitions. シナリオ 1 の場合は、スキャンするパーティション数が少ないので、同じクエリがシナリオ 2 より高速に実行される可能性があります。The query may run faster in scenario 1 than in scenario 2 as there are fewer partitions to scan.

パーティション分割列以外の列に対して TOP や MAX/MIN のような演算子を使用するクエリは、すべてのパーティションを評価する必要があるため、パーティション分割によってパフォーマンスが低下する可能性があります。Queries that use operators such as TOP or MAX/MIN on columns other than the partitioning column may experience reduced performance with partitioning because all partitions must be evaluated.

2 つ以上のパーティション テーブル間での等結合を行うクエリを頻繁に実行する場合、それらのテーブルのパーティション分割列は、テーブルの結合先の列と同じにする必要があります。If you frequently run queries that involve an equi-join between two or more partitioned tables, their partitioning columns should be the same as the columns on which the tables are joined. また、等結合するテーブルまたはテーブルのインデックスを併置する必要があります。Additionally, the tables, or their indexes, should be collocated. つまり、これらのテーブルでは、同じ名前のパーティション関数または名前は異なるが実質的には同じ関数のいずれかが使用されることになります。後者の場合、関数には次のような性質があります。This means that they either use the same named partition function, or they use different ones that are essentially the same, in that they:

  • パーティション分割に使用するパラメーターの数が同数で、対応するパラメーターのデータ型が同じです。Have the same number of parameters that are used for partitioning, and the corresponding parameters are the same data types.
  • 同数のパーティションが定義されているDefine the same number of partitions.
  • パーティションに同じ境界値が定義されているDefine the same boundary values for partitions. このような性質により、パーティション自体を結合できるので、クエリ オプティマイザーでは結合をより高速に処理できます。In this way, the query optimizer can process the join faster, because the partitions themselves can be joined. クエリで、併置されていないか、または結合フィールドでパーティション分割されていない 2 つのテーブルを結合すると、パーティションが存在することが原因で、クエリ処理のパフォーマンスは向上せず、低下することがあります。If a query joins two tables that are not collocated or are not partitioned on the join field, the presence of partitions may actually slow down query processing instead of accelerate it.

パーティション インデックス操作中の統計計算での動作の変更Behavior changes in statistics computation during partitioned index operations

SQL Server 2012 (11.x)SQL Server 2012 (11.x)以降では、パーティション インデックスが作成または再構築された場合、テーブル内のすべての行をスキャンして統計を作成することはできません。Starting with SQL Server 2012 (11.x)SQL Server 2012 (11.x), statistics are not created by scanning all the rows in the table when a partitioned index is created or rebuilt. 代わりに、クエリ オプティマイザーが既定のサンプリング アルゴリズムを使用して統計を生成します。Instead, the query optimizer uses the default sampling algorithm to generate statistics. パーティション インデックスでデータベースをアップグレードした後で、これらのインデックスのヒストグラム データに違いが見つかる場合があります。After upgrading a database with partitioned indexes, you may notice a difference in the histogram data for these indexes. この動作の変更はクエリ パフォーマンスに影響しない可能性があります。This change in behavior may not affect query performance. テーブル内のすべての行をスキャンしてパーティション インデックスの統計を作成するには、FULLSCAN 句で CREATE STATISTICS または UPDATE STATISTICS を使用します。To obtain statistics on partitioned indexes by scanning all the rows in the table, use CREATE STATISTICS or UPDATE STATISTICS with the FULLSCAN clause.

タスクTasks トピックTopic
パーティション関数とパーティション構成の作成方法、およびそれらをテーブルおよびインデックスに適用する方法について説明します。Describes how to create partition functions and partition schemes and then apply these to a table and index. パーティション テーブルとパーティション インデックスの作成Create Partitioned Tables and Indexes

次のホワイトペーパーには、パーティション テーブルおよびパーティション インデックスの戦略と有用な実装について記述されています。You may find the following white papers on partitioned table and index strategies and implementations useful.