統計の更新

SQL Serverの最後のいくつかのリリースでは、既存の機能の改善だけでなく、多数の新機能が導入されています。見落としがちなエンジンの1つの領域は、統計です。結局のところ、統計は引き続き同じ方法で作成され、データの分散について通知し、クエリオプティマイザーによって使用されます...何が違うのですか？統計の基本的な機能は同じですが、クエリオプティマイザーによる統計の使用方法は、使用しているカーディナリティ推定量によって異なります。統計の更新に関連するいくつかの注目すべき変更もあり、統計情報の表示に関する新機能が追加されました。全体として、最新リリース全体でのこれらの変更により、予期していなかったSQLServerの動作に変化が生じる可能性があります。

注：この投稿はSQL Server 2012以降に最も当てはまりますが、参照用（および楽しみ用）に以前のリリースの詳細が含まれています。

SQL Server 7.0

ヒストグラムのステップ数は300に制限されています。SQLServer6.5以前では、ヒストグラムには、キーの最初の列のサイズに基づいて、2Kページに収まるステップ数が含まれていました。
「統計の自動更新」データベースオプションが導入されました。以前は、統計は手動でのみ更新されていました。

SQL Server 2000

ヒストグラムのステップ数が300から200に減少します（キーの最初の列でNULLが許可されていると仮定すると、NULLのステップを含めると、技術的には201になります）。

SQL Server 2005

FULLSCANを使用する統計の更新は並行して実行できます。
トレースフラグ2389および2390は、投稿「昇順キーおよび自動クイック修正統計」で説明されている昇順キーの問題を支援するためにSP1に導入されました。このシナリオの詳細な例は、私の投稿のTraceFlag2389と新しいCardinalityEstimatorに記載されています。
インスタンスオプション「統計を非同期に自動的に更新」が導入されました。これを有効にするには、[統計を自動的に更新する]オプションも有効にする必要があることに注意してください。このオプションの機能がわからない場合は、ALTERDATABASESETオプションのドキュメントを確認してください。これはGlennが推奨する設定です（以下で参照する彼の投稿に記載されています）が、統計の自動更新がクエリのパフォーマンスに与える影響に記載されているように、潜在的な問題に注意することが重要だと思います。

注： SQLServer2008からSQLServer2012では、この設定に関連するメモリリークがあります。詳細については、Glennの投稿「SQLServer2008の重要な修正プログラム」を参照してください。

SQL Server 2008

フィルタリングされた統計が導入され、これらはフィルタリングされたインデックスとは別に作成できます。クエリオプティマイザー（TimChapmanの投稿ThePains ofFilteredIndexesおよびPaulWhiteの投稿OptimizerLimitationswith Filtered Indexes）の投稿に関して、フィルター処理されたインデックスにはいくつかの制限があり、変更を追跡するカウンターの動作を理解することが重要です（およびしたがって、自動更新をトリガーできます）。詳細については、キンバリーの投稿「フィルターされたインデックスとフィルターされた統計」が大幅に古くなる可能性があります。また、データの偏りを分析し、フィルターされた統計を作成してクエリオプティマイザーに詳細情報を提供できる場所を推奨する、彼女のストアドプロシージャを確認することをお勧めします。これは、述語で頻繁に使用されるVLTと列全体の偏った分布を持ついくつかの大規模な顧客に実装しました。
2つの新しいカタログビューsys.statsとsys.stats_columnsが追加され、統計と含まれる列をより簡単に把握できるようになりました。廃止されて提供される情報が少ないsp_helpstatsの代わりに、これら2つのビューを使用してください。

SQL Server 2008R2 SP1

トレースフラグ2371が使用可能になりました。これを使用して、統計の自動更新を実行するために必要な変更の数を減らすことができます。念のため、私はスケジュールされたジョブを通じて定期的に統計を更新し、安全のために自動更新を有効のままにしておくのが好きです。

SQL Server 2008R2 SP2

関数sys.dm_db_stats_propertiesが含まれています。この関数は、DBCC SHOW_STATISTICSのヘッダーにあるのと同じ情報と、変更を追跡し、プログラムで更新が必要かどうかを判断するために使用できる変更列を提供します。統計を更新するためにジョブを使用することに対する私の好みを覚えていますか？このDMFを使用すると、その作業が大幅にスマートになります。これで、変更されたデータの量を確認し、特定の割合のデータが変更された場合にのみ統計を更新できます。スリック。

SQL Server 2012

行が変更されていない場合、統計を更新してもプランが無効になることはありません。これは多くの人を驚かせるものであり、キンバリーには楽しい投稿があります。その計画がひどく間違っていた原因は何ですか。統計を更新する必要がありますか。これは、これを理解するための彼女の冒険を紹介しています。

SQL Server 2012 SP1

DBCC SHOW_STATISTICSには、SELECT権限のみが必要です。以前は、ユーザーがsysadminのメンバーであるか、db_ownerまたはdb_ddladminデータベースロールのメンバーである必要がありました。これは、トレースフラグ9485を使用してグローバルに無効にできます。
sys.dm_db_stats_propertiesが含まれています（上記の2008R2 SP2ノートを参照）

SQL Server 2012 SP2

累積アップデート1では、トレースフラグ2389および2390が使用されている場合でも、昇順キーが正しく識別されないことに関連する修正が導入されています。これには、KB 2952101に記載されているように、CU1に加えてトレースフラグ4139が必要です。

SQL Server 2014

新しいCardinalityEstimatorが導入され、データベース互換モードを120に設定するか、トレースフラグ2312を使用して実装されます。新しいCEについて何も読んでいない場合は、CardinalityEstimationのドキュメントから始めてJoeを読むことをお勧めします。詳細については、Sackのホワイトペーパー「SQLServer 2014CardinalityEstimatorを使用したクエリプランの最適化」を参照してください。
昇順キーのトレースフラグ2389および2390の動作は、データベース互換モードを介して実装されるようになりました。データベース互換モードが120（またはそれ以降のリリースではそれ以上）に設定されている場合、SQL Serverのトレースフラグ2389および2390を使用して、昇順のキーを持つ統計を識別する必要はありません。
増分統計がパーティションに導入され、新しいDMFsys.dm_db_incremental_stats_propertiesで表示できます。インクリメンタル統計は、テーブル全体の統計を更新せずに、パーティションの統計を更新する方法を提供します。ただし、増分統計からの追加の統計情報は、クエリオプティマイザーでは使用されませんが、テーブルのメインヒストグラムに折りたたまれます。
CU2には、SQL Server 2012 SP2について前述したものと同じ修正が含まれており、トレースフラグ4139も必要です。

SQL Server 2014 SP1

トレースフラグ7471はCU6にバックポートされており、以下に示すように、元々SQLServer2016で使用可能でした。

SQL Server 2016

データベース互換モードが130に設定されている場合、統計の自動更新のしきい値を下げるためにトレースフラグ2371は不要になりました。SQLServerでの自動統計（AUTO_UPDATE_STATISTICS）の動作の制御を参照してください。
FULLSCANだけでなく、SAMPLEを使用すると、統計の更新を並行して実行できます。これは互換モード（130である必要があります）に関連付けられていますが、より高速な更新を提供し、メンテナンスウィンドウを短縮する可能性があります。 Aaron Bertrandは、彼の投稿でこの機能強化について語っています。統計更新の潜在的な改善：MAXDOP。
トレースフラグ7471がCU1に導入され、単一のテーブルに対して複数のUPDATE STATISTICSコマンドを同時に実行できるようになりました。ジョナサンは、これを使用する方法の優れた例を、彼の投稿「並列統計再構築のサポートの改善」で提供しています。

SQL Server 2016 SP1

クエリヒントオプションENABLE_HIST_AMENDMENT_FOR_ASC_KEYSが、トレースフラグ4139と同等のFORHINT引数とともに導入されました。
DMF sys.dm_db_stats_histogramはCU2で公開されます。これは、DBCCSHOW_STATISTICSから出力されるヒストグラムの代替手段です。両方の情報は同じです。自分にとって簡単なもの、または解決する必要のある問題により適したものを使用してください。
オプションPERSIST_SAMPLE_PERCENTがCU4に導入されました。これを使用すると、統計が更新されるたびに同じサンプリングレートを強制的に使用できます。この動作の例は、「統計の永続的なサンプリングレート」の投稿にあります。

SQL Server 2017

PERSIST_SAMPLE_PERCENTオプションはCU1で使用できます（詳細については、2016 SP1エントリを参照してください）。
属性StatsInfoTypeおよびOptimizerStatsUsageTypeがクエリプランに追加されます。クエリプランには、クエリの最適化中に使用される統計が一覧表示されます。これはCU3で利用可能であり、CEバージョン（120以降）に関連付けられています。これはかなりクールです！これを試す機会はまだありませんが、以前にこの情報を取得するには、文書化されていないトレースフラグを使用する必要がありました。
CU3では、CREATESTATISTICSおよびUPDATESTATISTICSのMAXDOPオプションも導入されました。これらのオプションを使用して、インスタンスまたはデータベースのMAXDOP値をオーバーライドできます。
CU3でのもう1つの追加：UdfCpuTime属性とUdfElapsedTime属性は、スカラー値のUDFの実行統計を表すクエリプランにあります。

概要

新しいリリースへのアップグレードを検討している場合、または最近アップグレードした場合は、これらの変更がソリューションに与える影響に注意してください。 2005/2008 / 2008R2から2014または2016にアップグレードした後、パフォーマンスの問題について多くのクライアントから連絡がありました。多くの場合、アップグレード前に適切なテストが完了していませんでした。

これは、クライアントのアップグレードを支援するときに私たちが本当に注力していることです。ダウンタイムをほとんど発生させずに本番インスタンスをあるバージョンから別のバージョンに移動する手順を超えて、アップグレードの翌日がDBAと開発者にとって退屈なものであることを確認したいと思います。

単にアップグレードプロセスをテストするのではなく、アップグレード後のシステムがどのようになるかをテストします。新しい環境では、古い環境と同じトレースフラグが必要ですか？どのデータベース設定を調整する必要がありますか？クエリのパフォーマンスは変化しますか？良くも悪くも？生産をアップグレードする前にこれらの質問に対する答えがわからない場合は、1〜数日間の消火活動、Sev 1の呼び出し、机での食事、十分な睡眠がないこと、そして誰が他に何を知っているかを知ることになります。。

上記の新機能と機能の変更の影響を理解し、アップグレードを計画し、可能な限りテストするために、事前に時間を取ってください。