it-swarm-ko.com

가장 큰 속도 향상을 제공하는 MySQL의 구성 옵션은 무엇입니까?

가장 큰 속도 향상을 제공하는 MySQL의 구성 옵션은 무엇입니까?

실제 구성 파일 개선, 테이블 유형, 하드웨어 설정, 복제 등에 대해 궁금합니다. 쿼리 구조 및 테이블 구조 이외의 모든 것 (웹 사이트 및 Stack Overflow에서 쉽게 찾을 수 있음). 쿼리 캐시 설정과 같은 것이 가장 빠른 속도를 제공 했습니까? 드라이브는 어떻습니까? 외부 RAID 또는 내부에있는 것이 더 낫습니까? 복제가 특히 읽기 큰 쿼리에서 더 나은 성능을 제공 했습니까?

MySQL의 성능을 향상시키기 위해 어떤 다른 설정/변경 사항을 적용 했습니까?

참고 : 이것이 사용량에 따라 매우 의존적이라는 것을 알고 있지만 (즉, 소규모 웹 사이트 대 데이터웨어 하우스) 대부분의 사람들이 다양한 사이트/시스템에서 작업 할 것이라고 생각하므로 다양한 분야에 적용 할 수있는 다양한 기술을 아는 것이 좋습니다. 상황. 또한 상황간에 테크닉을 옮길 수 있다고 생각합니다.

mysqloptimization
29
Darryl Hein

내 권장 사항은 다음과 같습니다.

  • 하드웨어 RAID를 사용합니다. 이것은 다른 게시물에서 소프트웨어 RAID를 사용하라는 내 권장 사항과 상반되지만 하드웨어 RAID 카드를 원하는 특정 상황입니다. 특히 RAID 카드의 배터리 지원 NVRAM을 사용하여 로그 파일을 디스크로 fsync하는 데 걸리는 시간을 줄일 수 있습니다.
  • RAID 1 또는 RAID 10 볼륨 만 사용하십시오. RAID 5 또는 6 쓰기 비용은 혼합 된 읽기/쓰기 워크로드에서 허용하기에는 너무 높습니다.
  • 데이터, 로그 및 임시 볼륨에 별도의 LUN을 사용하십시오. 이들은 모두 OS 및 스왑 볼륨과 분리되어야합니다.
  • InnoDB 를 사용하십시오.
  • Innodb_file_per_table 사용
  • 64 비트 OS 사용
  • InnoDB 버퍼 풀을 사용 가능한 RAM의 ~ 80 %로 설정하십시오.
  • 로그 파일을 버퍼 풀 크기의 1/4 (2-4 로그 파일 사이)로 설정하십시오. 로그 파일이 클수록 종료 및 복구 시간이 느려지지만 대용량 데이터베이스 덤프를 더 빨리 복원 할 수 있습니다.
  • log_slow_queries, log-queries-not-using-indexes, set-variable = long_query_time = 1, 해당 로그의 모든 쿼리를 조사하고, 가능할 때마다 테이블 스캔 및 임시 테이블을 피하기 위해 스키마를 리팩터링하십시오.
20
Dave Cheney

다시 한번 Dave Cheney는 정말로 그것을 여기 공원에서 두 드렸습니다. 나는 당신의 질문에 대한 그의 대답에 아무것도 추가 할 수 없습니다. 그러나 나는 당신이 묻지 않은 것을 지적하고 싶습니다. Jeremy Zawodny와 Peter Zaitsev가 몇 년 전에 저에게 가르쳐 준 것처럼 잘못된 쿼리를 추적하고 최적화하는 데 소요 된 ROI는 구성 변경에 소요되는 시간에 대한 ROI를 10 배 이상 달성 할 것입니다. 물론 잘못된 구성, 잘못된 RAID 설정 또는 부족한 RAM을 원하지 않습니다. 그러나 우수하고 심지어 한계가있는 MySQL DBA의 잘못된 쿼리 (일반적으로 DBA가 아닌 개발자/프레임 워크에서 제공)는 만성 조건이며, 여기서 잘못된 구성은 지속 가능 1입니다. .

(나는 잠시 동안 그 형용사를 파고 들었지만 여전히 내가 선택한 것에 만족하지 않습니다.)

개발자가 Ruby on Rails 및 Django)와 같은 프레임 워크에서 일반적인 ORM과 같은 ORM을 사용하는 경우 반드시 모니터링해야 함을 다시 강조하고 싶습니다. 개발자가 SQL에 대한 생각을 멈추고 DB가 추상화되도록하면 정말 불쾌합니다. 방금 언급 한 두 가지 프레임 워크가 마음에 듭니다. (나쁜 입에 대해 투표하지 마십시오.) Query Sleuthing을 매우 중요하게 만듭니다. (읽기 : Job Security)

11
Bruno Bronosky

다른 몇 가지 사항 (Dave Cheney의 답변에서 언급되지 않은)

  • 데이터의 이중 버퍼링을 방지하려면 innodb_flush_method를 O_DIRECT로 설정하십시오. RAID 카드에 배터리 지원 쓰기 캐시가 없거나 데이터가 SAN에있는 경우이를 피하십시오.

  • 또한 innodb_thread_concurrency로 재생하십시오. 기본값은 8이라고 생각하지만 성능이 향상되는지 확인하기 위해 조정할 가치가 있습니다.

  • 쿼리 캐시가 켜져 있는지 확인하고 통계를 확인하여 적중률을 확인합니다. 좋으면 적중률을 높이기 위해 증가 시키십시오.

  • 실행되는 응용 프로그램에 따라 기본 격리 수준을 변경할 수 있습니다. 기본값은 REPEATABLE_READ이지만 READ_COMMITTED는 더 나은 성능을 제공 할 수 있습니다.

  • 문이 대부분 UPDATE 및 DELETE 인 경우 수정 될 결과 집합을 반환하는 SELECT 쿼리를 수행하여 슬레이브에서 캐시를 프라이밍 할 수 있습니다. 이 작업을 수행 할 mk-slave-prefetch 도구를 확인하십시오.

  • MyISAM 및 InnoDB를 제외한 다른 스토리지 엔진 살펴보기

4
Nathan

하드웨어에 대해 말할 수는 없지만 http://blog.mysqltuner.com 시도해 볼 수 있습니다. MySQL 설정을 분석하는 Perl 스크립트입니다.

http://www.thomas-krenn.com/de/wiki/MySQL_Performance_Tuning#mysqltuner.pl 에서 샘플 출력을 볼 수 있습니다.

3
weeheavy

가장 먼저해야 할 일은 메모리 매개 변수를 살펴 보는 것입니다. MySQL의 기본 설정은 매우 보수적입니다. 어떤 엔진을 사용하든 메모리 매개 변수의 수를 10 배 또는 100 배까지 높여야 할 것입니다.

다음으로해야 할 일은 테이블 캐시를 살펴 보는 것입니다. 기본값은 64이며, 테이블이 약 60 개 이하인 경우에만 유용합니다. 당신은 그것을 멀리 높이고 싶을 것입니다.

세 번째로해야 할 일은 스레드 및 연결 매개 변수를 살펴 보는 것입니다. 기본 wait_timeout은 대부분의 웹 기반 애플리케이션에서 매우 길며 30 초 정도로 줄일 수 있습니다. 이것은 MySQL이 더 빨리 연결을 얻을 수 있기 때문에 메모리 사용도 향상되어 '휴면'상태에있는 상태가 훨씬 적습니다.

1
staticsan