MySQL "주요 효율성"이란?
MySQL Workbench는 서버 상태와 관련하여 "Key Efficiency"라는 값을보고합니다. 이것은 무엇을 의미하며 그 의미는 무엇입니까?
에서 MySQL.com , "키 효율성"입니다 :
...
key_read_requests실제key_reads.
좋아, 그게 무슨 뜻이야. 서버 조정 방법에 대해 무엇을 알려 줍니까?
"주요 효율성"은 MySQL의 메모리 내에 보유 된 인덱스 캐시에서 얻는 가치의 양을 나타냅니다. 키 효율성이 높으면 대부분의 경우 MySQL은 메모리 공간 내에서 키 조회를 수행하며 이는 디스크에서 관련 인덱스 블록을 검색하는 것보다 훨씬 빠릅니다.
키 효율성을 향상시키는 방법은 시스템 메모리를 MySQL의 인덱스 캐시에 더 많이 할당하는 것입니다. 이를 수행하는 방법은 사용하는 스토리지 엔진에 따라 다릅니다. MyISAM의 경우 키 버퍼 크기 값을 늘립니다. InnoDB의 경우 innodb-buffer-pool-size 값을 늘립니다.
그러나 Michael Eakins가 지적했듯이 운영 체제는 최근에 액세스 한 디스크 블록의 캐시도 보유합니다. 운영 체제에 사용 가능한 메모리가 많을수록 캐시 할 수있는 디스크 블록이 많아집니다. 또한 디스크 드라이브 자체 (및 경우에 따라 디스크 컨트롤러)에도 캐시가있어 디스크에서 데이터 검색 속도를 높일 수 있습니다. 계층 구조는 다음과 같습니다.
- 가장 빠른-MySQL의 인덱스 캐시 내에서 인덱스 데이터를 검색합니다. 비용은 몇 가지 메모리 작업입니다.
- OS 파일 시스템 캐시에 보관 된 인덱스 데이터를 검색합니다. 비용은 시스템 호출 (읽기 용)과 일부 메모리 작업입니다.
- 디스크 시스템 캐시 (컨트롤러 및 드라이브)에 보관 된 인덱스 데이터 검색 비용은 시스템 호출 (읽기 용), 디스크 장치와의 통신 및 일부 메모리 작업입니다.
- 가장 느린-디스크 표면에서 인덱스 데이터를 검색합니다. 비용은 시스템 호출, 장치와의 통신, 디스크의 물리적 이동 (팔 이동 + 회전)입니다.
실제로 시스템이 매우 바쁘지 않으면 1과 2의 차이는 거의 눈에 띄지 않습니다. 또한 시나리오 3이 작동 할 가능성은 낮습니다 (시스템에 디스크 컨트롤러보다 여유 RAM이 적지 않은 경우).
나는 비교적 작은 인덱스 캐시 (512MB)를 가진 MyISAM 테이블이있는 서버를 사용했지만 시스템 메모리 (64GB)가 방대하여 인덱스 캐시의 크기를 늘리는 가치를 입증하기 어렵다는 것을 알게되었습니다. 나는 그것이 당신의 서버에서 일어나는 다른 일에 달려 있다고 생각합니다. 실행중인 모든 것이 MySQL 데이터베이스라면 OS 캐시가 매우 효과적 일 가능성이 높습니다. 그러나 동일한 서버에서 다른 작업을 실행하고 이러한 작업이 많은 메모리 / 디스크 액세스를 사용하는 경우 이러한 작업은 귀중한 캐시 된 인덱스 블록을 제거하여 MySQL이 디스크를 더 자주 공격하게 할 수 있습니다.
(시간이 있다면) 흥미로운 연습은 시스템을 느리게 실행하도록 조정하는 것입니다. 큰 테이블에서 표준 워크로드를 실행하고 영향이 눈에 띄게 나타날 때까지 MySQL 버퍼를 줄입니다. 파일 시스템 (cat large-file> / dev / null)을 통해 엄청난 양 (RAM보다 큼)의 관련없는 데이터를 펌핑하여 파일 시스템 캐시를 플러시합니다. 쿼리가 실행될 때 iostat를 확인하십시오.
"키 효율성"은 키가 얼마나 좋은지 측정하는 것이 아닙니다. 잘 설계된 키는 높은 "키 효율성"보다 성능에 훨씬 더 큰 영향을 미칩니다. 불행히도 MySQL은 당신을 도울 것이 많지 않습니다.
Key_read_requests는 캐시에서 키 블록을 읽기위한 요청 수입니다. key_reads는 디스크에서 키 블록의 물리적 읽기 수입니다. 따라서이 두 변수는 독립적으로 증가 할 수 있습니다. ( http://bugs.mysql.com/bug.php?id=28384 )
여전히 진흙처럼 분명합니다.
다음 설명은 다음과 같습니다.
부분적으로 유효한 Key_reads 사용
디스크가 컴퓨터의 다른 부분에 비해 매우 느리다는 것을 알고 있기 때문에 발생하는 물리적 읽기 수에 관심이 있다고 가정 할 때 Key_reads를 검사하는 부분적으로 유효한 이유가 있습니다. Key_reads는 실제로 물리적 디스크 읽기가 전혀 아니기 때문에 제가 위에서 "대부분 사실적"이라고 불렀던 부분으로 돌아갑니다. 요청 된 데이터 블록이 운영 체제의 캐시에 없으면 Key_read는 디스크 읽기이지만 캐시 된 경우 시스템 호출 일뿐입니다. 그러나 증명하기 어려운 첫 번째 가정을 만들어 보겠습니다.
입증하기 어려운 가정 # 1 : Key_read는 물리적 디스크 읽기에 해당 할 수 있습니다. 우리가 그 가정을 사실로 받아 들인다면 Key_reads에 대해 관심을 갖는 다른 이유는 무엇일까요? 이 가정은 "캐시 미스가 캐시 적중보다 훨씬 더 느리다"는 결과를 낳습니다. Key_read_request만큼 Key_read를 수행하는 것이 빠르다면 어쨌든 키 버퍼는 어떤 용도로 사용됩니까? MyISAM의 제작자는 캐시 적중이 실패보다 빠르도록 설계했기 때문에 이것에 대해 신뢰합시다. ( http://planet.mysql.com/entry/?id=23679 )
참조 URL : https://stackoverflow.com/questions/3845014/what-is-mysql-key-efficiency
'programing' 카테고리의 다른 글
| Android-화면이 아닌 휴대 전화 잠금 해제 이벤트 감지 (0) | 2021.01.14 |
|---|---|
| Objective-C에서 연산자를 오버로드 할 수 있습니까? (0) | 2021.01.14 |
| 두 개의 출력 목록 (즉, 목록의 분할)을 얻는 filter ()와 동등한 파이썬 (0) | 2021.01.14 |
| 참조 설정 대 출퇴근 대 변경 (0) | 2021.01.14 |
| R에서 x 축 눈금으로 플로팅 할 실제 x 축 값을 지정하는 방법 (0) | 2021.01.14 |