파일을 여기로 끌어오세요

SQL 업로드 ( 0 ) x -

페이지 관련 설정 클릭하여 페이지 상단으로 이동
Ctrl+Enter를 눌러 쿼리를 실행 Enter를 눌러 쿼리를 실행
오름차순
내림차순
순서:
SQL 디버그
개수
실행 순서
소요 시간
정렬 순서:
그룹 질의
그룹 해제 질의
접기 펼치기 추적 보기 추적 숨기기 개수: 소요 시간 :
북마크
다시 보기
추가
북마크가 없습니다
북마크 추가
옵션
기본값으로 복원
접기 펼치기 다시 쿼리하기 수정 분석 프로파일링 북마크 질의 실패 데이터베이스: 질의 실행 시간:

조언 시스템

가능한 성능 문제

문제:
업타임이 1일 미만인 경우 성능 최적화가 정확하지 않을 수 있습니다.
추천:
정확도를 높이려면 이 분석기를 사용하기 전에 하루 이상 서버를 실행하기를 권장합니다
이유:
업타임이 아직 0일 9시간 52분 43초 입니다
사용한 변수 / 식:
Uptime
테스트:
value < 86400
문제:
long_query_time은 10초 이상으로 설정되어 있으므로, 10초 이상 걸리는 슬로우 쿼리만 기록됩니다.
추천:
환경에 따라 long_query_time 을 더 낮은 값으로 설정하세요. 일반적으로 1-5초가 적당합니다.
이유:
long_query_time은 현재 10초로 설정 되어있습니다.
사용한 변수 / 식:
long_query_time
테스트:
value >= 10
문제:
슬로우 쿼리 로그가 비활성화 되어있습니다.
추천:
slow_query_log 설정을 'ON'으로 하여 슬로우 쿼리 로그를 남길 수 있습니다. 이 로그는 성능이 저하되는 쿼리 문제를 해결하는 데 도움이 됩니다.
이유:
slow_query_log가 'OFF'로 설정되었습니다
사용한 변수 / 식:
slow_query_log
테스트:
value == 'OFF'
문제:
정렬중인 행이 많습니다.
추천:
정렬하는 행이 많다면 문제가 없지만, 정렬이 많이 필요한 쿼리는 ORDER BY 절에서 인덱싱된 열을 사용하면 훨씬 빠르게 정렬할 수 있으므로 이를 사용하는 것이 좋습니다.
이유:
정렬된 행 평균: 2.7 초당
사용한 변수 / 식:
Sort_rows / Uptime
테스트:
value * 60 >= 1
문제:
인덱스를 사용하지 않는 조인이 너무 많습니다.
추천:
이는 조인을 하는 경우 전체 테이블 스캔이 일어난다는 것을 뜻합니다. 조인 조건에 사용하는 열에 인덱스를 추가하면 테이블 조인 속도가 크게 빨라집니다.
이유:
테이블 조인 평균: 2.33 초당, 이 값은 시간 당 1 보다 낮아야합니다
사용한 변수 / 식:
(Select_range_check + Select_scan + Select_full_join) / Uptime
테스트:
value * 60 * 60 > 1
문제:
첫 번째 인덱스 항목을 읽는 비율이 높습니다.
추천:
이는 일반적으로 전체 인덱스 스캔을 자주 수행함을 나타냅니다. 전체 인덱스 스캔은 테이블 스캔보다 빠르지만 큰 테이블의 경우 많은 CPU 자원이 필요하며, UPDATE 및 DELETE가 많거나 많은 양의 테이블이 있는 경우 'OPTIMIZE TABLE'을 실행하면 전체 인덱스 스캔의 횟수를 줄이거나 속도를 높일 수 있습니다. 그 외에는 쿼리를 다시 작성해야만 전체 인덱스 스캔을 줄일 수 있습니다.
이유:
인덱스 스캔 평균: 7.45 분당, 이 값은 시간 당 1 미만이어야 합니다
사용한 변수 / 식:
Handler_read_first / Uptime
테스트:
value * 60 * 60 > 1
문제:
고정된 위치에서 데이터를 읽는 비율이 높습니다.
추천:
이는 인덱스를 사용하지 않는 조인 쿼리를 포함하여 많은 쿼리가 결과를 정렬하거나 전체 테이블 스캔을 수행해야 함을 나타냅니다. 해당되는 경우 인덱스를 추가합니다.
이유:
고정된 위치의 데이터를 읽는 비율 평균: 2.68 초당, 이 값은 시간 당 1 미만이어야 합니다
사용한 변수 / 식:
Handler_read_rnd / Uptime
테스트:
value * 60 * 60 > 1
문제:
다음 테이블 행을 읽는 비율이 높습니다.
추천:
이는 많은 쿼리가 전체 테이블 스캔을 수행하고 있음을 나타냅니다. 해당되는 경우 인덱스를 추가합니다.
이유:
다음 테이블 행 읽기 비율: 90.89 초당, 이 값은 시간 당 1 미만이어야 합니다
사용한 변수 / 식:
Handler_read_rnd_next / Uptime
테스트:
value * 60 * 60 > 1
문제:
많은 임시 테이블이 메모리에 보관되지 않고 디스크에 기록되고 있습니다.
추천:
max_heap_table_size 및 tmp_table_size 값을 늘리면 도움이 될 수 있습니다. 그러나 일부 임시 테이블들은 이러한 변수 값과는 상관 없이 항상 디스크에 기록되며, MySQL Documentation에서 언급된 대로 이러한 상태(임시 테이블 안에 BLOB 이나 TEXT 열이 존재하거나 512바이트보다 큰 열이 존재)를 피하도록 쿼리를 다시 작성해야 합니다
이유:
임시테이블이 디스크에 저장되는 비율: 14.58 분당, 이 값은 시간 당 1 이하여야합니다
사용한 변수 / 식:
Created_tmp_disk_tables / Uptime
테스트:
value * 60 * 60 > 1
문제:
MyISAM 키 버퍼 (인덱스 캐시) 사용 % 가 낮습니다.
추천:
key_buffer_size의 크기를 줄이거나, 테이블을 다시 검토하여 인덱스가 제거되었는지 확인하거나, 사용 중인 인덱스에 대한 쿼리 및 예상치를 검토해야 할 수 있습니다.
이유:
사용된 적 있는 MyISAM 키 버퍼 최대 비율 (%): 0%, 이 값은 95% 이상이어야 합니다
사용한 변수 / 식:
Key_blocks_used * key_cache_block_size / key_buffer_size * 100
테스트:
value < 95
문제:
열려있는 테이블의 비율이 너무 높습니다.
추천:
테이블을 여는 데에는 디스크 입출력이 요구되어 시간이 많이 소모됩니다.table_open_cache값을 올리는 것이 해결에 도움이 될 수 있습니다.
이유:
열린 테이블 비율: 14.48 시간당, 이 값은 시간당 10보다 작아야 합니다
사용한 변수 / 식:
Opened_tables / Uptime
테스트:
value*60*60 > 10
문제:
열려있는 파일의 비율이 너무 높습니다.
추천:
open_files_limit를 증가시키는 것을 고려하시기 바라며, open_files_limit 값을 변경하고 재시작한 뒤 에러 로그를 확인하십시오.
이유:
열린 파일 비율: 7.69 시간당, 이 값은 시간당 5 미만이어야 합니다
사용한 변수 / 식:
Open_files / Uptime
테스트:
value * 60 * 60 > 5
문제:
쿼리 캐시의 80% 미만이 사용 중입니다.
추천:
이것은 query_cache_limit이 너무 낮아 발생했을 수 있습니다. 질의 캐시를 비우는게 도움이 될 수 있습니다.
이유:
전체 쿼리 캐시 크기(Size)에서 남은 쿼리 캐시 메모리의 현재 비율은 15% 입니다. 80%보다 높아야 됩니다
사용한 변수 / 식:
100 - Qcache_free_memory / query_cache_size * 100
테스트:
value < 80
문제:
쿼리 캐시의 결과 셋의 최대 크기가 기본값인 1 MiB 입니다.
추천:
query_cache_limit를 변경(일반적으로 증가)하여 효율을 높일 수 있습니다. 이 값은 쿼리 캐시에 넣을 수 있는 쿼리 결과의 최댓값을 결정합니다. 만약 1 MiB 이상의 캐시될 가능성이 높은 쿼리 결과(많은 읽기, 적은 쓰기)가 많다면, query_cache_limit를 증가하는 것이 효율을 높일 수 있습니다. 반면, 1 MiB 이상의 캐시될 가능성이 낮은 쿼리 결과(테이블 업데이트로 캐시가 무효화된다던가)가 많은 경우, query_cache_limit를 증가시키는 것은 효율을 낮출 수도 있습니다.
이유:
query_cache_limit가 1Mib로 설정되었습니다
사용한 변수 / 식:
query_cache_limit
테스트:
value == 1024*1024