답변:
여기 몇 가지 문제가 있습니다
다음은 MyISAM 키 캐시 및 InnoDB 버퍼 풀에 적합한 크기를 선택하는 방법에 대해 이전에 작성하고 게시 한 쿼리 입니다.
FULLTEXT 인덱스가있는 MyISAM 테이블을 찾으려면이 쿼리를 실행하십시오.
select tbl.table_schema,tbl.table_name from
(
select table_schema,table_name
from information_schema.tables
where engine='MyISAM'
and table_schema NOT IN ('information_schema','mysql')
) tbl
INNER JOIN
(
select table_schema,table_name
from information_schema.statistics
where index_type='FULLTEXT'
) ndx
USING (table_schema,table_name);
이 쿼리에서 나온 것은 MySQL 5.6으로 업그레이드 할 때까지 InnoDB로 변환 할 수 없습니다.
가장 큰 문제는 innodb가 거래되는 것입니다. 당신은 당신의 어플리케이션이 기본적으로 auto_commit에 의해 사용되는 MySQL 라이브러리를 알고 싶을 것이다.
예를 들어 Python 은 자동 커밋하지 않습니다. 즉, 응용 프로그램이 연결을 닫기 직전에 행을 삽입하는 경우 innodb로 변경하면 해당 삽입이 롤백됩니다. 예를 들어 파이썬 스크립트는 반드시 connection.commit ()을 호출해야합니다.
또 다른 차이점은 다중 행 삽입 또는 업데이트와 관련이있을 수 있습니다. 단일 다중 행 삽입자를 고려하십시오.
insert into tbl values (...row1...), (...row2...), (...rowN....);row3에서 고유 한 키 충돌과 같은 오류가 발생하면 어떻게되는지 고려하십시오. MyISAM을 사용하면 처음 두 행이 쓰여졌을 것이고, innodb에서 모든 행이 롤백되어 오류가 발생하더라도 아무 것도 기록되지 않았습니다.
innodb를 사용하면 교착 상태의 세계에 들어갑니다. 작업이 수행되는 것을 막기 위해 이러한 빈도로 발생하지 않는 한 본질적으로 나쁘지 않습니다. 그러나 응용 프로그램은 교착 상태를 예상하고 적절하게 처리하는 방식으로 코딩해야합니다 (대부분의 경우 재시도).
메모리 / 스토리지 제한을 고려하십시오. Innodb는 MyISAM보다 훨씬 많은 리소스를 사용합니다. 버퍼 풀을 모든 테이블을 수용 할 수있을만큼 크게 유지할 수있는 충분한 RAM이 있다면 황금색입니다.
기본 키가 큰 테이블을 찾으십시오. Innodb의 클러스터형 인덱싱은 각 보조 인덱스가 해당 행 PK의 다른 사본을 보유 함을 의미합니다. 2 개의 보조 인덱스가있는 경우 각 행 PK가 3 번 저장됩니다 (PK + 각 인덱스). pk가 여러 열 및 큰 데이터 유형 (예 : char (N))에 걸쳐 있으면 innodb에서 인덱스 요구 사항이 어떻게 빠르게 폭발하는지 확인할 수 있습니다.