다른 스레드 ( MyISAM 대 InnoDB ) 에서 논의되는 사용의 장점 / 단점에도 불구하고 마이그레이션은 사소한 프로세스입니다.
중히 여기다
- 가능한 경우 데이터베이스와 통신하는 모든 구성 요소를 기능적으로 테스트-차이 엔진은 다른 의미를 가짐
- 가능한 한 많은 성능 테스트를 실행하십시오. 일부는 개선 될 수 있고 다른 것은 훨씬 더 나빠질 수 있습니다. 잘 알려진 예는 대형 테이블의 SELECT COUNT (*)입니다.
- 모든 코드가 교착 상태를 정상적으로 처리하는지 확인합니다. 트랜잭션을 명시 적으로 사용하지 않고도 교착 상태를 얻을 수 있습니다.
- 변환을 통해 얻을 수있는 공간 사용량을 예상하고 비 프로덕션 환경에서 테스트하십시오.
의심 할 여지없이 대규모 소프트웨어 플랫폼에서 변경해야 할 필요가 있습니다. 괜찮습니다.하지만 자동 테스트 범위가 많으면 변경이 허용됩니다.
추신 : "뭔가 CPU에 부담을주기 시작했다"면 a) 비 프로덕션 환경에서 무엇을 찾아야하는지 b) 비 프로덕션 환경에서이를 줄이기위한 다양한 옵션을 시도해야합니다. 문제를 완전히 분석하지 않은 상태에서 데이터베이스 엔진 변경과 같은 주요 작업을 맹목적으로 시작해서는 안됩니다.
모든 성능 테스트는 프로덕션 수준의 하드웨어와 프로덕션 수준의 데이터를 사용하여 프로덕션이 아닌 환경에서 수행해야합니다. 그렇지 않으면 결과를 올바르게 해석하기가 어렵습니다.
-------------------다른 잠재적 인 마이그레이션 문제와 관련하여 :
1) 공간-InnoDB 테이블에는 종종 더 많은 디스크 공간이 필요하지만 InnoDB의 새 버전에 대한 Barracuda 파일 형식은 차이를 좁혔습니다. 테이블의 최근 백업을 변환하고 크기를 비교하여 이에 대한 감각을 얻을 수 있습니다. 데이터 길이를 비교하려면 "show table status"를 사용하십시오.
2) 전체 텍스트 검색-MyISAM에서만
3) GIS / 공간 데이터 유형-MyISAM에서만
성능면에서 다른 답변과 참조 된 답변에서 알 수 있듯이 작업량에 따라 다릅니다. MyISAM은 전체 테이블 스캔의 경우 훨씬 빠릅니다. InnoDB는 동시 액세스가 많은 경우 훨씬 더 빠른 경향이 있습니다. InnoDB는 조회가 기본 키를 기반으로하는 경우 훨씬 더 빠를 수도 있습니다.
또 다른 성능 문제는 MyISAM이 테이블 수준 잠금 만 수행하기 때문에 항상 행 수를 유지할 수 있다는 것입니다. 따라서 매우 큰 테이블의 행 수를 자주 가져 오려고하는 경우 InnoDB를 사용하면 훨씬 느려질 수 있습니다. 몇 가지 제안을 보았 듯이 이에 대한 해결 방법이 필요하면 인터넷을 검색하십시오.
테이블의 크기에 따라 MySQL 구성 파일을 업데이트해야 할 수도 있습니다. 최소한 key_buffer에서 innodb_buffer_pool_size로 바이트를 이동할 수 있습니다. 데이터베이스를 MyISAM에 최적화 된 상태로두면 공정한 비교를 할 수 없습니다. 모든 innodb_ * 구성 속성을 읽어보십시오.
-------------------InnoDB로 전환하면 성능이 향상 될 수 있다고 생각하지만 제 경험으로는 시도 할 때까지 확신 할 수 없습니다. 내가 당신이라면 동일한 서버에 테스트 환경을 설정하고 InnoDB로 변환하고 벤치 마크를 실행합니다.
-------------------내 경험에 비추어 볼 때 MyISAM 테이블은 큰 텍스트를 검색 할 때 좋은 성능이 필요한 텍스트 인덱싱에만 유용하지만 여전히 Solr 또는 ElasticSearch와 같은 완전한 검색 엔진은 필요하지 않습니다.
InnoDB로 전환하고 싶지만 MyISAM 테이블에서 텍스트를 계속 인덱싱하려면 http://blog.lavoie.sl/2013/05/converting-myisam-to-innodb-를 살펴 보시기 바랍니다. keep-fulltext.html
또한 : InnoDB는 Percona의 innobackupex를 사용하여 라이브 원자 백업을 지원합니다. 이것은 프로덕션 서버를 다룰 때 신이 주신 것입니다.
출처
https://stackoverflow.com/questions/2006053