본문으로 건너뛰기

DBMS 모니터링 : Table

크기 정보​

전체 테이블의 정보를 확인 한다.

스키마별 크기정보​

스키마별로 상세 정보를 확인 한다.

스키마별 테이블 개수​

스키마별로 엔진 정보와 테이블 수를 확인 한다.

PK 없는 테이블​

테이블에서 PK 가 없는 갯수를 확인 한다.

Index 없는 테이블​

테이블에서 인덱스가 없는 것을 확인 한다.

PK가 숫자 타입이 아닌 테이블​

숫자 타입이 아닌 테이블 정보를 확인 한다.

Data보다 Index가 더 큰 테이블 스냅샷​

풀스캔 비율​

MySQL의 전체 스캔 비율은 데이터베이스 서버가 인덱스를 사용하여 데이터를 검색하는 대신 전체 테이블을 스캔하는 횟수의 백분율을 나타냅니다. 전체 스캔 비율이 높으면 데이터베이스가 인덱스를 효율적으로 사용하지 않아 쿼리 성능이 느려진다는 것을 나타냅니다.

전체 스캔 비율을 최소화하기 위해 자주 사용하는 컬럼에 인덱스를 생성하고 인덱스를 활용하여 쿼리를 작성하는 것이 좋습니다. 인덱스를 최적화하면 데이터베이스 서버가 전체 테이블을 검색하는 대신 인덱스에서 원하는 데이터를 빠르게 찾을 수 있으므로 쿼리 성능이 크게 향상될 수 있습니다.

사용된 Parameter 정보는 아래와 습니다.

  • SELECT_FULL_JOIN
  • 계산 (HANDLER_READ_RND_NEXT + HANDLER_READ_RND) / (HANDLER_READ_RND_NEXT + HANDLER_READ_RND + HANDLER_READ_FIRST + HANDLER_READ_NEXT + HANDLER_READ_KEY + HANDLER_READ_PREV) * 100.0");

락 대기수​

immediate 및 waited는 각각 즉시 승인된 테이블 잠금 요청 수와 잠금 해제를 기다려야 하는 테이블 잠금 요청 수를 표시하는 MySQL 성능 스키마의 두 가지 성능 메트릭입니다.

immediate 테이블이 잠기지 않았거나 잠금을 즉시 사용할 수 있었기 때문에 즉시 허용된 잠금 요청 수를 반영합니다. 이 메트릭은 잠금 메커니즘의 성능과 서버의 전체 부하를 나타냅니다. 많은 수의 즉시 잠금 부여는 많은 수의 요청을 처리하는 잘 조정된 서버를 나타낼 수 있습니다.

반면 waited는 잠금이 해제될 때까지 기다려야 하는 잠금 요청 수를 반영합니다. 이 메트릭은 여러 쿼리가 동시에 동일한 테이블에 액세스하려고 시도하고 하나는 다른 하나가 완료될 때까지 기다려야 하는 잠금 경합의 존재를 나타낼 수 있습니다. waited 값이 높으면 성능 저하를 나타내는 지표가 될 수 있으며 데이터베이스가 높은 동시 사용량에 최적화되지 않았음을 나타낼 수 있습니다.

요약하면 이 두 메트릭은 MySQL의 잠금 메커니즘 성능에 대한 중요한 정보를 제공하며 시스템의 잠재적인 병목 현상이나 문제를 식별하는 데 사용할 수 있습니다.

사용된 Parameter 정보는 아래와 습니다.

  • TABLE_LOCKS_IMMEDIATE : 테이블 잠금을 즉시 획득한 수
  • TABLE_LOCKS_WAITED : 테이블 잠금을 위해 대기한 수

Tmp 디스크 사용률​

MySQL의 tmp 디스크 비율은 데이터베이스 서버에 사용 가능한 총 디스크 공간과 비교하여 임시 저장소에 사용되는 디스크 공간의 비율을 나타냅니다. 이 임시 저장소는 복잡한 쿼리 중에 중간 결과를 저장하는 데 사용되며 데이터 정렬 및 그룹화에도 사용됩니다.

CREATED_TMP_TABLES는 메모리가 아닌 디스크에 생성된 임시 테이블의 수를 나타내는 MySQL의 성능 메트릭입니다. 이 지표의 값은 MySQL 서버가 사용 중인 임시 디스크 공간의 양을 나타내는 지표입니다. CREATED_TMP_TABLES 값이 높으면 MySQL 서버의 메모리가 부족하여 임시 테이블을 저장하기 위해 임시 디스크 공간을 사용해야 함을 나타냅니다.

사용된 Parameter 정보는 아래와 습니다.

  • CREATED_TMP_TABLES : 임시테이블을 메모리에 생성한 수
  • 계산 CREATED_TMP_TABLES / QUERIES * 100

메타 데이터 락​

레코드 락​

열린 테이블 수​

MySQL에서 테이블을 열고 닫는 작업은 데이터베이스 성능에 중요한 영향을 미칩니다. 열린 테이블 수와 열었던 테이블 수를 모니터링하여 테이블 캐시 효율성과 시스템 성능을 평가할 수 있습니다.

Files 는 현재 열려있는 테이블 파일의 갯수이며, 실제 디스크에서 열린 파일의 핸들 수입니다.

값이 클수록 많은 테이블이 동시에 열려있다는 것이며, 각 열린 파일은 메모리를 사용하기 때문에 너무 많은 파일이 열려있다면 성능 저하의 가능성이 있습니다.

Tables 는 현재 열려있는 테이블의 갯수이며, 테이블 캐시에 저장 된 테이블 수를 나타냅니다.

캐시된 테이블은 빠르게 접근이 가능하며, 많이 열려있을 수록 테이블 캐시 메모리의 사용량이 증가합니다.

Ratio 는 열린 테이블 수 대비 테이블 캐시 사용률입니다.

열었던 테이블 수​

MySQL에서 테이블을 열고 닫는 작업은 데이터베이스 성능에 중요한 영향을 미칩니다. 열린 테이블 수와 열었던 테이블 수를 모니터링하여 테이블 캐시 효율성과 시스템 성능을 평가할 수 있습니다.

Files 는 MySql 시작 후 지금까지 열었던 테이블 파일의 총 갯수입니다.

Tables 는 MySql 시작 후 지금까지 열었던 테이블의 총 갯수입니다.

누적 값이 높을 수록 많은 테이블을 반복적으로 열었다는 것이므로, 캐시 미스를 점검하고, 적중률을 개선할 필요가 있습니다.

락 경합​

MySQL에서 락은 데이터 일관성과 동시성을 보장하는 중요한 메커니즘입니다. 락 경합을 모니터링하여 데이터베이스의 성능 병목 현상을 파악하고 최적화할 수 있습니다.

락 경합의 유형에는 메타데이터 락 경합, 행 락 경합, 테이블 락 경합이 있습니다.

메타데이터 락 경합은 DDL 작업과 DML 작업이 충돌 할 때 발생할 수 있으며, 행 락 경합은 동일한 행을 동시 수정할 경우, 테이블 락 경합은 여러 세션에서 동일 테이블을 수정할 경우 발생합니다.

락 경합이 심각하다면 트랜잭션 분할, 타임아웃설정을 통한 무한대기 방지, 재시도 로직 등의 최적화가 필요 합니다.

최종 수정: 에 MSKIM\kmins가