SQL ServerのMAXDOPとCost Threshold for Parallelismを確認・変更する方法
公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13
結論
現在値は `sys.configurations` を対象2件で絞れば参照専用で確認できます。変更はサーバー全体なら `sp_configure` と `RECONFIGURE`、データベース単位なら `ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP`(SQL Server 2016 以降)、単一クエリなら `OPTION (MAXDOP n)` です。この2つは再起動なしで反映されますが、サーバー全体の実行プランが変わる影響の広い変更です。
この文書の適用条件
| 対象製品 | SQL Server / Amazon RDS for SQL Server / Azure SQL Managed Instance |
|---|---|
| 確認バージョン | SQL Server 2008 以降(データベーススコープ構成の MAXDOP は SQL Server 2016 以降) |
| 適用環境 | オンプレミス、EC2、Amazon RDS、Azure |
| 必要権限 | 参照は VIEW SERVER STATE または VIEW ANY DEFINITION。`sp_configure` による変更は ALTER SETTINGS(実質 sysadmin / serveradmin)。データベーススコープ構成は ALTER ANY DATABASE SCOPED CONFIGURATION |
| 実行影響 | 参照は変更なし。設定変更はサーバー全体またはデータベース全体の実行プラン選択に影響します |
| 再起動 | 不要(この2つの設定は `RECONFIGURE` で即時反映されます) |
| 最終検証日 | 2026-08-13 |
そのまま実行できるコマンド
- 対象
- SQL Server 2008 以降 / Amazon RDS for SQL Server
- 権限
- VIEW SERVER STATE または VIEW ANY DEFINITION
- 変更作業
- なし(参照のみ)
- Production実行
- 可能
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: VIEW SERVER STATE または VIEW ANY DEFINITION
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
c.configuration_id,
c.name,
c.value AS configured_value, -- 構成された値
c.value_in_use AS running_value, -- 実際に使われている値
c.minimum,
c.maximum,
c.is_dynamic, -- 1: 再起動なしで反映される
c.is_advanced, -- 1: show advanced options が必要
c.description
FROM sys.configurations AS c
WHERE c.name IN ('max degree of parallelism', 'cost threshold for parallelism')
ORDER BY c.name;`sp_configure` と違って `show advanced options` を有効化する必要がないため、確認だけならこちらを使ってください。`configured_value` と `running_value` が食い違う場合、`RECONFIGURE` が実行されていません。
- 対象
- SQL Server 2008 以降 / Amazon RDS for SQL Server
- 権限
- VIEW SERVER STATE
- 変更作業
- なし(参照のみ)
- Production実行
- 可能
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: VIEW SERVER STATE
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
cpu_count AS logical_cpu_count,
hyperthread_ratio,
scheduler_count,
softnuma_configuration_desc -- SQL Server 2016 以降。それ以前の版では列を外すこと
FROM sys.dm_os_sys_info;
-- NUMA ノードごとのスケジューラ配置
SELECT
parent_node_id AS numa_node_id,
COUNT(*) AS scheduler_count
FROM sys.dm_os_schedulers
WHERE status = 'VISIBLE ONLINE'
GROUP BY parent_node_id
ORDER BY parent_node_id;MAXDOP の値を決めるには、まず論理CPU数とNUMAノードあたりのコア数を把握する必要があります。`softnuma_configuration_desc` は SQL Server 2016 以降の列です。
- 対象
- SQL Server 2008 以降
- 権限
- ALTER SETTINGS(sysadmin / serveradmin 相当)
- 変更作業
- あり(`show advanced options` 自体がサーバー構成の変更)
- Production実行
- 可能だが、確認だけなら `sys.configurations` を使うこと
-- 対象: SQL Server 2008 以降
-- 権限: ALTER SETTINGS(sysadmin / serveradmin 相当)
-- 変更作業: あり(show advanced options の切り替えはサーバー構成の変更)
-- Production 実行: 可能。ただし確認目的なら sys.configurations を推奨
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
EXEC sp_configure 'max degree of parallelism';
EXEC sp_configure 'cost threshold for parallelism';`show advanced options` を1にする操作自体がサーバー構成の変更です。参照だけが目的なら前掲の `sys.configurations` を使ってください。
- 対象
- SQL Server 2008 以降(Amazon RDS ではパラメータグループを使用)
- 権限
- ALTER SETTINGS(sysadmin / serveradmin 相当)
- 変更作業
- あり(サーバー全体の実行プラン選択が変わる)
- Production実行
- 実行可能だが、変更前後の測定と切り戻し手順を用意すること
-- 対象: SQL Server 2008 以降(Amazon RDS ではパラメータグループ経由)
-- 権限: ALTER SETTINGS(sysadmin / serveradmin 相当)
-- 変更作業: あり(サーバー全体の実行プラン選択に影響)
-- Production 実行: 可能。ただし変更前後の測定と切り戻し手順が前提
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
-- 下の値は「例示」であり推奨値ではない。必ず自環境の測定結果に置き換えること
DECLARE @maxdop int = 4;
DECLARE @cost_threshold int = 50;
EXEC sp_configure 'max degree of parallelism', @maxdop;
RECONFIGURE;
EXEC sp_configure 'cost threshold for parallelism', @cost_threshold;
RECONFIGURE;
GO
-- 反映結果の確認
SELECT name, value, value_in_use
FROM sys.configurations
WHERE name IN ('max degree of parallelism', 'cost threshold for parallelism');コード内の 4 と 50 は構文を示すための例示値であり、推奨値ではありません。適正値は論理CPU数、NUMA構成、ワークロードの性質(OLTP寄りか分析寄りか)によって変わるため、測定なしに適用しないでください。この2つの設定は `is_dynamic = 1` で、`RECONFIGURE` によりサービス再起動なしで反映されます。
- 対象
- SQL Server 2016 以降 / Azure SQL Database
- 権限
- ALTER ANY DATABASE SCOPED CONFIGURATION
- 変更作業
- あり(対象データベースの実行プラン選択が変わる)
- Production実行
- 実行可能だが、対象データベース全体に影響する
-- 対象: SQL Server 2016 以降 / Azure SQL Database
-- 権限: ALTER ANY DATABASE SCOPED CONFIGURATION
-- 変更作業: あり(対象データベース全体の実行プラン選択に影響)
-- Production 実行: 可能。対象DB全体に効くため影響範囲を確認すること
USE [SampleDB];
GO
-- 現在値の確認(参照のみ)
SELECT configuration_id, name, value, value_for_secondary
FROM sys.database_scoped_configurations
WHERE name = 'MAXDOP';
-- 変更(0 はサーバー設定に従う)
ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 4;データベーススコープの MAXDOP はサーバー設定より優先されます。複数の業務データベースが同居していて、片方だけ並列度を変えたい場合に有効です。`cost threshold for parallelism` にはデータベーススコープの設定がなく、サーバー全体の設定のみです。
- 対象
- SQL Server 2008 以降 / Amazon RDS for SQL Server
- 権限
- 対象オブジェクトへの参照権限
- 変更作業
- あり(そのクエリの実行プランのみ変わる)
- Production実行
- 可能。影響はそのクエリに限定される
-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: 対象オブジェクトへの参照権限
-- 変更作業: あり(このクエリの実行プランのみ変わる)
-- Production 実行: 可能(影響はこのクエリに限定)
SELECT col1, col2
FROM dbo.SampleTable
WHERE col1 > 0
OPTION (MAXDOP 1);問題が特定のクエリに限定されている場合、この方法が最も影響範囲を抑えられます。サーバー設定を変える前に、まずクエリ単位で効果があるかを確認してください。
結果の読み方
| 列 | 意味 | 確認するポイント |
|---|---|---|
| name | 構成オプション名 | `max degree of parallelism` / `cost threshold for parallelism` の2件が取得できているか |
| configured_value | 構成された値 | 意図した値が設定されているか |
| running_value | 実際に使用されている値 | `configured_value` と異なる場合、`RECONFIGURE` が未実行 |
| is_dynamic | 再起動なしで反映されるか | この2つの設定はいずれも 1(再起動不要) |
| is_advanced | `show advanced options` が必要か | 1 の場合、`sp_configure` からの変更には事前の有効化が必要 |
| logical_cpu_count | 論理CPU数 | MAXDOP の上限を判断する基準になる |
| numa_node_id / scheduler_count | NUMAノードごとのスケジューラ数 | ノードあたりのコア数を把握する。MAXDOP をノード内に収めるかの判断材料 |
| value_for_secondary | セカンダリレプリカ用の値 | 可用性グループ構成の場合、セカンダリ側の設定も確認する |
こういう状況で使います
- 待機統計で CXPACKET / CXCONSUMER が上位を占める
- 小さいクエリまで並列プランになり、CPU 使用率だけが上がる
- 同時実行数が増える時間帯に全体のスループットが落ちる
- 検証環境と本番環境で同じクエリの実行プランが違う
考えられる原因(可能性の高い順)
01
cost threshold for parallelism が既定値のまま
既定値の 5 は非常に古い時代のハードウェアを前提とした値です。現在の環境では、並列化の効果が小さいクエリまで並列プランの対象になりやすくなります。ただし「いくつにすべきか」は環境ごとに異なり、一律の正解はありません。実際のクエリコスト分布を測ってから決めてください。
02
MAXDOP が 0(無制限)のまま運用されている
0 は「利用可能なすべての論理CPUを使う」設定です。コア数の多いサーバーでは1本のクエリが多数のスレッドを占有し、同時実行時に他の処理を圧迫することがあります。
03
サーバー設定とワークロードの性質が合っていない
OLTP 中心の処理と分析中心の処理では適正な並列度が異なります。同一インスタンスに両方が同居している場合、サーバー全体の単一値では最適化しきれません。
04
統計情報が古く、コスト見積もりが実態とずれている
推定行数が過大だとコストが高く見積もられ、しきい値を超えて並列プランが選ばれます。この場合の対処は並列度設定ではなく統計情報の更新です。
確認手順
- 1
現在値を確認する
参照のみ`sys.configurations` で2つの設定の `value` と `value_in_use` を確認します。参照専用です。
- 2
ハードウェア構成を確認する
参照のみ論理CPU数とNUMAノードあたりのスケジューラ数を確認します。設定値を決める前提になります。
- 3
待機統計で並列待機の比重を測る
参照のみ対象時間帯の差分で CXPACKET / CXCONSUMER の比重を確認します。累計値だけでは判断できません。
- 4
実際に遅いクエリの実行プランを取得する
低並列演算子があるか、スレッド間の行数に偏りがあるかを確認します。
- 5
クエリ単位で効果を検証する
低`OPTION (MAXDOP n)` を付けて実行し、応答時間が改善するかを確認します。改善しなければサーバー設定を変えても効果はありません。
- 6
統計情報の鮮度を確認する
参照のみコスト見積もりのずれが原因でないことを確認してから、設定変更に進みます。
対応方法
すぐに実施できる低リスクの対応
クエリヒントで対象を限定して検証する
低`OPTION (MAXDOP n)` で問題のクエリだけを制御します。影響範囲が限定され、切り戻しも容易です。
統計情報の鮮度を確認・更新する
中推定行数の乖離が原因の場合、設定変更ではなく統計更新が正しい対処です。
事前検討が必要な変更
cost threshold for parallelism を見直す
中並列プランになっているクエリの推定コスト分布を測り、並列化の恩恵が無いクエリを除外できる水準を検討します。値は測定結果から決め、変更後に応答時間を再測定します。
MAXDOP を見直す
中論理CPU数とNUMA構成を踏まえて上限を設定します。段階的に適用し、各段階で主要クエリの応答時間を比較してください。
データベース単位の設定に切り替える
中性質の異なる業務が同一インスタンスに同居している場合、`ALTER DATABASE SCOPED CONFIGURATION`(SQL Server 2016 以降)でデータベースごとに分けられます。
Amazon RDS ではパラメータグループを更新する
中サーバー全体の設定はDBパラメータグループで管理します。パラメータの適用タイプにより、反映タイミングが即時か再起動後かが変わります。
再起動・サービス影響を伴う変更
リソースガバナーでワークロード別に制御する
専門家レビュー必須ワークロードグループ単位で並列度を制御できますが、分類関数の設計を誤ると特定処理が極端に遅くなります。エディション制約もあり、設計レビューが前提です。
インスタンス分離を検討する
専門家レビュー必須OLTP と分析ワークロードを別インスタンスに分ける方式です。設定の最適化としては最も確実ですが、構成変更と移行作業を伴います。
!注意事項
- コード例に含まれる `4` や `50` は構文を示すための例示値です。推奨値ではありません。適正値は論理CPU数、NUMA構成、ワークロードの性質によって変わるため、必ず自環境で測定してから決めてください。
- `cost threshold for parallelism` の既定値 5 は古い基準であり、実務では引き上げられることが多い設定です。ただし「いくつが正しいか」は環境依存であり、無条件に特定の値へ変更してよいものではありません。
- この2つの設定はサービス再起動なしで反映されますが、反映と同時にサーバー全体の実行プラン選択が変わります。既存プランの再コンパイルにより一時的な負荷上昇が起きることがあります。
- Amazon RDS for SQL Server では、サーバー全体の構成はDBパラメータグループで管理します。`sp_configure` による変更は権限上実行できない場合があるため、対象パラメータが変更可能かを事前に確認してください。
- データベーススコープの MAXDOP はサーバー設定より優先されます。サーバー設定を変えても効かない場合は、データベース側の設定を確認してください。
- `RECONFIGURE` を実行しないと `value_in_use` は変わりません。設定後は必ず反映結果を確認してください。
バージョン・環境による違い
これで解決しない場合に確認すること
並列プランになっているクエリのコスト分布
プランキャッシュから推定コストを集計し、しきい値付近にどれだけのクエリが分布しているかを確認します。
実行プランのスレッド別行数
並列スレッド間で行数が偏っていないかを確認します。偏りがある場合、並列度を上げても効果は限定的です。
メモリ許可の状況
並列クエリはメモリ許可を多く要求します。`RESOURCE_SEMAPHORE` 待機が併発していないかを確認します。
可用性グループのセカンダリ設定
データベーススコープ構成の `value_for_secondary` がプライマリと異なっていないかを確認します。
この文書の根拠と限界
製品の公式ドキュメントに基づく説明
SQL Server の `sp_configure`(`max degree of parallelism` / `cost threshold for parallelism`)、`sys.configurations`、`ALTER DATABASE SCOPED CONFIGURATION`、`sys.database_scoped_configurations`、クエリヒント `MAXDOP` の公開仕様に基づきます。設定値の推奨は環境依存であるため、具体的な数値は例示にとどめ、判断基準のみを記載しています。Amazon RDS でのパラメータ変更可否・反映タイミングは対象環境で確認してください。
よくある質問
MAXDOPはいくつに設定すべきですか?
一律の正解はありません。論理CPU数、NUMAノードあたりのコア数、そしてOLTP寄りか分析寄りかというワークロードの性質によって適正値が変わります。まず現在値とハードウェア構成を確認し、`OPTION (MAXDOP n)` でクエリ単位に効果を測ってから、サーバー設定の変更を検討してください。
cost threshold for parallelism の既定値5のままで問題ありますか?
既定値の 5 は非常に古い時代の基準で、現在のハードウェアでは並列化の効果が小さいクエリまで並列プランの対象になりやすくなります。実務では引き上げられることが多い設定ですが、適正値は環境ごとに異なるため、クエリの推定コスト分布を測ってから決めてください。
変更にサービス再起動は必要ですか?
不要です。この2つの設定は `is_dynamic = 1` で、`RECONFIGURE` により即時反映されます。ただし反映と同時にサーバー全体の実行プラン選択が変わるため、再コンパイルによる一時的な負荷上昇が起きることがあります。
AWS RDSでも使用できますか?
確認用の `sys.configurations` はそのまま使用できます。サーバー全体の設定変更はDBパラメータグループで行うため、`sp_configure` を前提とした手順はそのままでは適用できません。対象パラメータが変更可能か、反映タイミングはどうかを事前に確認してください。
どの権限が必要ですか?
参照には VIEW SERVER STATE または VIEW ANY DEFINITION が必要です。`sp_configure` による変更には ALTER SETTINGS(実質 sysadmin / serveradmin)、データベーススコープ構成の変更には ALTER ANY DATABASE SCOPED CONFIGURATION が必要です。
結果をどう判断しますか?
`value` と `value_in_use` が一致していることをまず確認します。そのうえで、対象時間帯の待機統計と主要クエリの応答時間を変更前後で比較し、改善が測定できた場合にのみ設定を維持してください。
この文書がカバーする質問
- MAXDOPの現在値を確認したい
- 並列度をデータベース単位で変えたい
- RDSでMAXDOPを変更する方法が知りたい
リスク表示の意味
- 参照のみデータと設定を変更しません。
- 低影響は限定的ですが、権限と負荷の確認が必要です。
- 中性能・ロック・コストに影響する可能性があります。
- 高障害・データ損失・復旧作業が発生する可能性があります。
- 専門家レビュー必須本番適用前に別途レビューが必須です。
GIIPの対応範囲
並列度の設定は「一度決めて終わり」ではありません。データ量が増え、クエリが追加され、インスタンスサイズが変われば適正値も動きます。GIIP では設定値そのものと、その設定下での待機事象・応答時間を同じ時系列で保持し、変更の前後で何が変わったかを追える形にしています。設定変更のような影響範囲の広い操作はAIエージェントに自動実行させず、測定と提案までを自動化し、適用の判断と承認は人間が行う運用としています。
執筆・技術検証
GIIP プロダクション運用チーム
大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。
SQL ServerでCXPACKET待機が多いときの原因と確認方法
sys.dm_os_wait_stats と sys.dm_os_waiting_tasks で CXPACKET を評価し、CXCONSUMER との区別を踏まえて並列度の見直しに進むための手順です。
sql-serverSQL Serverでテーブルごとの統計情報更新日時を確認するSQL
sys.stats と STATS_DATE で、テーブル・統計ごとの最終更新日時と更新後の変更行数を一覧化する参照専用SQLです。
sql-serverSQL Serverで長時間開いたままのトランザクションを確認するSQL
sys.dm_tran_active_transactions 系のDMVで、開始時刻・セッション・最後に実行したSQLまで含めて放置トランザクションを特定する手順です。
awsAWS RDSで大きいインスタンス1台と小さいインスタンス複数台に分ける場合の違い
RDSのサイジングで「大きい1台」と「小さい複数台」を比べるときの技術的な差分と、決める前に測るべきCloudWatch指標を整理した文書です。
関連サービス
並列度設定の妥当性を診断する
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
並列度設定の妥当性を診断する