19

データ ウェアハウス データベースを使用していますが、SQL Server 2014 の新しいカーディナリティ エスティメーターの問題に直面しています。

データベース サーバーを SQL Server 2014 にアップグレードした後、クエリのパフォーマンスに大きな違いがあることがわかりました。一部のクエリの実行が大幅に遅くなります (SQL 2012 では 30 秒、SQL 2014 では 5 分)。実行計画を調査した後、SQL Server 2014 でのカーディナリティの見積もりがかなりずれており、その理由を見つけることができないことがわかりました。

SQL 2012 と SQL 2014 のクエリ実行プラン (左上の演算子) の例を次に示します。

推定行数

いくつかの詳細:

  • 私のクエリは、典型的なデータ ウェアハウスのファクト テーブル ロード クエリです。トランザクション テーブルにクエリを実行し、多数 (15 ～ 20) のディメンション テーブルを結合します (ディメンション テーブルから結合されるレコードは常に 0 または 1 です)。

  • 統計が最新であることを確認するために、(FULLSCAN を使用して) すべてのテーブルの統計を更新しました。

  • ディメンション テーブルのビジネス キーにはインデックスが付けられます (一意の非クラスター化インデックス)。このインデックスの一意性のために、古い基数推定器 (SQL 2012) は最大があると正しく想定しているように思えます。結合する 1 つのレコード (実行計画でレコードの推定数は変わりません)。

問題を最も単純な例に絞り込もうとしました - 2 つの結合を持つ SELECT:

加入

SQL 2012 と SQL 2014 での演算子 1 と 2 のカーディナリティの見積もりは次のとおりです。

           | Est.rows - SQL2012 | Est.rows - SQL2014
Operator 1 |               7653 |               7653
Operator 2 |               7653 |              10000

ご覧のとおり、SQL Server 2014 は見積もりを 30% 以上下回っています (10000 対 7653)。私はcaを持っているので。典型的なクエリで 15 ～ 20 の結合が行われると、最終的な見積もりは大きく外れます。

データベースを下位の互換性モード (110) にすると正常に動作しますが (SQL Server 2012 と同じ)、この動作の理由を知りたいです。SQL Server 2014 のカーディナリティ エスティメータの結果が間違っているのはなぜですか?

4

3 に答える 3

6

今日、この興味深い質問に対する簡単な答えはないと思います。私が知っている最良の答えは、次のビデオです: http://channel9.msdn.com/events/TechEd/NorthAmerica/2014/DBI-B331#fbid= . 新旧の推定量の例が多数あります。動画の長さは約50分以上ですが、時間の価値があります。

この質問に関連するビデオの要約:

カーディナリティ推定の古い仮定:

  1. 均一性 - データは均一に分散されます。
  2. 独立性 - 列 1 は列 2 と関係がありません。
  3. 封じ込め - 2 つの属性が同じである可能性がある場合、それらは同じであると見なされます。
  4. 包含 - 一致する必要があります。

SQL SERVER 2014 で SQL SERVER 2012 カーディナリティ エスティメーターを使用するには、次のオプションを使用します。

  • オプション (querytraceon 9481) -- 2012 年に戻す

新しい推定器は何をしていますか (ビデオに基づく):

  • SQL Server は、インデックスの平均選択性を使用し、キーの密度をインデックス内の行の総数に掛けて行数を推定します。
  • 新しい推定量は、ぎざぎざの分布ではうまく機能しません。
  • エスティメータ間のほとんどの違いは、WHERE 句に基づいています。
  • 新しいカーディナリティ エスティメータは、テーブル間に相関関係があると考えています。
  • フィルタリングされた統計を作成して、クエリを改善できます。( http://msdn.microsoft.com/en-us/library/ms188038.aspx )

やること / チェックリスト:

1. Auto Create / Update Stats
2.  Check database compatibility mode (120/110)
3.  Test using query trace flags
4.  XML showplan

カーディナリティ エスティメータの新機能を更新 する (SQL Server 2016)

  1. より正確です。
  2. CE は、クエリが返す可能性のある行数を予測します
  3. SQL Server 2016 クエリ ストア
  4. CE の基数予測を追跡するための別のオプションは、query_optimizer_estimate_cardinality という名前の拡張イベントを使用することです。
  5. CE は、統計が最後に収集されたときよりも最大値が高くなる可能性があることを理解しています
  6. CE は、同じテーブルでフィルター処理された述語が相関していることが多いことを理解しています。
  7. CE は、異なるテーブルからフィルター処理された述語間の相関関係を想定しなくなりました

詳細:

https://docs.microsoft.com/en-us/sql/relational-databases/performance/cardinality-estimation-sql-server

https://www.sqlshack.com/query-optimizer-changes-in-sql-server-2016-explained/

于 2014-11-10T20:05:13.927 に答える
3

複数列の選択性の推定に関するこの問題に遭遇しているのではないかと思います。

http://www.sqlskills.com/blogs/kimberly/multi-column-statistics-exponential-backoff/

新しい CE にはまだ癖があるようです。概説したように TF 4137 も使用してみて、それが役立つかどうかを確認してください。

最後に、最新の CU 上にあり、TF 4199 で実行されていることを確認して、すべてのクエリ オプティマイザーの修正を包括的に有効にします。可能な場合は最初に非運用環境でこれをテストし、設定をグローバルに有効にするときに他のクエリの回帰に注意してください。

于 2015-02-01T06:16:43.470 に答える