1

Below is the link explaining my the table and the situation:

Why does the presence of primary key on the table significantly enhance the performance of column-store indexes?

When comparing the two situations, one where the query is run using the column-store index and the other, where the query is run on a simple heap. When I compare the two results, I observe that even though the query with the column-store performs better than the other case, when simply run on a heap. But, the query using the column-store index involves a physical read(1) while the original one doesn't.

Both the queries have the same execution plan. Also, I run the queries in both the situations in warm and cold buffers. In a cold buffer, the original query requires 4 physical reads, while in a warn buffer, it required 0 physical reads. The behavior of the query using the column-store indexes however remains the same. Is there any particular reason behind this?

4

1 に答える 1

1

SQL Server 2012 では、新しい DMV、新しいメモリ管理、COLUMNSTORE インデックスの追加など、多くの変更が行われました。

問題: 列ストア インデックスを使用してクエリを実行すると、物理的な読み取りが発生します (データ キャッシュ ミス)。

前提条件: SQL Server 2012、クラスター化された列ストア インデックス

免責事項: これは回答ではなく、議論を進めるための試みです。

列ストア (SQL Server 2012 の新機能) は列ストア インデックス オブジェクト (圧縮) をキャッシュし、このメモリはバッファー プールとは別のものです。

SQL Server 2012 では、単一ページの 8 KB と複数ページのアロケーター (8 KB を超える要求の場合) を置き換える、SQLOS の新しい任意ページ アロケーターによってメモリ割り当てが簡素化されます。

バッファー プールと列ストア キャッシュの両方が、任意ページ アロケーターを介してメモリを割り当てます。ただし、バッファー プールはデータ ページをキャッシュし、列ストアは圧縮された列ストア インデックス オブジェクトをキャッシュします。

データ キャッシュ ミスの原因として考えられるのは、列ストア メモリの割り当てによるバッファ プールへのメモリ プレッシャが「ページ フラッシュ」を引き起こす可能性があることです。

私は本SQL Server 2012 internalsを参照として使用します。さらに、SQL Server 2012 で COLOMNSTORE インデックスがメモリを使用する方法を説明しているこの記事: クラスター化された列ストア インデックス – パート 38 (「メモリ構造」)

于 2015-04-03T21:38:18.907 に答える