giip
SES 안건 등록
Aurora MySQL性能インデックスパラメータログファイルAurora

Aurora MySQL에서 특정 쿼리가 느려졌을 때 확인하는 절차

公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13

結論

Aurora MySQL에서 특정 쿼리가 느릴 때는 (1) 슬로우 쿼리 로그(`slow_query_log`와 `long_query_time`)로 느린 SQL을 특정하고, (2) `SHOW FULL PROCESSLIST`로 실행 중인 세션과 대기 상태를 확인하고, (3) `EXPLAIN`으로 실행 계획을 확인하는 순서로 원인을 파악합니다. `performance_schema`가 활성화되어 있으면 다이제스트 집계와 Performance Insights로 대기 이벤트까지 추적할 수 있지만, 비활성화된 경우에도 이 세 가지와 CloudWatch 메트릭으로 대부분의 원인을 파악할 수 있습니다.

この文書の適用条件

対象製品Aurora MySQL(MySQL 호환 에디션)
確認バージョンAurora MySQL 2.x(MySQL 5.7 호환) / 3.x(MySQL 8.0 호환). `EXPLAIN ANALYZE`는 MySQL 8.0에서 추가되었으므로 3.x에서만 사용 가능
適用環境Amazon Aurora(AWS)
必要権限조회 작업은 대상 스키마에 대한 `SELECT` 권한. 다른 사용자의 세션이나 트랜잭션을 보려면 `PROCESS` 권한. 파라미터 변경에는 IAM의 `rds:ModifyDBParameterGroup`과 마스터 사용자 수준의 권한 필요
実行影響조회 작업은 영향 없음. `EXPLAIN ANALYZE`는 대상 쿼리를 실제로 실행함. 파라미터 변경은 설정 변경에 해당함
再起動조회 작업은 불필요. `performance_schema` 활성화는 인스턴스 재시작 필요
最終検証日2026-08-13

そのまま実行できるコマンド

슬로우 쿼리 로그와 performance_schema 현재 값 확인하기参照のみ
対象
Aurora MySQL 2.x / 3.x
権限
접속 권한(전역 변수 조회)
変更作業
없음(조회만)
Production実行
가능
-- 対象: Aurora MySQL 2.x / 3.x
-- 権限: 接続権限(グローバル変数の参照のみ)
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SHOW GLOBAL VARIABLES WHERE Variable_name IN (
    'slow_query_log',
    'long_query_time',
    'log_output',
    'log_queries_not_using_indexes',
    'min_examined_row_limit',
    'performance_schema'
);

`performance_schema`가 `OFF`인 경우 이 문서의 다이제스트 집계는 사용할 수 없습니다. 이 경우에는 슬로우 쿼리 로그와 PROCESSLIST, `information_schema.INNODB_TRX`, CloudWatch 메트릭으로 원인을 파악합니다.

현재 실행 중인 세션 확인하기参照のみ
対象
Aurora MySQL 2.x / 3.x
権限
자신 외의 세션을 보려면 `PROCESS` 권한 필요
変更作業
없음(조회만)
Production実行
가능
-- 対象: Aurora MySQL 2.x / 3.x
-- 権限: 自分以外のセッションを見るには PROCESS 権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
    ID,
    USER,
    HOST,
    DB,
    COMMAND,
    TIME                    AS elapsed_sec,
    STATE,
    LEFT(INFO, 200)         AS query_head
FROM information_schema.PROCESSLIST
WHERE COMMAND <> 'Sleep'
ORDER BY TIME DESC;

`SHOW FULL PROCESSLIST`와 동일한 정보를 정렬·필터링할 수 있는 형태입니다. MySQL 8.0 호환(Aurora MySQL 3.x)에서는 `performance_schema.processlist`도 사용할 수 있으며, 이는 전역 뮤텍스를 사용하지 않는 구현이라 연결 수가 많은 환경에서 영향이 더 적습니다.

오래 열려 있는 트랜잭션 확인하기(performance_schema가 비활성화되어도 사용 가능)参照のみ
対象
Aurora MySQL 2.x / 3.x
権限
`PROCESS` 권한
変更作業
없음(조회만)
Production実行
가능
-- 対象: Aurora MySQL 2.x / 3.x
-- 権限: PROCESS 権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
    trx_id,
    trx_state,
    trx_started,
    TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS open_sec,
    trx_mysql_thread_id,
    trx_rows_locked,
    trx_rows_modified,
    LEFT(trx_query, 200)                      AS current_query
FROM information_schema.INNODB_TRX
ORDER BY trx_started ASC;

느린 원인이 특정 쿼리가 아니라 락 대기라면, 여기에서 오랫동안 `RUNNING` 상태로 남아 있는 트랜잭션이 보입니다. `performance_schema`의 활성화 여부와 관계없이 조회할 수 있습니다.

실행된 SQL을 다이제스트 단위로 집계하기(performance_schema가 ON인 경우)参照のみ
対象
Aurora MySQL 2.x / 3.x(`performance_schema = ON`이 전제)
権限
`performance_schema`에 대한 `SELECT` 권한
変更作業
없음(조회만)
Production実行
가능
-- 対象: Aurora MySQL 2.x / 3.x(performance_schema = ON が前提)
-- 権限: performance_schema への SELECT
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
    SCHEMA_NAME,
    LEFT(DIGEST_TEXT, 200)                          AS digest_head,
    COUNT_STAR                                      AS exec_count,
    ROUND(SUM_TIMER_WAIT / 1000000000000, 3)        AS total_sec,
    ROUND(AVG_TIMER_WAIT / 1000000000000, 6)        AS avg_sec,
    SUM_ROWS_EXAMINED                               AS rows_examined,
    SUM_ROWS_SENT                                   AS rows_sent,
    SUM_NO_INDEX_USED                               AS no_index_used,
    SUM_CREATED_TMP_DISK_TABLES                     AS tmp_disk_tables,
    FIRST_SEEN,
    LAST_SEEN
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 20;

`*_TIMER_WAIT`의 단위는 피코초(picosecond)이므로 10^12로 나누어 초 단위로 변환했습니다. 집계값은 인스턴스 기동 이후의 누적값이며, 재시작이나 장애 조치(failover) 시 초기화됩니다.

실행 계획 확인하기(EXPLAIN / EXPLAIN ANALYZE)
対象
`EXPLAIN`은 2.x / 3.x, `EXPLAIN ANALYZE`는 3.x(MySQL 8.0 호환)에서만 사용 가능
権限
대상 테이블에 대한 `SELECT` 권한
変更作業
없음. 단, `EXPLAIN ANALYZE`는 대상 쿼리를 실제로 실행함
Production実行
`EXPLAIN`은 가능. `EXPLAIN ANALYZE`는 실행 부하를 감당할 수 있는 경우에만
-- 対象: EXPLAIN は Aurora MySQL 2.x / 3.x、EXPLAIN ANALYZE は 3.x(MySQL 8.0互換)のみ
-- 権限: 対象テーブルへの SELECT
-- 変更作業: なし(EXPLAIN ANALYZE はクエリを実際に実行する点に注意)
-- Production 実行: EXPLAIN は可能/EXPLAIN ANALYZE は実行負荷を許容できる場合のみ

-- 1) 実行計画だけを見る(クエリは実行されない)
EXPLAIN
SELECT id, name, updated_at
FROM SampleDB.sample_table
WHERE status = 'active'
  AND updated_at >= '2026-08-01'
ORDER BY updated_at DESC
LIMIT 100;

-- 2) 実測値つきの実行計画(Aurora MySQL 3.x のみ。クエリを実際に実行する)
EXPLAIN ANALYZE
SELECT id, name, updated_at
FROM SampleDB.sample_table
WHERE status = 'active'
  AND updated_at >= '2026-08-01'
ORDER BY updated_at DESC
LIMIT 100;

`EXPLAIN ANALYZE`는 예상 행 수가 아니라 실측 행 수와 실측 시간을 반환하므로 예측과의 차이를 직접 확인할 수 있습니다. 다만 쿼리를 실제로 실행하므로 갱신계 쿼리나 무거운 집계에는 사용하지 마십시오. `EXPLAIN FORMAT=JSON`은 비용(cost) 값까지 포함한 상세 정보를 반환하며, 이쪽은 실행을 수반하지 않습니다.

슬로우 쿼리 로그를 활성화하여 CloudWatch Logs로 출력하기
対象
Aurora MySQL 2.x / 3.x(DB 파라미터 그룹 및 DB 클러스터 설정)
権限
IAM: `rds:ModifyDBParameterGroup`, `rds:ModifyDBCluster`
変更作業
있음(파라미터 변경 및 로그 출력 설정 변경)
Production実行
사전에 변경 관리 절차를 거친 후 실시. 로그량 증가를 감안할 것
# 対象: Aurora MySQL 2.x / 3.x(DBパラメータグループとDBクラスター設定)
# 権限: IAM rds:ModifyDBParameterGroup, rds:ModifyDBCluster
# 変更作業: あり(パラメータ変更 + ログ出力先の変更)
# Production 実行: 変更管理を通したうえで実施。ログ量とストレージ増加を見込むこと

# 1) スロークエリログを有効化する(いずれも動的パラメータとして扱われる想定。
#    実際の反映方法は describe-db-parameters の ApplyType で確認すること)
aws rds modify-db-parameter-group \
  --db-parameter-group-name example-aurora-mysql-params \
  --parameters '[
    {"ParameterName":"slow_query_log","ParameterValue":"1","ApplyMethod":"immediate"},
    {"ParameterName":"long_query_time","ParameterValue":"1","ApplyMethod":"immediate"},
    {"ParameterName":"log_output","ParameterValue":"FILE","ApplyMethod":"immediate"}
  ]'

# 2) クラスター単位でスロークエリログをCloudWatch Logsへ出力する
aws rds modify-db-cluster \
  --db-cluster-identifier example-aurora-cluster \
  --cloudwatch-logs-export-configuration '{"EnableLogTypes":["slowquery","error"]}' \
  --apply-immediately

# 3) 反映後の値を確認する
aws rds describe-db-parameters \
  --db-parameter-group-name example-aurora-mysql-params \
  --query "Parameters[?ParameterName=='slow_query_log' || ParameterName=='long_query_time'].{Name:ParameterName,Value:ParameterValue,Apply:ApplyType,Status:ApplyMethod}" \
  --output table

`long_query_time`을 작게 설정할수록 기록되는 쿼리가 늘어나 로그량과 CloudWatch Logs 비용이 증가합니다. 먼저 1초 정도부터 시작해 필요에 따라 낮추십시오. `log_output`을 `TABLE`로 설정하면 `mysql.slow_log` 테이블에서 SQL로 조회할 수 있지만, 기록 방식이 테이블 삽입으로 바뀌므로 부하의 성격이 달라집니다.

performance_schema 활성화하기(인스턴스 재시작 필요)
対象
Aurora MySQL 2.x / 3.x(DB 파라미터 그룹)
権限
IAM: `rds:ModifyDBParameterGroup`, `rds:RebootDBInstance`
変更作業
있음(정적 파라미터 변경 + 인스턴스 재시작)
Production実行
재시작이 수반되므로 불가. 유지보수 시간대에 계획적으로 실행
# 対象: Aurora MySQL 2.x / 3.x(DBパラメータグループ)
# 権限: IAM rds:ModifyDBParameterGroup, rds:RebootDBInstance
# 変更作業: あり(静的パラメータ変更 + インスタンス再起動)
# Production 実行: 不可(再起動を伴うためメンテナンス時間帯に計画実行)

# 1) performance_schema を有効化する(再起動時に反映)
aws rds modify-db-parameter-group \
  --db-parameter-group-name example-aurora-mysql-params \
  --parameters '[
    {"ParameterName":"performance_schema","ParameterValue":"1","ApplyMethod":"pending-reboot"}
  ]'

# 2) 反映のためインスタンスを再起動する(接続断が発生する)
aws rds reboot-db-instance --db-instance-identifier example-aurora-instance

`performance_schema`는 재시작이 필요한 파라미터입니다. 재시작은 연결 끊김과 장애 조치(failover)에 준하는 영향을 수반하므로 반드시 계획된 정지로 처리하십시오. Performance Insights의 일부 상세 정보도 `performance_schema`에 의존합니다. 활성화로 인한 메모리 사용량 증가분은 환경마다 다르므로 사전에 검증 환경에서 측정하십시오.

結果の読み方

意味確認するポイント
SCHEMA_NAME다이제스트가 속한 스키마대상 애플리케이션의 스키마로 좁혀서 확인
digest_head리터럴을 정규화한 SQL 문의 앞부분같은 형태의 SQL이 하나로 묶여 있음. 전문은 `DIGEST_TEXT`를 직접 참조
exec_count실행 횟수(`COUNT_STAR`)1회가 느린 것인지, 횟수가 많아 합계가 커진 것인지 구분
total_sec누적 실행 시간(초)상위 순서가 부하의 주요 원인. 먼저 이 항목을 확인
avg_sec1회당 평균 실행 시간(초)합계는 작지만 평균이 큰 쿼리는 실행 시점에 따라 문제가 될 수 있음
rows_examined스캔한 행 수의 누계`rows_sent`에 비해 현저히 크면 인덱스가 효과를 내지 못하고 있을 가능성이 높음
rows_sent반환한 행 수의 누계`rows_examined`와의 비율이 효율성의 기준
no_index_used인덱스를 사용하지 않은 실행 횟수0이 아니면 `EXPLAIN`으로 접근 방식을 확인
tmp_disk_tables디스크상에 임시 테이블을 생성한 횟수값이 크면 정렬·그룹화 로직 재검토 대상
FIRST_SEEN / LAST_SEEN최초·최종 관측 시각느려진 시점과 일치하는지 확인

こういう状況で使います

  • 어제까지 문제 없던 동일한 쿼리가 특정 시점부터 갑자기 느려졌다
  • 애플리케이션 쪽에서 타임아웃이 증가했지만 CPU 사용률은 높지 않다
  • 특정 화면·배치만 느리고 다른 처리는 정상
  • Performance Insights를 확인하려 했지만 `performance_schema`가 비활성화되어 있어 상세 정보가 나오지 않는다
  • `SHOW PROCESSLIST`에 동일한 쿼리가 오랫동안 남아 있다

考えられる原因(可能性の高い順)

  1. 01

    실행 계획이 바뀌어 인덱스가 사용되지 않게 됨

    데이터량 증가나 통계 갱신으로 인해 옵티마이저가 다른 접근 방식을 선택하는 경우가 있습니다. `rows_examined`가 `rows_sent`에 비해 극단적으로 커졌다면 이 가능성이 높습니다.

  2. 02

    락 대기로 실행이 진행되지 않음

    쿼리 자체는 가볍더라도 다른 트랜잭션이 행 락을 보유하고 있으면 대기하게 됩니다. `information_schema.INNODB_TRX`에 오래 열려 있는 트랜잭션이 남아 있지 않은지 확인합니다.

  3. 03

    데이터량이 증가해 스캔 비용이 상승함

    같은 실행 계획이라도 대상 행이 늘어나면 소요 시간이 늘어납니다. 이 경우에는 인덱스 설계나 검색 조건의 재검토가 필요하며, 파라미터 조정으로는 해결되지 않습니다.

  4. 04

    정렬·임시 테이블이 디스크로 내려가고 있음

    `ORDER BY`나 `GROUP BY`의 대상이 크면 임시 테이블이 디스크 위에 생성됩니다. 다이제스트 집계의 `SUM_CREATED_TMP_DISK_TABLES`로 확인할 수 있습니다.

  5. 05

    리더 인스턴스 쪽의 레플리카 지연이나 리소스 경쟁

    읽기를 리더 엔드포인트로 보내는 경우, 라이터와 리더의 부하 상황이 다릅니다. 먼저 어느 인스턴스에서 느린지 구분하십시오.

確認手順

  1. 1

    어느 인스턴스, 어느 시간대인지 특정하기

    参照のみ

    CloudWatch의 `CPUUtilization`, `DatabaseConnections`, `ReadLatency` / `WriteLatency`, `Deadlocks`를 확인해 사건 발생 시간대와 인스턴스를 좁힙니다.

  2. 2

    슬로우 쿼리 로그 설정값 확인하기

    参照のみ

    위의 `SHOW GLOBAL VARIABLES`를 실행해 로그가 애초에 수집되고 있는지, `long_query_time`이 실제 상황에 맞는지 확인합니다.

  3. 3

    실행 중인 세션 확인하기

    参照のみ

    `information_schema.PROCESSLIST`로 느린 쿼리가 실행 중인지 대기 중인지 확인합니다. `STATE` 열이 단서가 됩니다.

  4. 4

    장시간 트랜잭션과 락 확인하기

    参照のみ

    `information_schema.INNODB_TRX`를 참조합니다. `performance_schema`가 비활성화되어 있어도 실행할 수 있습니다.

  5. 5

    다이제스트 집계로 상위 항목 추출하기

    参照のみ

    `performance_schema`가 활성화되어 있으면 `events_statements_summary_by_digest`를 누적 실행 시간 내림차순으로 확인합니다.

  6. 6

    대상 SQL의 실행 계획 확인하기

    `EXPLAIN`으로 접근 방식, 사용 인덱스, 예상 행 수를 확인합니다. 예상과 실측의 차이를 보고 싶을 때만, 부하를 감당할 수 있는 범위에서 `EXPLAIN ANALYZE`(Aurora MySQL 3.x)를 사용합니다.

対応方法

すぐに実施できる低リスクの対応

  • 슬로우 쿼리 로그를 활성화해 대상 SQL 확정하기

    추측으로 대책을 세우기 전에 실제로 느린 SQL을 로그로 확정합니다. `long_query_time`은 먼저 1초 정도로 시작합니다.

  • 락을 보유한 세션을 애플리케이션 측에서 종료하기

    오래 열려 있는 트랜잭션이 원인이라면 먼저 애플리케이션 측 처리를 중단합니다. DB 측 `KILL`은 최후의 수단으로, 실행 중인 업데이트가 롤백됩니다.

事前検討が必要な変更

  • 검색 조건에 맞는 인덱스 추가하기

    `EXPLAIN` 결과를 바탕으로 필터링과 정렬을 모두 만족하는 복합 인덱스를 검토합니다. 추가는 스키마 변경에 해당하므로 검증 환경에서의 확인과 실행 시간대 조정이 필요합니다.

  • 쿼리를 재작성해 스캔 행 수 줄이기

    조건 열에 함수를 적용하지 않기, 필요한 열만 반환하기, 페이징 방식 재검토 등의 변경으로 `rows_examined`를 줄입니다.

  • 슬로우 쿼리 로그를 CloudWatch Logs로 출력해 지속적으로 확인하기

    일시적으로 보는 것이 아니라 로그를 집약해 추이를 추적할 수 있는 상태로 만듭니다. 로그량에 따른 비용이 발생합니다.

再起動・サービス影響を伴う変更

  • performance_schema 활성화하기

    재시작이 필요한 정적 파라미터입니다. 연결 끊김을 수반하므로 계획된 정지로 처리하십시오. 활성화 후에는 다이제스트 집계와 Performance Insights의 상세 정보를 사용할 수 있게 됩니다.

  • 인스턴스 클래스 변경하기

    CPU나 메모리가 상시적으로 부족한 경우의 선택지이지만, 단일 쿼리의 실행 계획 문제는 해결하지 못합니다. 먼저 원인 파악을 끝낸 뒤 판단하십시오.

!注意事項

  • `EXPLAIN ANALYZE`는 대상 쿼리를 실제로 실행합니다. 갱신계 쿼리나 무거운 집계에는 사용하지 마십시오.
  • `performance_schema` 활성화는 인스턴스 재시작을 수반합니다. 연결 끊김이 발생하므로 무중단으로는 실시할 수 없습니다.
  • `long_query_time`을 극단적으로 작게 설정하면 로그 출력 자체가 부하와 스토리지 소비의 원인이 됩니다.
  • `KILL`은 실행 중인 트랜잭션의 롤백을 발생시키며, 롤백에는 원래 처리와 같거나 더 긴 시간이 걸릴 수 있습니다. 함부로 사용하지 마십시오.
  • 다이제스트 집계는 인스턴스 기동 이후의 누적값입니다. 장애 조치(failover)나 재시작 직후에는 모수가 작아 판단 근거가 되지 않습니다.
  • 이 문서는 원인 파악 절차를 설명한 것이며, 특정 설정값을 적용하면 빨라진다는 것을 보장하지 않습니다.

バージョン・環境による違い

Aurora MySQL 2.x(MySQL 5.7 호환)`EXPLAIN ANALYZE`는 사용할 수 없습니다. 실행 계획의 상세를 보려면 `EXPLAIN FORMAT=JSON`을 사용합니다.
Aurora MySQL 3.x(MySQL 8.0 호환)`EXPLAIN ANALYZE`와 `performance_schema.processlist`를 사용할 수 있습니다. `information_schema.PROCESSLIST`는 MySQL 8.0 계열 일부 버전에서 비권장(deprecated)으로 취급되므로, 장기적으로는 `performance_schema.processlist`로의 전환을 검토하십시오.
Performance Insights활성화는 인스턴스 단위 설정입니다. 보존 기간과 대상 인스턴스 클래스 조건은 AWS의 요금·사양 페이지에서 최신 내용을 확인하십시오(본 문서에서는 단정하지 않습니다).

これで解決しない場合に確認すること

  • 애플리케이션 측 타임아웃과 커넥션 풀 설정 확인하기

    DB 측 실행 시간이 변하지 않았는데도 느려 보이는 경우, 연결 대기나 풀 고갈이 원인인 경우가 있습니다.

  • 라이터와 리더 중 어느 쪽에서 느린지 분리하기

    같은 SQL을 라이터와 리더 각각에서 실행해 차이가 있는지 확인합니다. 차이가 있다면 개별 인스턴스의 부하 요인을 의심합니다.

  • CloudWatch의 `ReadIOPS` / `WriteIOPS`와 버퍼 풀 히트 상황 확인하기

    스토리지 측에서 대기 중인지, CPU에서 대기 중인지에 따라 대응 방법이 달라집니다.

  • 스키마 변경이나 배포 이력과 시각을 대조하기

    느려진 시각 전후로 인덱스 삭제나 애플리케이션의 쿼리 변경이 없었는지 확인합니다.

  • 동일한 증상이 여러 쿼리에서 나타나지 않는지 확인하기

    단일 쿼리의 문제인지, 인스턴스 전체의 문제인지에 따라 조사 방향이 달라집니다.

この文書の根拠と限界

製品の公式ドキュメントに基づく説明

MySQL의 슬로우 쿼리 로그 관련 시스템 변수, `information_schema.PROCESSLIST` / `INNODB_TRX`, `performance_schema.events_statements_summary_by_digest`, `EXPLAIN` / `EXPLAIN ANALYZE`의 공개 사양, 그리고 Amazon RDS / Aurora의 파라미터 그룹 및 로그 출력 공개 사양에 기반한 일반적인 확인 절차입니다. 특정 환경의 실측값은 포함하지 않습니다.

よくある質問

Production에서 실행할 수 있습니까?

`SHOW GLOBAL VARIABLES`, `information_schema.PROCESSLIST`, `information_schema.INNODB_TRX`, 다이제스트 집계, `EXPLAIN`은 모두 조회 전용이므로 운영 환경에서 그대로 실행할 수 있습니다. `EXPLAIN ANALYZE`는 쿼리를 실제로 실행하고, 파라미터 변경은 설정 변경에 해당하므로 각각 영향을 확인한 뒤 실시하십시오.

performance_schema가 비활성화되어 있어도 원인을 조사할 수 있습니까?

조사할 수 있습니다. 슬로우 쿼리 로그로 느린 SQL을 특정하고, `SHOW FULL PROCESSLIST`와 `information_schema.INNODB_TRX`로 실행 상태와 락을 확인하고, `EXPLAIN`으로 실행 계획을 보는 흐름으로 대부분 파악할 수 있습니다. 활성화에는 재시작이 필요하므로, 먼저 비활성화 상태에서 할 수 있는 범위를 모두 시도해 보십시오.

performance_schema를 활성화하려면 재시작이 필요합니까?

필요합니다. DB 파라미터 그룹에서 `performance_schema`를 1로 변경하고 대상 인스턴스를 재시작해 적용합니다. 재시작은 연결 끊김을 수반하므로 계획된 정지로 처리하십시오.

어떤 권한이 필요합니까?

자신의 세션과 대상 테이블의 `EXPLAIN`만이라면 대상 스키마에 대한 `SELECT` 권한으로 충분합니다. 다른 사용자의 세션이나 `INNODB_TRX`를 보려면 `PROCESS` 권한이 필요합니다. 파라미터 변경에는 IAM 권한(`rds:ModifyDBParameterGroup` 등)이 필요합니다.

결과는 어떻게 판단합니까?

`rows_examined`가 `rows_sent`에 비해 현저히 크면 접근 방식의 문제, `INNODB_TRX`에 장시간 트랜잭션이 있으면 락 대기, 둘 다 아니고 CPU나 I/O가 가득 차 있으면 리소스 측 문제로 구분합니다. 다이제스트 집계는 '누적 실행 시간' 기준으로 정렬해 1회의 느림과 횟수의 많음을 구분하십시오.

EXPLAIN ANALYZE를 운영 환경에서 사용해도 됩니까?

대상이 조회계이고 실행해도 되는 부하임을 확인한 경우에만 사용하십시오. `EXPLAIN ANALYZE`는 예측이 아닌 실측값을 반환하는 대신 쿼리를 끝까지 실행합니다. 판단이 어렵다면 `EXPLAIN FORMAT=JSON`을 사용하십시오.

この文書がカバーする質問

  • Aurora MySQL에서 슬로우 쿼리 로그를 활성화해서 확인하고 싶다
  • performance_schema=OFF 환경에서 성능 분석을 어떻게 진행할까
  • MySQL에서 실행 중인 쿼리와 대기 상태를 확인하고 싶다
  • EXPLAIN 결과로부터 인덱스가 효과를 내지 못하고 있는지 판단하고 싶다

リスク表示の意味

  • 参照のみデータと設定を変更しません。
  • 影響は限定的ですが、権限と負荷の確認が必要です。
  • 性能・ロック・コストに影響する可能性があります。
  • 障害・データ損失・復旧作業が発生する可能性があります。
  • 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

하나의 느린 쿼리를 특정하는 단계까지는 이 문서의 절차로 도달할 수 있습니다. 실제 운영에서 어려운 점은 느려졌던 '그 순간'의 정보가 남아 있지 않다는 것입니다. GIIP에서는 슬로우 쿼리 로그와 CloudWatch 메트릭을 상시 수집하고, 임계값을 초과한 시점의 실행 중 세션과 트랜잭션 상태를 함께 기록하여 사후에 재현을 기다리지 않고도 원인 조사를 시작할 수 있는 상태를 유지하고 있습니다. 일상적인 수집과 1차 파악은 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エージェントと人間の専門家が継続的に監視・運用しています。

関連するナレッジ

関連サービス

느린 쿼리 원인 조사를 요청하기

同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。

느린 쿼리 원인 조사를 요청하기

ナレッジベース一覧へ