カーディナリティ推定 (SQL Server)Cardinality Estimation (SQL Server)

適用対象: yesSQL Server yesAzure SQL Database noAzure Synapse Analytics (SQL DW) noParallel Data Warehouse APPLIES TO: yesSQL Server yesAzure SQL Database noAzure Synapse Analytics (SQL DW) noParallel Data Warehouse

SQL ServerSQL Server クエリ オプティマイザーは、コストベースのオプティマイザーです。The SQL ServerSQL Server Query Optimizer is a cost-based Query Optimizer. つまり、実行のための推定処理コストが最も低いクエリ プランが選択されます。This means that it selects query plans that have the lowest estimated processing cost to execute. クエリ オプティマイザーでは、主に次の 2 つの要素に基づいてクエリ プランを実行する際のコストが決定されます。The Query Optimizer determines the cost of executing a query plan based on two main factors:

  • クエリ プランの各レベルで処理される行の総数。これをプランのカーディナリティと呼びます。The total number of rows processed at each level of a query plan, referred to as the cardinality of the plan.
  • クエリ内の演算子で指示されているアルゴリズムのコスト モデル。The cost model of the algorithm dictated by the operators used in the query.

最初の要素であるカーディナリティは、2 番目の要素であるコスト モデルの入力パラメーターとして使用します。The first factor, cardinality, is used as an input parameter of the second factor, the cost model. そのため、カーディナリティが向上すると、推定コストが適切になり、その結果実行プランも高速化します。Therefore, improved cardinality leads to better estimated costs and, in turn, faster execution plans.

SQL ServerSQL Server でのカーディナリティ推定は、インデックスまたは統計を作成するときに手動か自動で作成されたヒストグラムから主に取得されます。Cardinality estimation (CE) in SQL ServerSQL Server is derived primarily from histograms that are created when indexes or statistics are created, either manually or automatically. また、SQL ServerSQL Server では、クエリの制約情報および論理再書き込みを使用して、カーディナリティが決定されることもあります。Sometimes, SQL ServerSQL Server also uses constraint information and logical rewrites of queries to determine cardinality.

次の例では、SQL ServerSQL Server を使用してカーディナリティを正確に計算することができません。In the following cases, SQL ServerSQL Server cannot accurately calculate cardinalities. その場合コストが正しく計算されないので、最適なクエリ プランが選択されない場合があります。This causes inaccurate cost calculations that may cause suboptimal query plans. 次に示す構造をクエリで使用しないようにすることで、クエリのパフォーマンスが向上する場合があります。Avoiding these constructs in queries may improve query performance. 別のクエリ式や他の方法で代替できることがあるので、それについても記載してあります。Sometimes, alternative query formulations or other measures are possible and these are pointed out:

  • 同一テーブルの異なる列どうしを比較する比較演算子を述語で使用しているクエリ。Queries with predicates that use comparison operators between different columns of the same table.
  • 次のいずれかの条件に該当し、演算子を述語で使用しているクエリ。Queries with predicates that use operators, and any one of the following are true:
    • 演算子の一方の側で使用されている列の統計が存在しない。There are no statistics on the columns involved on either side of the operators.
    • 統計内の値の分布が不均一であるにもかかわらず、クエリにより選択度の高い値セットがシークされる。The distribution of values in the statistics is not uniform, but the query seeks a highly selective value set. これに該当するのは、主に演算子が等号 (=) 以外である場合です。This situation can be especially true if the operator is anything other than the equality (=) operator.
    • 等しくない (!=) 比較演算子または NOT 論理演算子を述語で使用している。The predicate uses the not equal to (!=) comparison operator or the NOT logical operator.
  • SQL Server の組み込み関数、または引数が定数値でないスカラー値関数かユーザー定義関数を使用するクエリ。Queries that use any of the SQL Server built-in functions or a scalar-valued, user-defined function whose argument is not a constant value.
  • 算術連結演算子または文字列連結演算子によって結合した列を含んでいるクエリ。Queries that involve joining columns through arithmetic or string concatenation operators.
  • クエリのコンパイル時または最適化時に値が確定しない変数を比較するクエリ。Queries that compare variables whose values are not known when the query is compiled and optimized.

この記事では、ご利用のシステムに最適な CE 構成を評価して選択する方法を示しています。This article illustrates how you can assess and choose the best CE configuration for your system. 最も正確なので、ほとんどのシステムで最新の CE のメリットを享受できます。Most systems benefit from the latest CE because it is the most accurate. CE はクエリが返す可能性のある行の数を予測します。The CE predicts how many rows your query will likely return. クエリ オプティマイザーではカーディナリティ予測を使用して、最適なクエリ プランを生成します。The cardinality prediction is used by the Query Optimizer to generate the optimal query plan. 推定が正確であるほど、通常はクエリ オプティマイザーでより最適なクエリ プランを生成できます。With more accurate estimations, the Query Optimizer can usually do a better job of producing a more optimal query plan.

アプリケーション システムには、新しい CE が原因で低速のプランに変更された重要なクエリが含まれている可能性があります。Your application system could possibly have an important query whose plan is changed to a slower plan due to the new CE. そのようなクエリは、次のいずれかのようになります。Such a query might be like one of the following:

  • OLTP (オンライン トランザクション処理) クエリ。頻繁に実行され、その複数のインスタンスがしばしば同時に実行されます。An OLTP (online transaction processing) query that runs so frequently that multiple instance of it often run concurrently.
  • SELECT。OLTP 営業時間中に実行される大量の集計と一緒に実行されます。A SELECT with substantial aggregation that runs during your OLTP business hours.

新規の CE で低速で実行するクエリを識別するための手法があります。You have techniques for identifying a query that performs slower with the new CE. そして、パフォーマンスの問題に対処する方法のオプションもあります。And you have options for how to address the performance issue.

CE のバージョンVersions of the CE

1998 年には、CE の主要な更新プログラムは、互換性レベルが 70 の SQL ServerSQL Server 7.0 の一部でした。In 1998, a major update of the CE was part of SQL ServerSQL Server 7.0, for which the compatibility level was 70. このバージョンの CE モデルは、次の 4 つの基本的な前提条件で設定されています。This version of the CE model is set on four basic assumptions:

  • 非依存性: 異なる列のデータ分布は、相関関係情報があって使用可能な場合を除き、相互に独立しているものと想定されます。Independence: Data distributions on different columns are assumed to be independent of each other, unless correlation information is available and usable.
  • 統一性: 個別の値は等間隔であり、すべて同じ頻度です。Uniformity: Distinct values are evenly spaced and that they all have the same frequency. 具体的には、各ヒストグラム ステップ内では、個別の値は均等に分散し、各値は同じ頻度です。More precisely, within each histogram step, distinct values are evenly spread and each value has same frequency.
  • コンテインメント (単純): ユーザーは存在するデータをクエリします。Containment (Simple): Users query for data that exists. たとえば、2 つのテーブル間の等価結合では、結合の選択度を推定するためにヒストグラムを結合する前に、各入力のヒストグラムの述語選択度1を考慮します。For example, for an equality join between two tables, factor in the predicates selectivity1 in each input histogram, before joining histograms to estimate the join selectivity.
  • 包含: Column = Constant のフィルター述語では、定数が関連付けられた列に実際に存在すると想定されます。Inclusion: For filter predicates where Column = Constant, the constant is assumed to actually exist for the associated column. 対応するヒストグラム ステップが空ではない場合、ステップの個別値のいずれかは述語の値と一致するものと想定されます。If a corresponding histogram step is non-empty, one of the step's distinct values is assumed to match the value from the predicate.

1 述語を満たす行数。1 Row count that satisfies the predicate.

以降の更新プログラムは SQL Server 2014 (12.x)SQL Server 2014 (12.x) 以上 (互換性レベルが 120 以上) に含まれています。Subsequent updates started with SQL Server 2014 (12.x)SQL Server 2014 (12.x), meaning compatibility levels 120 and above. レベル 120 以上の CE 更新プログラムには、最新のデータ ウェアハウスおよび OLTP ワークロードで適切に機能する更新された前提条件とアルゴリズムが組み込まれています。The CE updates for levels 120 and above incorporate updated assumptions and algorithms that work well on modern data warehousing and on OLTP workloads. CE 120 以降では、CE 70 の前提条件から次のモデル前提条件が変更されました。From the CE 70 assumptions, the following model assumptions were changed starting with CE 120:

  • 非依存性相関関係になります:異なる列の値の組み合わせは必ずしも独立していません。Independence becomes Correlation: The combination of the different column values are not necessarily independent. これはより実際のデータ クエリと似ている可能性があります。This may resemble more real-life data querying.
  • 単純なコンテインメントベース コンテインメントになります:ユーザーは存在しないデータをクエリする可能性があります。Simple Containment becomes Base Containment: Users might query for data that does not exist. たとえば、2 つのテーブル間の等価結合では、ベース テーブル ヒストグラムを使用して結合の選択度を推定した後、述語選択度を考慮します。For example, for an equality join between two tables, we use the base tables histograms to estimate the join selectivity, and then factor in the predicates selectivity.

互換性レベル: COMPATIBILITY_LEVEL に次の Transact-SQLTransact-SQL コードを使用して、データベースが特定のレベルであることを確認します。Compatibility level: You can ensure your database is at a particular level by using the following Transact-SQLTransact-SQL code for COMPATIBILITY_LEVEL.

SELECT ServerProperty('ProductVersion');  
GO  
  
ALTER DATABASE <yourDatabase>  
SET COMPATIBILITY_LEVEL = 130;  
GO  
  
SELECT d.name, d.compatibility_level  
FROM sys.databases AS d  
WHERE d.name = 'yourDatabase';  
GO  

互換性レベルが 120 以上に設定されている SQL ServerSQL Server データベースの場合、トレース フラグ 9481 をアクティブにすると、システムは強制的に CE バージョン 70 を使用します。For a SQL ServerSQL Server database set at compatibility level 120 or above, activation of the trace flag 9481 forces the system to use the CE version 70.

レガシ CE: 互換性レベルが 120 以上に設定されている SQL ServerSQL Server データベースの場合、ALTER DATABASE SCOPED CONFIGURATION を使用して、データベース レベルで CE バージョン 70 をアクティブにすることができます。Legacy CE: For a SQL ServerSQL Server database set at compatibility level 120 and above, the CE version 70 can be can be activated by using the at the database level by using the ALTER DATABASE SCOPED CONFIGURATION.

ALTER DATABASE SCOPED CONFIGURATION 
SET LEGACY_CARDINALITY_ESTIMATION = ON;  
GO  
  
SELECT name, value  
FROM sys.database_scoped_configurations  
WHERE name = 'LEGACY_CARDINALITY_ESTIMATION';  
GO

SQL Server 2016 (13.x)SQL Server 2016 (13.x) SP1 以降の場合は、クエリ ヒント USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION') を使用します。Or starting with SQL Server 2016 (13.x)SQL Server 2016 (13.x) SP1, the Query Hint USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION').

SELECT CustomerId, OrderAddedDate  
FROM OrderTable  
WHERE OrderAddedDate >= '2016-05-01'
OPTION (USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION'));  

クエリ ストア: SQL Server 2016 (13.x)SQL Server 2016 (13.x) から導入されたクエリ ストアは、クエリのパフォーマンスを確認する場合に便利なツールです。Query store: Starting with SQL Server 2016 (13.x)SQL Server 2016 (13.x), the query store is a handy tool for examining the performance of your queries. クエリ ストアを有効にすると、Management StudioManagement Studioオブジェクト エクスプローラーで、データベース ノード以下にクエリ ストア ノードが表示されます。In Management StudioManagement Studio, in the Object Explorer under your database node, a Query Store node is displayed when the query store is enabled.

ALTER DATABASE <yourDatabase>  
SET QUERY_STORE = ON;  
GO  
  
SELECT q.actual_state_desc AS [actual_state_desc_of_QueryStore],  
        q.desired_state_desc,  
        q.query_capture_mode_desc  
FROM sys.database_query_store_options AS q;  
GO  
  
ALTER DATABASE <yourDatabase>  
SET QUERY_STORE CLEAR;  

ヒント

最新リリースの Management Studio をインストールし、頻繁に更新することをお勧めします。We recommend that you install the latest release of Management Studio and update it often.

カーディナリティ推定処理を追跡するための別のオプションは、query_optimizer_estimate_cardinality という名前の拡張イベントを使用することです。Another option for tracking the cardinality estimation process is to use the extended event named query_optimizer_estimate_cardinality. 次の Transact-SQLTransact-SQL コードを SQL ServerSQL Server で実行します。The following Transact-SQLTransact-SQL code sample runs on SQL ServerSQL Server. これは C:\Temp\ に .xel ファイルを書き込みます (ただし、パスを変更することができます)。It writes a .xel file to C:\Temp\ (although you can change the path). Management StudioManagement Studio で .xel ファイルを開くと、ユーザーにわかりやすい方法で詳細情報が表示されます。When you open the .xel file in Management StudioManagement Studio, its detailed information is displayed in a user friendly manner.

DROP EVENT SESSION Test_the_CE_qoec_1 ON SERVER;  
go  
  
CREATE EVENT SESSION Test_the_CE_qoec_1  
ON SERVER  
ADD EVENT sqlserver.query_optimizer_estimate_cardinality  
    (  
        ACTION (sqlserver.sql_text)  
            WHERE (  
                sql_text LIKE '%yourTable%'  
                and sql_text LIKE '%SUM(%'  
            )  
    )  
ADD TARGET package0.asynchronous_file_target   
        (SET  
            filename = 'c:\temp\xe_qoec_1.xel',  
            metadatafile = 'c:\temp\xe_qoec_1.xem'  
        );  
GO  
  
ALTER EVENT SESSION Test_the_CE_qoec_1  
ON SERVER  
STATE = START;  --STOP;  
GO  

SQL DatabaseSQL Database 向けに拡張されたイベントの詳細については、「SQL Database の拡張イベント」を参照してください。For information about extended events as tailored for SQL DatabaseSQL Database, see Extended events in SQL Database.

CE のバージョンを評価する手順Steps to assess the CE version

次に示す手順を使用して、最も重要なクエリの中に、最新の CE で適切に機能しないものがあるかどうかを評価できます。Next are steps you can use to assess whether any of your most important queries perform less well under the latest CE. 一部の手順は、前のセクションで説明されたコード サンプルを実行すると実行されます。Some of the steps are performed by running a code sample presented in a preceding section.

  1. Management StudioManagement Studioを開きます。Open Management StudioManagement Studio. SQL ServerSQL Server データベースが、利用できる最も高い互換性レベルに設定されていることを確認してください。Ensure your SQL ServerSQL Serverdatabase is set to the highest available compatibility level.

  2. 次の準備作業を実行します。Perform the following preliminary steps:

    1. Management StudioManagement Studioを開きます。Open Management StudioManagement Studio.

    2. T-SQL を実行して、SQL ServerSQL Server データベースが、利用できる最も高い互換性レベルに設定されていることを確認します。Run the T-SQL to ensure that your SQL ServerSQL Server database is set to the highest available compatibility level.

    3. データベースの LEGACY_CARDINALITY_ESTIMATION 構成が OFF になっていることを確認します。Ensure that your database has its LEGACY_CARDINALITY_ESTIMATION configuration turned OFF.

    4. クエリ ストアをクリアします。CLEAR your query store. もちろん、クエリ ストアが ON であることを確認します。Of course, ensure your query store is ON.

    5. SET NOCOUNT OFF; ステートメントを実行します。Run the statement: SET NOCOUNT OFF;

  3. SET STATISTICS XML ON; ステートメントを実行します。Run the statement: SET STATISTICS XML ON;

  4. 重要なクエリを実行します。Run your important query.

  5. [メッセージ] タブの結果ウィンドウで、影響を受けた行の実際の数を確認してください。In the results pane, on the Messages tab, note the actual number of rows affected.

  6. [結果] タブの結果ウィンドウで、XML 形式の統計情報を含むセルをダブルクリックします。In the results pane on the Results tab, double-click the cell that contains the statistics in XML format. グラフィックのクエリ プランが表示されます。A graphic query plan is displayed.

  7. グラフィックのクエリ プランで最初のボックスを右クリックし、 [プロパティ] をクリックします。Right-click the first box in the graphic query plan, and then click Properties.

  8. 別の構成と後で比較するために、次のプロパティの値を記録してください:For later comparison with a different configuration, note the values for the following properties:

    • CardinalityEstimationModelVersionCardinalityEstimationModelVersion.

    • 推定される行の数Estimated Number of Rows.

    • I/O の推定コストと、行数の予測ではなく、実際のパフォーマンスを含む 推定 プロパティ。Estimated I/O Cost, and several similar Estimated properties that involve actual performance rather than row count predictions.

    • 論理操作物理操作Logical Operation and Physical Operation. 並列処理 は有効な値です。Parallelism is a good value.

    • 実際の実行モードActual Execution Mode. バッチ は、 より適切で、有効な値です。Batch is a good value, better than Row.

  9. 行の推定数と行の実際の数とを比較します。Compare the estimated number of rows to the actual number of rows. CE は 1% (前後)、または 10% 程度、不正確ですか?Is the CE inaccurate by 1% (high or low), or by 10%?

  10. SET STATISTICS XML OFF; を実行します。Run: SET STATISTICS XML OFF;

  11. T-SQL を実行して、データベースの互換性レベルを 1 レベルずつ下げます (例: 130 から 120 に下げる)。Run the T-SQL to decrease the compatibility level of your database by one level (such as from 130 down to 120).

  12. すべての非準備ステップを再実行します。Rerun all the non-preliminary steps.

  13. 2 つの実行からの CE プロパティ値を比較します。Compare the CE property values from the two runs.

    • 最新の CE での不正確さの割合は、以前の CE での不正確さの割合より小さいですか?Is the inaccuracy percentage under the newest CE less than under the older CE?
  14. 最後に、2 つの実行からのさまざまなパフォーマンス プロパティ値を比較します。Finally, compare the various performance property values from the two runs.

    • クエリは 2 つの異なる CE 見積もりでの異なるプランを使用しましたか?Did your query use a different plan under the two differing CE estimations?

    • 最新の CE でのクエリ実行速度は低速でしたか?Did your query run slower under the latest CE?

    • 古い CE で別のプランを使用してクエリの動作が向上するのでない限り、恐らく最新の CE を使用したいと思われるでしょう。Unless your query runs better and with a different plan under the older CE, you almost certainly want the latest CE.

    • ただし、クエリが古い CE でより高速なプランで実行している場合は、システムで高速なプランを強制的に使用し、CE を無視することを検討してください。However, if your query runs with a faster plan under the older CE, consider forcing the system to use the faster plan and to ignore the CE. これが、1 つの例外で高速のプランを維持しながらも、すべてに対して最新の CE を保持できる方法です。This way you can have the latest CE on for everything, while keeping the faster plan in the one odd case.

最適なクエリ プランをアクティブにする方法How to activate the best query plan

CE 120 以降で効果の低いクエリ プランが、クエリで生成されるとします。Suppose that with CE 120 or above, a less efficient query plan is generated for your query. よりよいプランをアクティブにするいくつかのオプションを次に示します。Here are some options you have to activate the better plan:

  1. データベース全体に対して、互換性レベルを利用可能な最新の値より低い値に設定できます。You could set the compatibility level to a value lower than the latest available, for your whole database.

    • たとえば、互換性レベル 110 以下に設定すると CE 70 がアクティブ化しますが、すべてのクエリは以前の CE モデルの対象になります。For example, setting the compatibility level 110 or lower activates CE 70, but it makes all queries subject to the previous CE model.

    • さらに、低い互換性レベルに設定すると、最新バージョンのクエリ オプティマイザーの多数の機能強化も利用できません。Further, setting a lower compatibility level also misses a number of improvements in the query optimizer for latest versions.

  2. LEGACY_CARDINALITY_ESTIMATION データベース オプションを使用すると、クエリ オプティマイザーの他の機能強化を維持したまま、データベース全体が古い CE を使用するようにできます。You could use LEGACY_CARDINALITY_ESTIMATION database option, to have the whole database use the older CE, while retaining other improvements in the query optimizer.

  3. LEGACY_CARDINALITY_ESTIMATION クエリ ヒントを使用すると、クエリ オプティマイザーの他の機能強化を維持したまま、単一のクエリが古い CE を使用するようにできます。You could use LEGACY_CARDINALITY_ESTIMATION query hint, to have a single query use the older CE, while retaining other improvements in the query optimizer.

詳細に制御するために、システムがテスト中に CE 70 で生成されたプランを "強制的に" 使用するように指定できます。For the finest control, you could force the system to use the plan that was generated with CE 70 during your testing. 優先するプランを 固定 した後、データベース全体が最新の互換性レベルと CE を使用するように設定できます。After you pin your preferred plan, you can set your whole database to use the latest compatibility level and CE. このオプションについて、次に詳しく説明します。The option is elaborated next.

特定のクエリ プランを強制的に実行する方法How to force a particular query plan

クエリ ストアでは、特定のクエリ プランを使用するようシステムを強制するさまざまな方法を示します。The query store gives you different ways that you can force the system to use a particular query plan:

  • sp_query_store_force_planを実行します。Execute sp_query_store_force_plan.

  • Management StudioManagement Studio で、 [クエリ ストア] ノードを展開し、 [トップ リソース コンシューマー ノード] を右クリックして、 [トップ リソース コンシューマー ノードの表示] をクリックします。In Management StudioManagement Studio, expand your Query Store node, right-click Top Resource Consuming Nodes, and then click View Top Resource Consuming Nodes. [プランの強制][プランを強制しない] というラベルのボタンが表示されます。The display shows buttons labeled Force Plan and Unforce Plan.

クエリ ストアの詳細については、「 クエリのストアを使用した、パフォーマンスの監視」を参照してください。For more information about the query store, see Monitoring Performance By Using the Query Store.

CE の強化機能の例Examples of CE improvements

このセクションでは、最近のリリースで CE に実装された拡張機能からメリットを享受できるクエリの例について説明します。This section describes example queries that benefit from the enhancements implemented in the CE in recent releases. これは、ユーザー側で特定の操作が要求されていない背景情報です。This is background information that does not call for specific action on your part.

例 A。CE は、統計が最後に収集されたときよりも、最大値が高くなる可能性があることを理解していますExample A. CE understands maximum value might be higher than when statistics were last gathered

統計は 2016-04-30OrderTable について最後に収集され、最大 OrderAddedDate2016-04-30 であったものとします。Suppose statistics were last gathered for OrderTable on 2016-04-30, when the maximum OrderAddedDate was 2016-04-30. CE 120 (およびより高いレベル) は、"昇順" データを持つ OrderTable の列が、統計によって記録された最大値よりも大きい値を持つ可能性があることを理解しています。The CE 120 (and above version) understands that columns in OrderTable which have ascending data might have values larger than the maximum recorded by the statistics. これを理解すると、次のような Transact-SQLTransact-SQL SELECT ステートメントのクエリ プランの機能を改善できます。This understanding improves the query plan for Transact-SQLTransact-SQL SELECT statements such as the following.

SELECT CustomerId, OrderAddedDate  
FROM OrderTable  
WHERE OrderAddedDate >= '2016-05-01';  

例 B。CE は、同じテーブル上のフィルターにかけられた述語が頻繁に関連付けられることを理解していますExample B. CE understands that filtered predicates on the same table are often correlated

次の SELECT では、フィルターにかけられた述語が ModelModelVariant に表示されます。In the following SELECT we see filtered predicates on Model and ModelVariant. Model が "Xbox" である場合は、ModelVariant が "One" の可能性があることを直感的に理解できます (Xbox に One というバリアントがある場合)。We intuitively understand that when Model is 'Xbox' there is a chance the ModelVariant is 'One', given that Xbox has a variant called One.

CE 120 以降では、SQL ServerSQL Server は同じテーブルの 2 つの列、ModelModelVariant の間に相関関係がある可能性があることを理解します。Starting with CE 120, SQL ServerSQL Server understands there might be a correlation between the two columns on the same table, Model and ModelVariant. CE はクエリで返される行数のより正確な見積もりを行い、クエリ オプティマイザーがより最適なプランを生成します。The CE makes a more accurate estimation of how many rows will be returned by the query, and the query optimizer generates a more optimal plan.

SELECT Model, Purchase_Price  
FROM dbo.Hardware  
WHERE Model = 'Xbox' AND  
      ModelVariant = 'One';  

例 C。CE は異なるテーブルからフィルターにかけられた述語の間に、もはや相関関係がないと想定しますExample C. CE no longer assumes any correlation between filtered predicates from different tables

最近のワークロードと実際のビジネス データに関する最新の調査によって、異なるテーブルからの述語フィルターは、通常互いに関連していないことが明らかになりました。With extense new research on modern workloads and actual business data reveal that predicate filters from different tables usually do not correlate with each other. 次のクエリでは、CE は s.typer.date 間の相関関係がないと想定します。In the following query, the CE assumes there is no correlation between s.type and r.date. そのため CE は、返される行数の推定値を低く指定します。Therefore the CE makes a lower estimate of the number of rows returned.

SELECT s.ticket, s.customer, r.store  
FROM dbo.Sales    AS s  
CROSS JOIN dbo.Returns  AS r  
WHERE s.ticket = r.ticket AND  
      s.type = 'toy' AND  
      r.date = '2016-05-11';  

参照See Also

パフォーマンスの監視とチューニング Monitor and Tune for Performance
SQL Server 2014 のカーディナリティ推定機能によるクエリプランの最適化Optimizing Your Query Plans with the SQL Server 2014 Cardinality Estimator
クエリ ヒント Query Hints
USE HINT クエリ ヒント USE HINT Query Hints
クエリ調整アシスタントを使用したデータベースのアップグレード Upgrading Databases by using the Query Tuning Assistant
クエリのストアを使用した、パフォーマンスの監視 Monitoring Performance By Using the Query Store
クエリ処理アーキテクチャ ガイドQuery Processing Architecture Guide