InnoDB와 MyISAM의 주요 차이점은 무엇입니까?
InnoDB와 MyISAM의 주요 차이점은 무엇입니까?
답변:
가장 큰 차이점은 InnoDB는 행 수준 잠금을 구현하는 반면 MyISAM은 테이블 수준 잠금 만 수행 할 수 있다는 것입니다. InnoDB에서 더 나은 응급 복구를 찾을 수 있습니다. 그러나 FULLTEXT
MyISAM과 마찬가지로 v5.6까지는 검색 색인 이 없습니다 . InnoDB는 또한 트랜잭션, 외래 키 및 관계 제약 조건을 구현하지만 MyISAM은 구현하지 않습니다.
목록은 조금 더 나아갈 수 있습니다. 그러나 둘 다 서로 유리한 점과 단점이있는 독특한 장점이 있습니다. 각각은 다른 시나리오보다 일부 시나리오에서 더 적합합니다.
요약하면 ( TL; DR ) :
FULLTEXT
검색 인덱스가 있으며 InnoDB는 MySQL 5.6 (2013 년 2 월)까지 지원하지 않았습니다.아직 언급되지 않은 또 다른 주요 차이점은 각 스토리지 엔진에 대한 캐싱이 수행되는 방식입니다.
사용되는 주요 메커니즘은 키 캐시입니다. .MYI 파일의 색인 페이지 만 캐시합니다. 키 캐시의 크기를 조정하려면 다음 쿼리를 실행하십시오.
SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.4999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1))
recommended_key_buffer_size FROM
(SELECT LEAST(POWER(2,32),KBS1) KBS
FROM (SELECT SUM(index_length) KBS1
FROM information_schema.tables
WHERE engine='MyISAM' AND
table_schema NOT IN ('information_schema','mysql')) AA ) A,
(SELECT 2 PowerOf1024) B;
현재 데이터 세트에 따라 MyISAM 키 캐시 ( key_buffer_size )에 대한 권장 설정이 제공 됩니다 ( 쿼리는 4G (4096M)에서 권장 사항을 제한합니다. 32 비트 OS의 경우 4GB가 제한됩니다. 64 비트, 8GB의 경우.
사용되는 주요 메커니즘은 InnoDB 버퍼 풀입니다. 액세스 된 InnoDB 테이블에서 데이터 및 인덱스 페이지를 캐시합니다. InnoDB 버퍼 풀의 크기를 조정하려면 다음 쿼리를 실행하십시오.
SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.49999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1)) recommended_innodb_buffer_pool_size
FROM (SELECT SUM(data_length+index_length) KBS FROM information_schema.tables
WHERE engine='InnoDB') A,
(SELECT 2 PowerOf1024) B;
현재 데이터 세트가 제공된 InnoDB 버퍼 풀 ( innodb_buffer_pool_size ) 크기에 대한 권장 설정을 제공합니다.
InnoDB 로그 파일 (ib_logfile0 및 ib_logfile1)의 크기를 조정하는 것을 잊지 마십시오. MySQL 소스 코드는 모든 InnoDB 로그 파일의 크기가 4G (4096M) 미만이어야합니다. 간단하게하기 위해 두 개의 로그 파일 만 제공하면 다음과 같이 크기를 조정할 수 있습니다.
service mysql stop
rm /var/log/mysql/ib_logfile[01]
service mysql start
(ib_logfile0 및 ib_logfile1이 다시 작성 됨)두 쿼리의 끝에는 인라인 쿼리
(SELECT 2 PowerOf1024)
B가 있습니다.
(SELECT 0 PowerOf1024)
바이트 단위로 설정을 제공합니다(SELECT 1 PowerOf1024)
킬로바이트 단위로 설정(SELECT 2 PowerOf1024)
메가 바이트 단위로 설정을 제공합니다(SELECT 3 PowerOf1024)
기가 바이트 단위로 설정상식을 대신 할 수있는 것은 없습니다. 제한된 메모리, 스토리지 엔진 혼합 또는 이들의 조합이있는 경우 다른 시나리오에 맞게 조정해야합니다.
가능한 시나리오는 끝이 없습니다!
할당 한 내용에 관계없이 DB 연결 및 운영 체제에 충분한 RAM을 남겨 두십시오.
InnoDB는 다음을 제공합니다.
InnoDB에서 TEXT 및 BLOB를 제외한 행의 모든 데이터는 최대 8,000 바이트를 차지할 수 있습니다. MySQL 5.6 (2013 년 2 월)까지 InnoDB에서 전체 텍스트 인덱싱을 사용할 수 없습니다. 이노에서, COUNT(*)
S는 (시 WHERE
, GROUP BY
또는 JOIN
사용하지 않는)를 로우 카운트가 내부에 저장되어 있지 않으므로의 MyISAM보다 느리게 실행한다. InnoDB는 데이터와 인덱스를 모두 하나의 파일에 저장합니다. InnoDB는 버퍼 풀을 사용하여 데이터와 인덱스를 모두 캐시합니다.
MyISAM은 다음을 제공합니다.
COUNT(*)
S (시 WHERE
, GROUP BY
또는 JOIN
사용하지 않음)MyISAM에는 테이블 수준 잠금이 있지만 행 수준 잠금은 없습니다. 거래가 없습니다. 자동 응급 복구는 없지만 복구 테이블 기능을 제공합니다. 외래 키 제약 조건이 없습니다. MyISAM 테이블은 일반적으로 InnoDB 테이블과 비교할 때 디스크 크기가 더 작습니다. 필요한 경우 myisampack으로 압축하여 MyISAM 테이블의 크기를 크게 줄일 수 있지만 읽기 전용이됩니다. MyISAM은 한 파일에 인덱스를 저장하고 다른 파일에 데이터를 저장합니다. MyISAM은 인덱스 캐싱에 키 버퍼를 사용하고 데이터 캐싱 관리를 운영 체제에 맡깁니다.
전반적으로 나는 대부분의 목적으로 InnoDB를 권장하고 특수 용도로만 MyISAM을 권장합니다. InnoDB는 이제 새로운 MySQL 버전의 기본 엔진입니다.
한 가지 더 : 파일 시스템의 스냅 샷을 작성하여 InnoDB 테이블을 백업 할 수 있습니다. MyISAM을 백업하려면 mysqldump를 사용해야하며 일관성이 보장되지 않습니다 (예 : 부모 테이블과 자식 테이블에 삽입하는 경우 백업에서 자식 테이블의 행만 찾을 수 있음).
기본적으로 다른 데이터 사본이 있고 PHP 웹 사이트에서 데이터에 액세스하는 표준 수단을 허용하기 위해 MySQL에서만 캐시하는 경우 MyISAM은 괜찮습니다 (예 : 플랫 CSV 파일 또는 쿼리 로그 파일보다 낫습니다. 동시 액세스). 데이터베이스가 데이터의 실제 "마스터 사본"인 경우 사용자의 실제 데이터를 수행 INSERT
하고 UPDATE
사용 하는 경우 InnoDB 이외의 다른 것을 사용하는 것은 어리석은 일입니다. MyISAM은 신뢰할 수없고 관리하기 어렵습니다. '이 일을 할 것이다 myisamchk
어떤 성능 향상을 부정, 시간을 반 ...
(개인 경험 : MyISAM의 2 테라 바이트 DB).
게임에 조금 늦었지만 ... 여기 에 몇 달 전에 쓴 MYISAM과 InnoDB의 주요 차이점을 자세하게 설명한 포괄적 인 게시물이 있습니다. 컵파 (아마도 비스킷)를 잡고 즐기십시오.
MyISAM과 InnoDB의 주요 차이점은 참조 무결성과 트랜잭션에 있습니다. 잠금, 롤백 및 전체 텍스트 검색과 같은 다른 차이점도 있습니다.
참조 무결성은 테이블 간의 관계가 일관되게 유지되도록합니다. 보다 구체적으로 말하면, 테이블 (예 : 리스팅)에 다른 테이블 (예 : 제품)을 가리키는 외래 키 (예 : 제품 ID)가 있고, 지정된 테이블에 대한 업데이트 또는 삭제가 발생하면 이러한 변경 사항이 연결에 연결됩니다. 표. 이 예에서 제품 이름이 바뀌면 연결 테이블의 외래 키도 업데이트됩니다. '제품'테이블에서 제품을 삭제하면 삭제 된 항목을 가리키는 모든 목록도 삭제됩니다. 또한 새 목록에는 유효한 기존 항목을 가리키는 외래 키가 있어야합니다.
InnoDB는 관계형 DBMS (RDBMS)이므로 참조 무결성이 있지만 MyISAM은 그렇지 않습니다.
테이블의 데이터는 SELECT, INSERT, UPDATE 및 DELETE와 같은 DML (Data Manipulation Language) 문을 사용하여 관리됩니다. 트랜잭션 그룹은 둘 이상의 DML 문을 단일 작업 단위로 함께 묶으므로 전체 단위가 적용되거나 적용되지 않습니다.
MyISAM은 트랜잭션을 지원하지 않지만 InnoDB는 지원합니다.
MyISAM 테이블을 사용하는 동안 작업이 중단되면 작업이 즉시 중단되고 작업이 완료되지 않은 경우에도 영향을받는 행 (또는 각 행 내의 데이터)이 영향을받습니다.
원 자성이있는 트랜잭션을 사용하기 때문에 InnoDB 테이블을 사용하는 동안 작업이 중단되면 커밋이 수행되지 않으므로 완료되지 않은 트랜잭션은 적용되지 않습니다.
MyISAM 테이블에 대해 쿼리를 실행하면 쿼리하는 전체 테이블이 잠 깁니다. 이는 후속 쿼리가 현재 쿼리가 완료된 후에 만 실행됨을 의미합니다. 큰 테이블을 읽거나 읽기 및 쓰기 작업이 자주 발생하는 경우 쿼리에 대한 백 로그가 엄청날 수 있습니다.
InnoDB 테이블에 대해 쿼리를 실행할 때 관련된 행만 잠기고 나머지 테이블은 CRUD 작업에 사용할 수 있습니다. 이는 동일한 행을 사용하지 않는 한 동일한 테이블에서 쿼리를 동시에 실행할 수 있음을 의미합니다.
InnoDB의이 기능은 동시성이라고합니다. 동시성이있는 한, 엄선 된 테이블 범위에 적용되는 주요 단점이 있습니다. 커널 스레드간에 전환하는 데 오버 헤드가 있으므로 서버가 중지되지 않도록 커널 스레드에 제한을 설정해야합니다. .
MyISAM에서 작업을 실행하면 변경 사항이 설정됩니다. InnoDB에서는 이러한 변경 사항을 롤백 할 수 있습니다. 트랜잭션을 제어하는 데 사용되는 가장 일반적인 명령은 COMMIT, ROLLBACK 및 SAVEPOINT입니다. 1. COMMIT-여러 DML 작업을 작성할 수 있지만 COMMIT가 수행 될 때만 변경 사항이 저장됩니다. 2. ROLLBACK-아직 커밋되지 않은 작업은 모두 버릴 수 있습니다. 3. SAVEPOINT-목록에서 포인트를 설정합니다. ROLLBACK 조작이 롤백 할 수있는 조작
MyISAM은 데이터 무결성을 제공하지 않습니다. 하드웨어 오류, 부정한 종료 및 취소 된 작업으로 인해 데이터가 손상 될 수 있습니다. 인덱스와 테이블을 완전히 복구하거나 다시 작성해야합니다.
반면 InnoDB는 트랜잭션 로그, 이중 쓰기 버퍼 및 자동 체크섬 및 유효성 검사를 사용하여 손상을 방지합니다. InnoDB는 변경하기 전에 트랜잭션 이전의 데이터를 ibdata1이라는 시스템 테이블 스페이스 파일에 기록합니다. 충돌이 발생하면 InnoDB는 해당 로그 재생을 통해 자동 복구합니다.
InnoDB는 MySQL 버전 5.6.4까지 FULLTEXT 인덱싱을 지원하지 않습니다. 이 글을 쓰는 현재 많은 공유 호스팅 제공 업체의 MySQL 버전이 여전히 5.6.4 미만이므로 InnoDB 테이블에 대해 FULLTEXT 인덱싱이 지원되지 않습니다.
그러나 이것이 MyISAM을 사용하는 유효한 이유는 아닙니다. 최신 버전의 MySQL을 지원하는 호스팅 제공 업체로 변경하는 것이 가장 좋습니다. FULLTEXT 인덱싱을 사용하는 MyISAM 테이블을 InnoDB 테이블로 변환 할 수있는 것은 아닙니다.
결론적으로 InnoDB는 기본 스토리지 엔진으로 선택해야합니다. 특정 요구에 맞는 MyISAM 또는 기타 데이터 유형을 선택하십시오.
내 경험상 가장 중요한 차이점은 각 엔진이 잠금을 처리하는 방식입니다. InnoDB는 행 잠금을 사용하는 반면 MyISAM은 테이블 잠금을 사용합니다. 경험상, 나는 무거운 테이블을 쓰기 위해 InnoDB를 사용하고 무거운 테이블을 읽기 위해 MyISAM을 사용합니다.
다른 중요한 차이점은 다음과 같습니다.
FULLTEXT
와 SPATIAL
. InnoDB는 읽기 및 쓰기가 많은로드 모두에 적합 합니다.
MyISAM을 MySQL의 '기본'테이블 선택으로 보는 경향이 있으므로 대부분의 InnoDB 사용자에 대한 차이점을 지적하겠습니다.
MySQL 5.6 변경 사항 포함
이노 DB 스토리지 엔진 :
따라서 MyISAM
이미 5.6으로 업그레이드 한 경우에는 엔진 을 사용할 필요가 없습니다. 그렇지 않은 경우 MySQL 5.6으로 업그레이드하기를 기다리지 마십시오.
MyISAM은 MySQL 용 스토리지 엔진입니다. MySQL 5.5 이전에는 MySQL의 기본 스토리지 엔진이었습니다. 이전 ISAM 스토리지 엔진을 기반으로합니다. MyISAM은 읽기 작업이 많고 쓰기가 적거나 전혀없는 환경에 최적화되어 있습니다. MyISAM이 빠른 읽기를 허용하는 이유는 인덱스의 구조입니다. 각 항목은 데이터 파일의 레코드를 가리키고 포인터는 파일의 시작 부분에서 오프셋됩니다. 이런 식으로 레코드를 빠르게 읽을 수 있습니다. 특히 형식이 FIXED 인 경우입니다. 따라서 행의 길이는 일정합니다. MyISAM을 선호 할 수있는 일반적인 영역은 매우 큰 테이블에 대한 쿼리를 포함하기 때문에 데이터웨어 하우스입니다. 이러한 테이블의 업데이트는 데이터베이스를 사용하지 않을 때 (일반적으로 야간) 수행됩니다. 새로운 행이 데이터 파일의 끝에 추가되므로 삽입도 쉽습니다. 하나, 삭제 및 업데이트 작업이 더 문제가됩니다. 삭제는 빈 공간을 두어야합니다. 그렇지 않으면 행의 오프셋이 변경됩니다. 행 길이가 짧아짐에 따라 업데이트도 마찬가지입니다. 업데이트로 인해 행이 길어지면 행이 조각화됩니다. 행을 조각 모음하고 빈 공간을 요구하려면OPTIMIZE TABLE
명령을 실행해야합니다. 이 간단한 메커니즘으로 인해 일반적으로 MyISAM 인덱스 통계는 매우 정확합니다. MyISAM의 다른 주요 단점은 거래 지원 및 외래 키가 없다는 것입니다.
InnoDB는 MySQL 용 스토리지 엔진입니다. MySQL 5.5 이상에서는 기본적으로 사용합니다. 외래 키 지원 (Declarative Referential Integrity)과 함께 표준 ACID 호환 트랜잭션 기능을 제공합니다. FULLTEXT
OpenGIS 표준에 따라 SQL 및 XA 트랜잭션, 테이블 스페이스, 인덱스 및 공간 작업을 모두 구현합니다 . MySQL AB에 의해 배포되는 대부분의 바이너리에는 표준으로 포함되어 있지만 일부 OEM 버전은 예외입니다. 소프트웨어는 Oracle Corporation에 의해 이중 라이센스가 부여됩니다. GNU 일반 공중 사용 허가서에 따라 배포되지만 InnoDB를 독점 소프트웨어와 결합하려는 당사자에게도 사용 허가를받을 수 있습니다.
MariaDB에는 "MyISAM에 대한 충돌 안전 대안"이라고하는 Aria라는 스토리지 엔진이 있습니다. MariaDB와 Percona Server는 기본적으로 XtraDB라는 InnoDB 포크를 사용합니다. XtraDB는 Percona가 관리합니다. Oracle InnoDB의 변경 사항을 정기적으로 XtraDB로 가져오고 일부 버그 수정 및 추가 기능이 추가되었습니다.