2017-10-06 24 views
0

AWS RDS (버전 5.6.34)가있는 MySQL 서버가 있습니다. 우리는 MyISAM 테이블을 독점적으로 사용합니다. IO 처리량을 높이기 위해 key_block_size를 변경하려고했습니다. 그러나 두 가지 예기치 않은 결과가있었습니다.key_block_size가 설정된 MyISAM 테이블

1> 색인 레벨 (예 : 8192)에서 key_block_size가 설정되면 실행이 완료되면 테이블이 InnoDB로 전환되며 이는 내가 원하는 것이 아닙니다. MyISAM으로 다시 테이블을 변경하려면 인덱스를 삭제해야합니다.

2> key_block_size를 테이블 수준 (예 : 16384)으로 설정하면 색인을 작성하는 데 오랜 시간이 걸립니다. 테이블이 key_block_size가 설정되지 않은 상태로 남아있는 경우보다 시간이 오래 걸립니다.

어떤 일이 일어 났을 까와 그 이유는 무엇입니까? 내가 그 값으로해야할까요? MyISAM 테이블에 대해 key_block_size?

아무쪼록 고맙습니다.

+1

현재 수행중인 작업이 명확하지 않습니다. 1)는 테이블을 InnoDB로 변경해서는 안된다 (사실, InnoDB는 인덱스 당'key_block_size '를 지원하지 않는다). 2) 어떤 인덱스가 더 오래 걸리는지는 명확하지 않다 : 새로운 인덱스 또는 기존 인덱스? 테이블 설정을 변경하면 전체 테이블을 다시 작성해야하므로 단일 인덱스를 추가하는 것보다 시간이 오래 걸립니다. 그래서 좀 더 구체적으로 할 수 있습니다 : (또는 오히려 : 작은 샘플)'create table' 문, 실행 한 명령 및 결과'show create table'을 추가하십시오. 일반적으로 성능을 향상시키는 체크리스트에서'key_block_size'는 142 번 항목입니다. 이미 1-141 번 했습니까? – Solarflare

+0

MyISAM은 곧 죽을 것입니다. 나는 누구도 key_block_size를 성공적으로 변경하는 것에 대해 들어 본 적이 없다. 아무런 지원도 없습니다. –

+0

@Solarflare, AWS RDS에서 다음 문을 실행하면 MyISAM 테이블이 InnoDB 테이블로 변환됩니다. CREATE TABLE'test_tbl1' ( 'row_id' int (11) NOT NULL DEFAULT '0', 'row_detail' int (11) NOT NULL DEFAULT '0', KEY'idx' ('row_id') ) ENGINE = MyISAM DEFAULT CHARSET = latin1; ALTER TABLE'test_tbl1' DROP INDEX'idx', ADI 고유 인덱스 'idx2'사용 BTREE ('row_id' ASC) KEY_BLOCK_SIZE = 8192; – TonyS

답변

0

기본 키 블록 크기는 1K입니다. OS는 4K를 좋아합니다. 색인 액세스가 임의로이면 작을수록 좋습니다. 인덱스에서 범위 스캔을 수행하면 더 큰 것이 좋습니다.

key_buffer_size을 너무 크게 만드는 것은 데이터의 캐싱을 제거합니다. 인덱스를 너무 작게 만들면 인덱스에 대한 I/O가 증가합니다. 실수로이 잔액에 팁을 주었습니까?

ENGINE이 자동으로 변경되었다는 말을 들어 본 적이 없습니다. 자세한 내용을 입력하십시오. Comments의 테스트 케이스는 Percona의 5.6.22-71.0-log에 대한 MyISAM 테이블로 돌아오고 KEY_BLOCK_SIZE=8192을 유지했습니다. (나는 AWS를 시도하지 않았다.) SHOW VARIABLES LIKE '%engine%'; Hmmm ... Percona 5.7.10-1의 변경 사항 : 이 활성화되었을 때 (ENGINE= 절없이) 스토리지 엔진을 지정하지 않고 ALTER TABLE을 실행하거나 OPTIMIZE TABLE을 실행 함 요청되지 않은 예상치 못한 스토리지 엔진 변경을 초래할 수 있습니다. 시스템 테이블에 대해 수행하면 시스템 테이블 저장소 엔진의 일반적인 호환성 검사를 우회하여 충돌 또는 서버 작동이 중단 될 수 있습니다. "# 버그 1488055 수정."

MyISAM이 "key_buffer"대신 "sorting"을 통해 인덱스를 재 작성하는 까다로운 방법이 있습니다. (SHOW PROCESSLIST은 어떤 일을하는지 보여줍니다.) ("reparing"이라고합니다.) "Sorting"은 보통 훨씬 빠르며 key_buffer를 피합니다.

delay_key_write의 값을 확인하십시오.

MyISAM에서 PRIMARY KEY은 다른 색인으로 간주됩니다. 내가 InnoDB, 그것은 데이터와 클러스터되어 있으므로 Index_length에 나타나지 않습니다.

최적화 및 I/O 팁이 많이 있습니다. 그러나 그들은 튜닝보다 쿼리에 더 의존합니다. 쿼리 EXPLAIN SELECT ..., RAM 크기 및 SHOW CREATE TABLE을 입력하십시오. 또한 SHOW VARIABLES LIKE '%buffer%';을 보자.

더 많은 비평을 원할 경우 SHOW VARIABLES;SHOW GLOBAL STATUS;을 제공하십시오.

웹 로그 분석 - 아마도 "요약표"가 어떻게 될까요? 때로는 성능이 10 배 향상됩니다.

Analytics - 클러스터 된 PK를 통해 스캔 할 수있는 경우, 별도의 인덱스와 데이터 사이를 오가야 만하는 MyISAM보다 InnoDB에서 성능이 좋아집니다. 그리고/또는 별도의 정렬 패스를 만들어야합니다.

오라클은 사실상 모든 상황에서 MyISAM보다 더 나은 것으로 선언하기 위해 InnoDB를 계속 개선해 왔습니다. 나머지 결함 : 디스크 공간; where없이 count (*); 2 부분 PK. (분석을 보지 않고도 InnoDB가 실제로 더 빨리 수행 될지 여부는 알 수 없습니다.)