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 |
そのまま実行できるコマンド
- 対象
- 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`도 사용할 수 있으며, 이는 전역 뮤텍스를 사용하지 않는 구현이라 연결 수가 많은 환경에서 영향이 더 적습니다.
- 対象
- 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`의 활성화 여부와 관계없이 조회할 수 있습니다.
- 対象
- 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`은 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) 값까지 포함한 상세 정보를 반환하며, 이쪽은 실행을 수반하지 않습니다.
- 対象
- 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로 조회할 수 있지만, 기록 방식이 테이블 삽입으로 바뀌므로 부하의 성격이 달라집니다.
- 対象
- 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_sec | 1회당 평균 실행 시간(초) | 합계는 작지만 평균이 큰 쿼리는 실행 시점에 따라 문제가 될 수 있음 |
| 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`에 동일한 쿼리가 오랫동안 남아 있다
考えられる原因(可能性の高い順)
01
실행 계획이 바뀌어 인덱스가 사용되지 않게 됨
데이터량 증가나 통계 갱신으로 인해 옵티마이저가 다른 접근 방식을 선택하는 경우가 있습니다. `rows_examined`가 `rows_sent`에 비해 극단적으로 커졌다면 이 가능성이 높습니다.
02
락 대기로 실행이 진행되지 않음
쿼리 자체는 가볍더라도 다른 트랜잭션이 행 락을 보유하고 있으면 대기하게 됩니다. `information_schema.INNODB_TRX`에 오래 열려 있는 트랜잭션이 남아 있지 않은지 확인합니다.
03
데이터량이 증가해 스캔 비용이 상승함
같은 실행 계획이라도 대상 행이 늘어나면 소요 시간이 늘어납니다. 이 경우에는 인덱스 설계나 검색 조건의 재검토가 필요하며, 파라미터 조정으로는 해결되지 않습니다.
04
정렬·임시 테이블이 디스크로 내려가고 있음
`ORDER BY`나 `GROUP BY`의 대상이 크면 임시 테이블이 디스크 위에 생성됩니다. 다이제스트 집계의 `SUM_CREATED_TMP_DISK_TABLES`로 확인할 수 있습니다.
05
리더 인스턴스 쪽의 레플리카 지연이나 리소스 경쟁
읽기를 리더 엔드포인트로 보내는 경우, 라이터와 리더의 부하 상황이 다릅니다. 먼저 어느 인스턴스에서 느린지 구분하십시오.
確認手順
- 1
어느 인스턴스, 어느 시간대인지 특정하기
参照のみCloudWatch의 `CPUUtilization`, `DatabaseConnections`, `ReadLatency` / `WriteLatency`, `Deadlocks`를 확인해 사건 발생 시간대와 인스턴스를 좁힙니다.
- 2
슬로우 쿼리 로그 설정값 확인하기
参照のみ위의 `SHOW GLOBAL VARIABLES`를 실행해 로그가 애초에 수집되고 있는지, `long_query_time`이 실제 상황에 맞는지 확인합니다.
- 3
실행 중인 세션 확인하기
参照のみ`information_schema.PROCESSLIST`로 느린 쿼리가 실행 중인지 대기 중인지 확인합니다. `STATE` 열이 단서가 됩니다.
- 4
장시간 트랜잭션과 락 확인하기
参照のみ`information_schema.INNODB_TRX`를 참조합니다. `performance_schema`가 비활성화되어 있어도 실행할 수 있습니다.
- 5
다이제스트 집계로 상위 항목 추출하기
参照のみ`performance_schema`가 활성화되어 있으면 `events_statements_summary_by_digest`를 누적 실행 시간 내림차순으로 확인합니다.
- 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)나 재시작 직후에는 모수가 작아 판단 근거가 되지 않습니다.
- 이 문서는 원인 파악 절차를 설명한 것이며, 특정 설정값을 적용하면 빨라진다는 것을 보장하지 않습니다.
バージョン・環境による違い
これで解決しない場合に確認すること
애플리케이션 측 타임아웃과 커넥션 풀 설정 확인하기
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エージェントと人間の専門家が継続的に監視・運用しています。
Aurora MySQL에서 감사 로그를 수집하고 확인하는 방법
Aurora MySQL의 Advanced Auditing을 클러스터 파라미터로 활성화하고 CloudWatch Logs 또는 RDS 로그 파일로 확인하는 절차입니다. 기록 대상을 좁히는 방법도 정리합니다.
aurora-mysqlAurora MySQL에서 utf8mb3에서 utf8mb4로 마이그레이션할 때 확인할 사항
utf8mb4로 변환할 때 가장 먼저 깨지는 것은 인덱스의 키 길이입니다. 대상을 찾아내는 SQL, 콜레이션 선택 방법, 변환 시 영향과 설정 위치를 정리합니다.
sql-serverSQL Server에서 테이블별 통계 정보 업데이트 일시를 확인하는 SQL
sys.stats와 STATS_DATE로 테이블·통계별 최종 업데이트 일시와 업데이트 이후 변경된 행 수를 목록화하는 참조 전용 SQL입니다.
monitoring서버와 데이터베이스를 24시간 모니터링할 때 설정할 항목
24시간 모니터링을 설계할 때의 모니터링 대상·임계값 사고방식·에스컬레이션 체계·외부 모니터링의 필요성을 계층별로 정리한 체크리스트입니다.
関連サービス
느린 쿼리 원인 조사를 요청하기
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
느린 쿼리 원인 조사를 요청하기