MySQL 느린 쓰기

다음 표에 삽입하는 데 최대 70 초가 걸립니다.

CREATE TABLE IF NOT EXISTS `productsCategories` (
  `categoriesId` int(11) NOT NULL,
  `productsId` int(11) NOT NULL,
  PRIMARY KEY (`categoriesId`,`productsId`),
  KEY `categoriesId` (`categoriesId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

테이블에는 약 100,000 개의 행이 있으며 디스크에서 7MB를 사용합니다.

쓰기 성능을 향상시킬 수있는 MySQL의 설정이 있습니까?

내 my.cnf파일은 다음과 같습니다.

log-slow-queries="/var/log/mysql/slow-query.log"
long_query_time=1 
log-queries-not-using-indexes

innodb_buffer_pool_size=4G
innodb_log_buffer_size=4M
innodb_flush_log_at_trx_commit=2
innodb_thread_concurrency=8
innodb_flush_method=O_DIRECT

query_cache_size = 6G
key_buffer_size = 284M
query_cache_limit = 1024M
thread_cache_size = 128
table_cache = 12800

sort_buffer_size=2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M

read_buffer_size=128K

open_files_limit               = 1000
table_definition_cache         = 1024
table_open_cache               = 6000

max_heap_table_size=512M
tmp_table_size=4096M

max_connections=1000

thread_concurrency = 24

하드웨어 설정은 다음과 같습니다.

델 R710
RAID10
48G RAM

이 하드웨어가 주어지면 문제가 하드웨어 병목 현상이 될 것으로 기대하지 않습니다.

mysql innodb

— Ronn0
소스

객관적인 데이터를 제공 할 수 있습니까? 로그, 테스트 / 벤치마킹 방법론 및 결과 등이 그런가?

— womble

어떤 종류의 로그를 보시겠습니까? 내가 왜 그렇게 오래 걸 렸는지 볼 유일한 것은 de mtop 입니다. 테이블을 myisam 테이블, 더 높은 메모리 제한, 더 높은 스레드로 변경하는 것을 테스트했습니다.

— Ronn0

mysql을 개선하는 가장 좋은 설정은 ... 포스트 그레스로 전환하는 것입니다 롤

— 안토니 깁스

thread_concurrency (24)는 효과가 없습니다 = ... 당신은 라인 덤프 할 수

— 안토니 깁스

답변:

관찰 # 1

내 눈길을 끄는 첫 번째 것은 테이블 구조입니다

CREATE TABLE IF NOT EXISTS `productsCategories` (
  `categoriesId` int(11) NOT NULL,
  `productsId` int(11) NOT NULL,
  PRIMARY KEY (`categoriesId`,`productsId`),
  KEY `categoriesId` (`categoriesId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

통지를하시기 바랍니다 categoriesId인덱스와 PRIMARY KEY는 동일한 열로 시작합니다. 중복 인덱스입니다. 이 테이블은 InnoDB이므로 categoriesId인덱스는 다른 이유로 중복됩니다. 모든 보조 인덱스에는 gen_clust_index에 대한 키가 포함됩니다 (일명 Clustered Index; mysql에서 gen_clust_index는 무엇을 참조하십시오 ).

categoriesId색인 을 제거하면

ALTER TABLE productsCategories DROP INDEX categoriesId;

이 경우 보조 및 클러스터형 인덱스 유지 관리를 추가로 수행 할 필요가 없으므로 INSERT가 크게 향상됩니다 .

관찰 # 2

대량 삽입 작업을 수행하는 경우 큰 대량 삽입 버퍼 가 필요합니다 .

이것에 대한 내 과거 게시물을 참조하십시오 :

관찰 # 3

로그 파일 크기가 너무 작습니다! InnoDB 버퍼 풀의 25 % 여야하며,이 경우 1G 여야합니다. InnoDB 로그 파일 크기를 조정하는 방법에 대한 내 게시물을 참조하십시오 .

관찰 # 4

innodb_thread_concurrency를 설정하지 마십시오! 나는 Percona Live NYC에서 직접 그 환경을 떠나는 것을 배웠다 . MySQL 5.5, MySQL 5.1 InnoDB 플러그인 및 Percona Server 5.1 이상에서는 기본적으로 비활성화되어 있습니다.

관찰 # 5

innodb_file_per_table을 사용해야합니다. 이것이 비활성화되면 ibdata1의 파일 유지 관리를 악몽으로 만듭니다. 이를 구현하기 위해 InnoDB를 정리하는 방법에 대한 내 게시물을 읽으십시오 .

관찰 # 6

MySQL 5.5 또는 Percona Server를 사용하는 경우 InnoDB가 다중 CPU / 다중 코어를 사용하도록 특정 옵션을 설정해야합니다. 해당 설정에 대한 내 게시물을 참조하십시오 .

관찰 # 7

당신은 있습니다 innodb_log_buffer_size=4M. 기본값은 8M입니다. 이로 인해 리두 로그가 두 배로 플러시됩니다. 그것은 또한 당신의 innodb_flush_log_at_trx_commit=2설정을 방해 할 것 입니다. 32M으로 설정하십시오. 또한 innodb_log_buffer_size의 MySQL 설명서 를 참조하십시오 .

이러한 관찰에 비추어 다음 설정을 추가하거나 교체하십시오.

[mysqld]
innodb_thread_concurrency = 0
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_io_capacity = 5000
innodb_file_per_table
innodb_log_file_size=1G
innodb_log_buffer_size=1G
bulk_insert_buffer_size = 256M

— RolandoMySQLDBA
소스

와우 고마워! 나는 모든 포인트를 인쇄하고 지금 작업하고 다른 사람들을 돕기 위해 두뇌에 저장했습니다. 많은 감사합니다!

— Ronn0

query_cache_size또한 엄청나 다. 모든 삽입물을 비우려면 최대 6GB의 캐시가 필요합니다.

— Aaron Brown

@AaronBrown 동의합니다. 고성능 MySQL 책에서 InnoDB는 쿼리 캐시의 InnoDB 테이블에서 트랜잭션 ID를 사용하여 지루한 작업을 수행하므로 쿼리 캐시를 사용하는 데 느리게 말할 필요도 없습니다. 실제로 MySQL 4.1에는 InnoDB에 대해 쿼리 캐시가 비활성화되어 있습니다.

— RolandoMySQLDBA

쿼리 캐시가 스토리지 엔진과 완전히 분리되어 있다고 생각합니다. 기본적으로 모든 작업을 수행하고 쿼리 캐시를 스캔하여 쿼리가 무효화되도록하여 모든 쓰기 작업을 직렬화합니다. 유스 케이스를 찾지 못했으며 항상 문제가 발생했습니다.

— Aaron Brown

한 가지 더 추가해야 할 것은 query_cache_size = 6G <-이것은 완전히 터무니없는 것입니다. 쿼리 캐시는 종종 더 잘 비활성화되며 32M 또는 64M보다 커서는 안됩니다. 6G 쿼리 캐시를 유지 관리하는 오버 헤드는 확실히 성능을 저하시킵니다.

— Gavin Towey

당신은 확인해야합니다 innodb_log_file_size기본 설정은 쓰기 집약적 설정에 대한 매우 낮은 5M입니다. 100M으로 설정하십시오. ib_logfile*새로운 설정으로 DB를 시작하려면 이전 파일 을 삭제해야합니다 . DB 서버가 실행되는 동안 로그 파일을 삭제하지 마십시오. 먼저 로그 파일을 중지해야합니다. 아마도 오래된 로그 파일을 삭제하는 것이 아니라 먼저 백업해야합니다.

— 알렉스
소스