MySQL의 어떤 구성 옵션이 가장 빠른 속도 향상을 제공합니까?

MySQL의 어떤 구성 옵션이 가장 빠른 속도 향상을 제공합니까?

실제 구성 파일 개선, 테이블 유형, 하드웨어 설정, 복제 등에 대해 궁금합니다. 쿼리 구조 및 테이블 구조 이외의 것은 웹 사이트 및 스택 오버플로에서 쉽게 찾을 수 있습니다. 쿼리 캐시 설정과 같은 것들이 가장 빠른 속도를 냈습니까? 드라이브는 어떻습니까? 외부 RAID 또는 내부에 두는 것이 더 낫습니까? 특히 큰 쿼리를 읽을 때 복제 성능이 향상 되었습니까?

MySQL의 성능을 향상시키기 위해 다른 설정 / 변경은 무엇입니까?

참고 : 이들은 매우 사용에 의존적이라는 것을 알고 있습니다 (즉, 작은 웹 사이트 대 데이터웨어 하우스). 우리 대부분은 아마도 다양한 사이트 / 시스템에서 작업 할 것이라고 생각하므로 다른 기술에 적용 할 수있는 다양한 기술을 아는 것이 좋습니다 상황. 또한 상황간에 일부 기술을 이전 할 수 있다고 생각합니다.

여기 내 추천 사항이 있습니다 (밀링은 다를 수 있습니다)

• 하드웨어 RAID를 사용하십시오. 이것은 다른 게시물에서 소프트웨어 RAID를 사용하는 권장 사항과 상반되지만 하드웨어 RAID 카드를 원하는 특정 상황입니다. 특히 RAID 카드의 배터리 백업 NVRAM을 사용하여 로그 파일을 디스크에 fsync하는 데 걸리는 시간을 줄이려고합니다.
• RAID 1 또는 RAID 10 볼륨 만 사용하십시오. RAID 5 또는 6 쓰기 비용이 너무 커서 혼합 된 읽기 / 쓰기 워크로드에서 견딜 수 없습니다.
• 데이터, 로그 및 tmp 볼륨에 별도의 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, 해당 로그의 모든 쿼리를 조사하고 가능할 때마다 테이블 스캔 및 tmp 테이블을 피하기 위해 스키마를 리팩터링하십시오.

다시 한번 데이브 체니 (Dave Cheney)는 그것을 공원에서 떨어 뜨 렸습니다. 나는 당신의 질문에 대한 그의 대답에 아무것도 추가 할 수 없습니다. 그러나 나는 당신이 묻지 않은 것을 지적하고 싶습니다. 몇 년 전에 Jeremy Zawodny와 Peter Zaitsev가 가르쳐 준 것처럼 잘못된 쿼리를 추적하고 최적화하는 데 소요되는 시간에 대한 ROI는 구성 변경에 10 배의 시간을 투자하여 ROI를 수행 할 것입니다. 물론 구성이 잘못되었거나 RAID 설정이 잘못되었거나 RAM이 부족하지는 않습니다. 그러나 훌륭하고 미미한 MySQL DBA의 나쁜 쿼리 (일반적으로 DBA가 아닌 개발자 / 프레임 워크의 쿼리)는 잘못된 구성이 참을 수 없는 만성적 조건 입니다.

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

개발자가 Ruby on Rails 및 Django와 같은 프레임 워크에서 일반적인 것과 같은 ORM을 사용하는 경우 DB에 충돌하는 쿼리를 반드시 모니터링해야한다는 점을 다시 강조하고 싶습니다. 개발자가 SQL에 대한 생각을 멈추고 DB가 추상화되도록 할 때,이 문제는 정말 불쾌합니다. 방금 언급 한 두 가지 프레임 워크를 좋아합니다. (나쁜 입으로 나에게 투표하지 마십시오.) 그것은 Query Sleuthing을 매우 중요하게 만듭니다. (읽기 : 직업 보안)

다른 것들은 거의 없습니다 (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를 제외한 다른 스토리지 엔진을 살펴보십시오

하드웨어에 대해 아무 말도 할 수 없지만 http://blog.mysqltuner.com 을 사용해보십시오. MySQL 설정을 분석하는 Perl 스크립트입니다.

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

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

다음으로해야 할 일은 테이블 캐시를 보는 것입니다. 기본값은 64이며, 약 60 개의 테이블이없는 경우에만 유용합니다. 당신은 그렇게 먼 길을 제기하고 싶을 것입니다.

세 번째로해야 할 일은 스레드 및 연결 매개 변수를 살펴 보는 것입니다. 기본 wait_timeout은 대부분의 웹 기반 응용 프로그램에서 매우 길며 30 초로 줄일 수 있습니다. MySQL이 더 빨리 연결을 가져 와서 '슬립'상태에서 훨씬 덜 누워 있기 때문에 메모리 사용량도 향상됩니다.