tablestudioapp/plugins

TableStudio로 쿼리 속도 높이기

TableStudio는 측정을 통해 추측이 아닌 확실한 결과를 제공합니다. 아래 도구로 증명할 수 있는데 직관에 의존해 인덱스나 재작성을 추천하지 마세요. 대부분의 도구는 PostgreSQL 전용입니다. 다른 엔진에서는 explain_query를 사용하고 실행 계획을 분석하세요.

먼저 database-workflow 스킬에 설명된 대로 연결을 선택하세요. 실제 데이터가 있는 데이터베이스에 대해 분석을 실행하는 것이 좋습니다. 거의 비어 있는 개발 데이터베이스는 잘못된 실행 계획을 제공할 수 있습니다.

느린 부분 찾기

• 사용자가 쿼리나 엔드포인트를 언급한 경우: 해당 SQL을 (코드 또는 ORM 로깅에서) 찾은 후 "하나의 문 진단"으로 이동하세요.
• "데이터베이스가 왜 느린가요?" slow_queries를 호출하세요. pg_stat_statements에서 총 시간 기준으로 문을 정렬합니다. 각 행의 query_id를 유지하세요. 다른 도구에서 이 ID를 사용할 수 있습니다. 확장 기능이 설치되지 않은 경우 도구는 활성화하는 방법을 설명하므로, 요청 없이 설치하지 말고 그 정보를 전달하세요.
• 광범위한 튜닝: workload_index_advisor는 가장 많은 데이터베이스 시간을 차지하는 쿼리를 가장 적은 인덱스로 커버하고, 사용되지 않는 기존 인덱스를 나열합니다.

건강 상태 점검

사용자가 데이터베이스에 문제가 무엇인지 묻거나 일반적인 검토를 원할 때, 아무것도 변경하지 말고 다음을 보고하세요:

1. database_health. 요약하기 전에 unavailable 목록을 읽으세요. 항목이 있는데 findings가 비어 있으면 검사가 건너뛰어진 것이지 모든 것이 정상이라는 뜻이 아닙니다.
2. database_overview: 크기, 가장 크고 바쁜 테이블, 연결 수.
3. schema_issues (테이블 없이): 데이터베이스 전반의 설계 문제.

가장 중요한 결과부터 평이한 언어로 작성하세요: 무엇이 문제인지, 무시했을 때의 비용, 수정 방법. 각 결과의 verify_sql을 포함하여 사용자가 숫자를 확인할 수 있도록 하고, 수정 사항의 lock_impact도 포함하세요. 사용자가 선택한 수정 사항을 "배포하기" 아래에 제안하세요.

하나의 문 진단

1. SQL과 함께 optimize_query를 호출하세요 (slow_queries에서 가져온 query_id가 있으면 함께 제공). 읽기 전용 문의 경우 analyze: true를 전달하여 측정 검사가 실행되도록 하세요. 롤백된 트랜잭션 내에서 한 번 실행됩니다. 할 가치가 없는 경우 already_fast를 보고하므로, 개선 사항을 만들어내지 말고 그대로 전달하세요.
2. 더 자세한 내용을 원하면 explain_query를 사용하세요 (읽기 전용일 때만 analyze: true). 각 노드에서 actual_rows와 estimated_rows를 비교하세요. 큰 차이는 오래된 통계(테이블에 ANALYZE 실행)를 의미하며, 종종 누락된 인덱스보다 실제 버그일 수 있습니다.
3. $1, $2 자리 표시자가 있는 문은 계획을 정확히 세우기 위해 실제 값이 필요합니다. suggest_parameter_values는 기록, 활성 세션 및 통계에서 값을 찾습니다.

수정 사항 증명

무엇이든 추천하기 전에 benchmark_query_variants(쿼리 랩)를 사용하세요:

• 기준 SQL과 후보를 variants로 제공하세요: 재작성된 sql, hypothetical_indexes(hypopg로 계획만, 생성되지 않음), hide_indexes, 또는 플래너 settings. 또는 variants를 생략하고 find_faster가 자체적으로 제안하도록 하세요.
• 각 매개변수 집합에 대해 여러 실행의 중간값을 보고하고, 모든 재작성이 기준과 동일한 행을 반환하는지 확인합니다.
• same_rows가 'yes'인 변형만 추천하세요. recommendation에 있는 변형을 선호하세요. 직관에 의한 백분율이 아닌 측정된 전후 값을 인용하세요.

인덱스를 삭제하기 전에 (사용되지 않거나 중복된 경우), hide에 해당 인덱스를 포함하여 index_what_if를 실행하세요. 더 비싸지는 문이나 오늘날 인덱스를 사용하는 문은 영향을 받을 수 있습니다.

배포하기

인덱스와 재작성은 database-workflow 스킬의 일반 변경 흐름을 따릅니다:

• 인덱스 변경은 스키마 변경입니다. 저장소에 마이그레이션 도구가 있으면 해당 인덱스를 추가하세요. 그렇지 않으면 stage_migration으로 제안하고, 측정된 숫자를 rationale에 포함하세요.
• PostgreSQL에서는 트래픽이 있는 테이블에 대해 CREATE INDEX CONCURRENTLY를 사용하고 트랜잭션으로 감싸지 마세요.
• 쿼리 재작성은 코드 변경입니다: 이를 실행하는 코드를 편집하고, 요약에 벤치마크 결과를 언급하세요.