MySQL 업데이트 쿼리의 성능을 프로파일했습니다. 정상 상태가 된 후 처리량 그래프에서 갑작스런 하락이 관찰되었습니다. 나는 여러 번 시험을 다시했다. 나는 갑작스런 하락 장소가 같은 시나리오에서 같은 지점이 아니라는 것을 알았다. 시간은 시간에 따라 다릅니다. 버퍼 풀에 캐싱 (caching) 때문에이 문제가 발생했는지 궁금합니다. 나는 MsSQL을 사용하여 같은 테스트를했는데 나는이 문제를 찾을 수 없었다. 이 혼란을 도와주세요.MySQL 업데이트 쿼리에서 갑작스런 하락이 관찰되었습니다.
성능 (큰 테이블 용)은 모두 디스크 히트에 관한 것입니다. 그런 감정을 완화시키는 기법.
자세한 내용 - 예 : SHOW CREATE TABLE, SHOW TABLE STATUS 및 UPDATE. 성능 저하가 얼마나 심한가? buffer_pool의 크기는 얼마나됩니까? RAM의 몇 분의 일입니까? 그러나 여기에 몇 가지 일반적인 대답이 있습니다.
"버퍼 변경"은 인덱스에 쓰기를 캐시하는 기술입니다. INSERTs 및 DELETEs은 결국 비 고유 인덱스를 모두 업데이트해야합니다. 또한 UPDATEs은 인덱스 된 열이 변경되는 경우에도 마찬가지로 수행해야합니다. 이러한 변경 사항은 buffer_pool에있는 "버퍼 변경"에 수집됩니다. 기본적으로 buffer_pool의 25 %는 그러한 전용입니다.
몇 가지 수정을하면 변경 버퍼가 가득 차게됩니다. 이 시점에서 인덱스를 포함하는 BTrees를 업데이트하려면 읽기 - 수정 - 쓰기 사이클이 필요합니다. 이 은 일 수 있습니다 처리 속도가 느려집니다.
한편 아직 업데이트되지 않은 인덱스가 필요한 쿼리는 어떻게됩니까? 문제가 아니다. CB는 필요에 따라 검사됩니다. (여분의 CPU 주기로 I/O를 피할 수 있습니다. 일반적으로 승리합니다.)
UUID는입니다. 성능이 떨어지면 가끔은 "절벽에서 떨어졌습니다"syndrone이 있습니다. 그 이유는 버퍼가 무작위 적이기 때문에 일단 테이블 (또는 uuid 인덱스)이 buffer_pool에 완전히 들어 맞을 수있는 것보다 크면 캐싱이 얼마나 쓸모 없게되는지. UUID 열은 일반적으로 UNIQUE (또는 PRIMARY)으로 선언되므로 즉시 INSERT에서 확인해야합니다. 즉, 변경 버퍼에서 지연 될 수 없습니다.
오랜 시간 동안 UUID가있는 테이블을 작성하는 경우 buffer_pool에 모두 캐싱 될 수 있으며 처리량이 좋습니다. 하지만 결국 테이블/인덱스가 너무 커지고 I/O가 급격히 증가합니다. 테이블의 크기가 캐시 할 수있는 크기의 20 배가되면 캐시에서 1/20의 작업 만 찾을 수 있습니다.
약 MSSql? 다른 공급 업체는 주요 성능 저하 요인 인 디스크를 해결하기 위해 여러 가지 기술을 사용합니다. 나는 오라클 등이 무엇을하는지 모른다. 하지만 아마도 다를 수 있으며 아마도 UUID 또는 캐시가 가득 차있어서 벽돌 벽의 다른 변형을 치게됩니다.
(다른 설명이 표시 될 수 있습니다.)