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)`입니다. 앞의 두 가지는 재시작 없이 반영되지만, 서버 전체의 실행 계획이 바뀌는 영향 범위가 넓은 변경입니다.
この文書の適用条件
| 対象製品 | 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 |
| 実行影響 | 참조는 변경 없음. 설정 변경은 서버 전체 또는 데이터베이스 전체의 실행 계획 선택에 영향을 줍니다 |
| 再起動 | 불필요(이 두 설정은 `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 중심인지 분석 중심인지)에 따라 달라지므로 측정 없이 적용하지 마십시오. 이 두 설정은 `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 | 재시작 없이 반영되는지 | 이 두 설정 모두 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를 사용"하는 설정입니다. 코어 수가 많은 서버에서는 하나의 쿼리가 다수의 스레드를 점유하여 동시 실행 시 다른 처리를 압박할 수 있습니다.
03
서버 설정과 워크로드의 성격이 맞지 않음
OLTP 중심 처리와 분석 중심 처리는 적정 병렬 처리 수준이 다릅니다. 동일 인스턴스에 둘 다 함께 있는 경우 서버 전체의 단일 값으로는 최적화가 어렵습니다.
04
통계 정보가 오래되어 비용 추정이 실제와 차이남
추정 행 수가 과대하면 비용이 높게 추정되어 임계값을 넘어 병렬 플랜이 선택됩니다. 이 경우의 대응은 병렬 처리 수준 설정이 아니라 통계 정보 업데이트입니다.
確認手順
- 1
현재 값을 확인한다
参照のみ`sys.configurations`에서 두 설정의 `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는 오래된 기준이며, 실무에서는 상향하는 경우가 많은 설정입니다. 다만 "얼마가 맞는지"는 환경에 따라 다르므로 무조건 특정 값으로 변경해서는 안 됩니다.
- 이 두 설정은 서비스 재시작 없이 반영되지만, 반영과 동시에 서버 전체의 실행 계획 선택이 바뀝니다. 기존 플랜의 재컴파일로 일시적인 부하 상승이 발생할 수 있습니다.
- 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는 매우 오래된 시대의 기준으로, 현재 하드웨어에서는 병렬화의 효과가 적은 쿼리까지 병렬 플랜 대상이 되기 쉬워집니다. 실무에서는 상향하는 경우가 많은 설정이지만, 적정값은 환경마다 다르므로 쿼리의 추정 비용 분포를 측정한 후 결정하십시오.
변경에 서비스 재시작이 필요합니까?
필요하지 않습니다. 이 두 설정은 `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 지표를 정리한 문서입니다.
関連サービス
병렬 처리 수준 설정의 적정성을 진단하기
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
병렬 처리 수준 설정의 적정성을 진단하기