日付に基づいて水平方向に分割されたテーブル「FactsTable1」があり、その上にクラスター化された列ストアインデックスもあります。次のクエリを実行しています。
クエリ1:
SELECT
SUM([Column1]),
SUM([Column2]),
SUM([Column3]),
SUM([Column4]),
SUM([Column5]),
SUM([Column6])
FROM [FactsTable1]
クエリ2:
SELECT
SUM([Column1])
FROM [FactsTable1]
'STATISTICS IO,TIME ON
'を使用して上記の2つのクエリを実行すると、出力として次のメッセージが表示されました。
クエリ1:
SQL Server parse and compile time:
CPU time = 94 ms, elapsed time = 95 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
Warning: Null value is eliminated by an aggregate or other SET operation.
(1 row(s) affected)
Table 'FactsTable1'. Scan count 1, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 1184, lob physical reads 31, lob read-ahead reads 0.
Table 'FactsTable1'. Segment reads 22, segment skipped 0.
SQL Server Execution Times:
CPU time = 218 ms, elapsed time = 247 ms.
クエリ2:
SQL Server parse and compile time:
CPU time = 46 ms, elapsed time = 57 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
Warning: Null value is eliminated by an aggregate or other SET operation.
(1 row(s) affected)
Table 'FactsTable1'. Scan count 1, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 198, lob physical reads 0, lob read-ahead reads 0.
Table 'FactsTable1'. Segment reads 22, segment skipped 0.
SQL Server Execution Times:
CPU time = 47 ms, elapsed time = 52 ms.
複数回チェックすると、常にCPU時間に多少の違いが見られますが、クエリコストに違いは見られません。その常に50-50%。
だから私は知りたいのですが、列の数はクラスター化された列ストアインデックスを持つパーティションテーブルのクエリのパフォーマンスに影響しますか?はいの場合、パフォーマンスの違いを測定する方法はありますか?
追加情報:
だから私は知りたいのですが、列の数はクラスター化された列ストアインデックスを持つパーティションテーブルのクエリのパフォーマンスに影響しますか?はいの場合、パフォーマンスの違いを測定する方法はありますか?
はい、列の数は、STATISTICS IO出力の最後の行に示されているように、列ストアクエリのパフォーマンスにとって重要な要素であることがよくあります。これは、列ストアが必要な列のデータのみを許可するためです。スキャンするクエリ。経過時間の差(247ミリ秒と52ミリ秒)は、クエリのパフォーマンスが列の数に比例することを示します(予想どおり)。経過時間はパフォーマンスの主要な指標です。
通常、経過時間を主要業績評価指標として使用できますが、考慮すべき他の要因があります。共有リソースでのキャッシュデータまたはその他のアクティビティは、タイミングに影響を与える可能性があります。この場合、両方のプランはシリアルであるため、経過時間は相対的なパフォーマンスで同等であり、分離された環境での反復可能なテストを想定しています。ただし、一方のプランがシリアルでもう一方のプランがパラレルの場合、パラレルプランは実時間よりも多くのCPU時間を消費し、偏った結論または誤った結論をもたらす可能性があります(たとえば、より多くの列を含むクエリの実行速度が速くなります)。