MySQL 데이터베이스 최적화 우수 사례

Question

다소 큰 테이블 (테이블 당 총 100MB의> 50k 레코드)을 처리 할 때 최상의 성능을 위해 MySQL 설치를 최적화하는 모범 사례는 무엇입니까? 우리는 현재 Delphi 프로그래밍 커뮤니티의 뉴스 사이트 인 DelphiFeeds.com을 다시 작성하고 간단한 Update 문이 최대 50ms가 걸릴 수 있음을 알아 챘습니다. 이것은 많이 보인다. 표준 MySQL 설치 (예 : 더 많은 RAM을 사용하여 쿼리와 데이터를 캐시하는 등)에서 일반적으로 사용하지 않도록 설정/해제해야하는 권장 구성 설정이 있습니까?

또한 스토리지 엔진을 선택하면 성능에 어떤 영향이 있습니까? 우리는 InnoDB를 사용할 계획이지만, 성능상의 이유로 MyISAM을 권장한다면 MyISAM을 사용할 수도 있습니다.

Answer 1

은 "가장 좋은 방법은"입니다 :

1. 측정 성능뿐만 아니라 당신이 할 수있는 관련 서브 시스템을 분리.
2. 병목 현상의 근본 원인을 식별하십시오. I/O 경계입니까? CPU 바인딩? 메모리 바운드? 자물쇠를 기다리고 있니?
3. 발견 한 근본 원인을 완화하기 위해 변경하십시오.
4. 다시 측정하여만큼 병목 현상을 수정했는지 확인하십시오.
5. 2 단계로 진행하고 시스템이 충분히 빠르게 작동 할 때까지 필요한만큼 반복합니다.

RSS 피드를 http://www.mysqlperformanceblog.com에 구독하고 그 역사적인 기사도 읽으십시오. 그것은 성과 관련 지혜를위한 매우 유용한 자료입니다. 예를 들어, InnoDB와 MyISAM에 대해 물었다. 그들의 결론 : InnoDB는 평균적으로 MyISAM보다 ~ 30 % 높은 성능을 보입니다. MyISAM이 InnoDB를 능가하는 몇 가지 사용 시나리오가 있지만.

InnoDB vs. MyISAM vs. Falcon benchmarks - part 1

그 블로그의 저자

는 "고성능 MySQL은,"앤드류 바넷에 의해 언급 된 책의 공동 저자이다.

---

Re : @ ʞɔıu : I/O 바인딩 대 CPU 바인딩 대 메모리 바인딩의 방법은 플랫폼에 따라 다릅니다. 운영 체제는 ps, iostat, vmstat 또는 top과 같은 도구를 제공 할 수 있습니다. 또는 OS가 제공하지 않는 타사 도구를 구해야 할 수도 있습니다.

기본적으로 100 % 사용률/채도로 고정 된 리소스가 병목 현상이 될 수 있습니다. CPU 부하가 적지 만 I/O 부하가 하드웨어에 최대가되면 I/O 경계가됩니다.

그러나 단 하나의 데이터 포인트입니다. 구제 방법은 다른 요인에 따라 달라질 수 있습니다. 예를 들어, 복잡한 SQL 쿼리가 파일롯을 수행하고 있으며 이로 인해 I/O가 사용 중일 수 있습니다. 더 많은/더 빠른 하드웨어를 던져야합니까, 아니면 filesort를 피하기 위해 쿼리를 다시 디자인해야합니까?

는 StackOverflow의 게시물에 요약 너무 많은 요인이있다, 많은 책이 주제에 존재한다는 사실이를 지원합니다.데이터베이스를 효율적으로 운영하고 자원을 최대한 활용하는 것은 전문 기술과 지속적인 연구가 요구되는 풀 타임 직업입니다.

---

제프 앳 우드는 시스템에서 병목 현상을 찾는 것에 대해 멋진 블로그 기사를 쓴 : 그것은 일을 broadbrush 어렵다

• The Computer Performance Shell Game

Answer 2

O'Reilly의 "고성능 MySQL"을 구입하십시오. 그 주제에 관한 700 페이지 가량의 페이지입니다. 그래서 당신은 SO에 대한 간결한 대답을 찾을 수 있을지 의심 스럽습니다.

Answer 3

하지만 적당히 높은 수준의보기가 가능합니다 .

• 읽기 : 쓰기 비율을 평가해야합니다. 비율이 약 5 : 1보다 낮은 테이블의 경우, InnoDB는 삽입이 선택을 차단하지 않기 때문에 이점을 얻을 수 있습니다. 그러나 트랜잭션을 사용하지 않는 경우 innodb_flush_log_at_trx_commit을 1로 변경하여 MyISAM을 통해 성능을 복구해야합니다.
• 메모리 매개 변수를 확인하십시오. MySQL의 기본값은 매우 보수적이며 메모리 제한 중 일부는 일반적인 하드웨어에서도 10 배 이상 올릴 수 있습니다. 이렇게하면 INSERT보다는 SELECT에 도움이됩니다.
• MySQL은 색인을 사용하지 않는 쿼리와 너무 오래 걸리는 쿼리 (사용자 정의 가능)를 로깅 할 수 있습니다.
• 쿼리 캐시가 유용 할 수 있지만이를 계측해야합니다 (예 : 사용량 표시). 선인장이 그렇게 할 수 있습니다. 할 수있다.
• 응용 디자인도 중요하다 :
  • 가볍게 캐시 자주 인출하지만 좀 작은 데이터 세트는 (몇 초 즉 캐시 수명) 큰 차이가있을 것이다.
  • 이미 가져와야하는 데이터를 다시 가져 오지 마십시오.
  • 다단계 저장소는 바쁘게 읽혀지는 테이블에 많은 양의 삽입을 도와줍니다. 기본 아이디어는 ad-hoc 삽입을위한 테이블 (INSERT DELAYED도 유용 할 수 있음)을 가질 수 있지만 MySQL 내에서 모든 읽기가 일어나는 곳으로 업데이트를 이동하는 배치 프로세스입니다. 이것의 변형이 있습니다. 당신이 생각하는 것은 UPDATE가 "긴"업데이트는 하루에 한 번 발생하는 경우 실제로 아주 사소한 수 있습니다 발생 할 수있는 긴 시간이다 :
은 관점과 맥락도 중요하다 잊지 마세요.

Answer 4

이전에 논의 된 모범 사례가 많아 반복 할 이유가 없습니다. 무엇을해야할지 구체적으로 조언을하려면 MySQL Tuner을 실행 해보십시오. 데이터베이스 서버에서 다운로드하여 실행할 수있는 perl 스크립트로 데이터베이스가 수행되는 방식 (캐시 히트와 같은)에 대한 통계와 함께 어떤 이슈 또는 구성 매개 변수를 조정해야하는지에 대한 몇 가지 구체적인 권장 사항을 제공합니다 성능을 향상시킵니다.

이러한 통계는 모두 MySQL 자체에서 사용할 수 있지만이 도구는 훨씬 더 쉽게 이해할 수있는 기능을 제공합니다. 권장 사항과 관련하여 YMMV를 언급하는 것이 중요하지만, 일반적으로 매우 정확한 것으로 나타났습니다. 현실적인 트래픽으로 데이터베이스를 미리 연습 해보십시오.