InnoDB와 MyISAM의 주요 차이점은 무엇입니까?


245

InnoDB와 MyISAM의 주요 차이점은 무엇입니까?


23
데이터베이스 엔진을 원하면 InnoDB를 사용하십시오. 두 개를 비교할 수 없습니다 .
Jeremy Stein

아래의 많은 답변이 맞지만 IMHO는 명확하게 정리하지 않습니다. 이 사이트 의 주요 요점 : InnoDB는 행 수준 잠금이고 MyISAM은 테이블 수준 잠금입니다. 즉, 일반적으로 MyISAM은 OLAP (분석, 대부분 읽기)에 더 좋고 InnoDB는 OLTP (트랜잭션, 대부분 쓰기 또는 적어도 많은 쓰기)에 더 좋습니다.
Mike Williamson

답변:


159

가장 큰 차이점은 InnoDB는 행 수준 잠금을 구현하는 반면 MyISAM은 테이블 수준 잠금 만 수행 할 수 있다는 것입니다. InnoDB에서 더 나은 응급 복구를 찾을 수 있습니다. 그러나 FULLTEXTMyISAM과 마찬가지로 v5.6까지는 검색 색인 이 없습니다 . InnoDB는 또한 트랜잭션, 외래 키 및 관계 제약 조건을 구현하지만 MyISAM은 구현하지 않습니다.

목록은 조금 더 나아갈 수 있습니다. 그러나 둘 다 서로 유리한 점과 단점이있는 독특한 장점이 있습니다. 각각은 다른 시나리오보다 일부 시나리오에서 더 적합합니다.

요약하면 ( TL; DR ) :

  • InnoDB에는 행 수준 잠금 기능이 있으며 MyISAM은 전체 테이블 수준 잠금 기능 만 수행 할 수 있습니다.
  • InnoDB는 응급 복구 기능이 향상되었습니다.
  • MyISAM에는 FULLTEXT검색 인덱스가 있으며 InnoDB는 MySQL 5.6 (2013 년 2 월)까지 지원하지 않았습니다.
  • InnoDB는 트랜잭션, 외래 키 및 관계 제약 조건을 구현하지만 MyISAM은 구현하지 않습니다.

친애하는 각하, 그래서 궁극적으로 무엇을 사용할 것인가? MyISAM 또는 InnoDB? 완전히 혼란 스럽습니다 ... 내 웹 사이트가 mysql을 사용하고 있으며 이것을 결정해야합니다.
sqlchild

3
응용 프로그램에 따라 필요한 기능 (예 : 전체 텍스트 검색, 외래 키 ...)이 포함 된 목록을 작성하고 하나를 결정 해보십시오 (각 기능을 평가 한 다음 점수 계산). 당신은 그들 모두를 가질 수 없지만 마녀 기능이 가장 필요하다고 결정하는 것은 당신에게 달려 있습니다.
poelinca

2
설명을 위해 그의 게시물을 편집했습니다.
Mathias Lykkegaard Lorenzen

1
@MathiasLykkegaardLorenzen 감사합니다, 그것이 우리가 stackexchange를 좋아하는 이유 중 하나입니다
poelinca

현재의 version 5.6.4이노 지원 FULLTEXT검색합니다. dev.mysql.com/doc/refman/5.6/en/fulltext-restrictions.html
daydreamer

85

아직 언급되지 않은 또 다른 주요 차이점은 각 스토리지 엔진에 대한 캐싱이 수행되는 방식입니다.

MYISAM

사용되는 주요 메커니즘은 키 캐시입니다. .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 테이블에서 데이터 및 인덱스 페이지를 캐시합니다. 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) 미만이어야합니다. 간단하게하기 위해 두 개의 로그 파일 만 제공하면 다음과 같이 크기를 조정할 수 있습니다.

  • 1 단계) innodb_log_file_size = NNN을 /etc/my.cnf에 추가하십시오 (NNN은 innodb_buffer_pool_size의 25 % 또는 2047M 중 작은 값이어야 함)
  • 2 단계) service mysql stop
  • 3 단계) rm /var/log/mysql/ib_logfile[01]
  • 4 단계) service mysql start(ib_logfile0 및 ib_logfile1이 다시 작성 됨)

경고

두 쿼리의 끝에는 인라인 쿼리 (SELECT 2 PowerOf1024)B가 있습니다.

  • (SELECT 0 PowerOf1024) 바이트 단위로 설정을 제공합니다
  • (SELECT 1 PowerOf1024) 킬로바이트 단위로 설정
  • (SELECT 2 PowerOf1024) 메가 바이트 단위로 설정을 제공합니다
  • (SELECT 3 PowerOf1024) 기가 바이트 단위로 설정
  • 0보다 작거나 3보다 큰 거듭 제곱은 허용되지 않습니다

발문

상식을 대신 할 수있는 것은 없습니다. 제한된 메모리, 스토리지 엔진 혼합 또는 이들의 조합이있는 경우 다른 시나리오에 맞게 조정해야합니다.

  • 2GB RAM과 16GB InnoDB가있는 경우 512M을 innodb_buffer_pool로 할당하십시오.
  • RAM이 2GB이고 MyISAM 인덱스가 4GB 인 경우 512M을 key_buffer_size로 할당하십시오.
  • 2GB RAM, 4GB MyISAM 인덱스 및 16GB InnoDB가있는 경우 512M을 key_buffer_size로, 512M을 innodb_buffer_pool_size로 할당하십시오.

가능한 시나리오는 끝이 없습니다!

할당 한 내용에 관계없이 DB 연결 및 운영 체제에 충분한 RAM을 남겨 두십시오.


그것들은 나쁜 공식입니다!
Rick James

(죄송합니다-단락을 가질 수 없다는 것을 잊지 마십시오) ... "답변"을 추가하겠습니다.
Rick James

캐시 크기에 대한 롤란도의 공식은 실용적이지 않습니다. -2의 거듭 제곱이 필요하지 않습니다. -32 비트 OS에서 4GB는 불가능합니다.- etc . 다음은이를 설정하는 방법에 대한 설명입니다 : mysql.rjweb.org/doc.php/memory (메모리 사용에 영향을 미치는 다양한 다른 설정을 다룹니다.)
Rick James

2
@Rick : 2의 거듭 제곱은 답을 다른 단위로 표시하기위한 것입니다. Doing (SELECT 2 PowerOfTwo) 응답 표시를 MB 단위로 설정합니다. Doing (SELECT 3 PowerOfTwo) 디스플레이를 GB 단위로 설정합니다. (SELECT 1 PowerOfTwo) KB로 표시합니다. (SELECT 0 PowerOfTwo) 바이트로 표시합니다. 이것이 (SELECT 2 PowerOfTwo)의 기능입니다. 따라서 아키텍처에 가정 된 값을 강요하지 않고 표시 만해야합니다.
RolandoMySQLDBA 2016 년

2
@Rick : 그거 알아? 두 가지 큰 이유로 실제로 +1을 줄 것입니다. 1) 귀하의 URL은 4GB가 key_buffer_size에 할당하는 가장 큰 숫자라는 점에서 제 답변이 정확하다는 것을 확인합니다. 2) 귀하의 답변은 귀하의 URL과 함께 컴퓨터의 메모리가 매우 적습니다. 크레딧이 필요한 곳에서 크레딧을드립니다.
RolandoMySQLDBA 2016 년

60

InnoDB는 다음을 제공합니다.

  • ACID 거래
  • 행 수준 잠금
  • 외래 키 제약
  • 자동 충돌 복구
  • 테이블 압축 (읽기 / 쓰기)
  • 공간 데이터 유형 (공간 인덱스 없음)

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사용하지 않음)
  • 전체 텍스트 인덱싱 (업데이트 : MySQL 5.6의 InnoDB에서 지원)
  • 더 작은 디스크 공간
  • 매우 높은 테이블 압축 (읽기 전용)
  • 공간 데이터 유형 및 인덱스 (R- 트리) (업데이트 : MySQL 5.7의 InnoDB에서 지원됨)

MyISAM에는 테이블 수준 잠금이 있지만 행 수준 잠금은 없습니다. 거래가 없습니다. 자동 응급 복구는 없지만 복구 테이블 기능을 제공합니다. 외래 키 제약 조건이 없습니다. MyISAM 테이블은 일반적으로 InnoDB 테이블과 비교할 때 디스크 크기가 더 작습니다. 필요한 경우 myisampack으로 압축하여 MyISAM 테이블의 크기를 크게 줄일 수 있지만 읽기 전용이됩니다. MyISAM은 한 파일에 인덱스를 저장하고 다른 파일에 데이터를 저장합니다. MyISAM은 인덱스 캐싱에 키 버퍼를 사용하고 데이터 캐싱 관리를 운영 체제에 맡깁니다.

전반적으로 나는 대부분의 목적으로 InnoDB를 권장하고 특수 용도로만 MyISAM을 권장합니다. InnoDB는 이제 새로운 MySQL 버전의 기본 엔진입니다.


5
나는 당신의 대답을 읽고 이미 여기에있는 다른 사람들과 비교했습니다. BLOB에 대해 언급 한 것은 귀하뿐입니다. 그들은 보통 당연한 것으로 여겨집니다. Mysampack을 언급 한 유일한 사람은 빠르게 읽을 수있는 MyISAM 테이블의 이름없는 영웅 중 하나입니다. 당신은 오늘 +1입니다 !!!
RolandoMySQLDBA 3

2
예를 들어 테이블을 완전히 교체하여 자주 업데이트되지 않는 압축 된 읽기 전용 테이블이 있습니다.
dabest1

30

한 가지 더 : 파일 시스템의 스냅 샷을 작성하여 InnoDB 테이블을 백업 할 수 있습니다. MyISAM을 백업하려면 mysqldump를 사용해야하며 일관성이 보장되지 않습니다 (예 : 부모 테이블과 자식 테이블에 삽입하는 경우 백업에서 자식 테이블의 행만 찾을 수 있음).

기본적으로 다른 데이터 사본이 있고 PHP 웹 사이트에서 데이터에 액세스하는 표준 수단을 허용하기 위해 MySQL에서만 캐시하는 경우 MyISAM은 괜찮습니다 (예 : 플랫 CSV 파일 또는 쿼리 로그 파일보다 낫습니다. 동시 액세스). 데이터베이스가 데이터의 실제 "마스터 사본"인 경우 사용자의 실제 데이터를 수행 INSERT하고 UPDATE사용 하는 경우 InnoDB 이외의 다른 것을 사용하는 것은 어리석은 일입니다. MyISAM은 신뢰할 수없고 관리하기 어렵습니다. '이 일을 할 것이다 myisamchk어떤 성능 향상을 부정, 시간을 반 ...

(개인 경험 : MyISAM의 2 테라 바이트 DB).


29

게임에 조금 늦었지만 ... 여기 에 몇 달 전에 쓴 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 또는 기타 데이터 유형을 선택하십시오.


1
정말 유익하고 명확한 요약 감사합니다.
informatik01

18

내 경험상 가장 중요한 차이점은 각 엔진이 잠금을 처리하는 방식입니다. InnoDB는 행 잠금을 사용하는 반면 MyISAM은 테이블 잠금을 사용합니다. 경험상, 나는 무거운 테이블을 쓰기 위해 InnoDB를 사용하고 무거운 테이블을 읽기 위해 MyISAM을 사용합니다.

다른 중요한 차이점은 다음과 같습니다.

  1. InnoDB는 트랜잭션 및 외래 키를 지원합니다. MyISAM은 그렇지 않습니다.
  2. MyISAM은 전체 텍스트 인덱싱을 사용합니다.
  3. MyISAM은 데이터 무결성을 강화하는 열악한 작업을 수행합니다.

날짜 중 - InnoDB는 지금 가지고 FULLTEXTSPATIAL. InnoDB는 읽기 및 쓰기가 많은로드 모두에 적합 합니다.
Rick James

8

MyISAM을 MySQL의 '기본'테이블 선택으로 보는 경향이 있으므로 대부분의 InnoDB 사용자에 대한 차이점을 지적하겠습니다.

  • 행 레벨 잠금
  • 외래 키 집행
  • 거래 지원
  • 사용량이 많은 시스템에서 성능 저하

5
최신 MySQL 릴리스를 제외하고는 더 이상 MyISAM을 기본 엔진으로 사용하지 않습니다. 5.5에서는 기본값을 InnoDB :)로 변경했습니다. 그리고 나는 InnoDB가 일반적으로 '성능 히트'를 얻는다는 일반화에 동의하지 않습니다. 적절한 인덱싱과 메모리 설정을 갖춘 잘 설계된 InnoDB 테이블은 MyISAM에서 동일한 스키마뿐만 아니라 InnoDB 테이블의 성능을 향상시킬 수 있습니다
TechieGurl

3
많은 "고용도"상황에서 InnoDB는 실제로 MyISAM보다 성능뛰어납니다 . MyISAM은 특정 문제에 대한 특정 도구이며 InnoDB는 대부분의 상황에서 더 나은 서비스를 제공합니다 (따라서 MySQL 팀이 기본 엔진으로 만든 이유). MySQL 커뮤니티가 InnoDB가 성숙한 후에도 기본적으로 MyISAM을 사용하는 습관으로 성장한 이유는 MyISAM이 오랫동안 유일한 엔진 이었기 때문입니다.
Nick Chammas 2009 년

2
MySQL 5.6 개발주기에 InnoDB에 대한 전체 텍스트 검색이 추가되었습니다. 인용 된 URL 은 이제 InnoDB에도 적용됩니다.
Max Webster

5

MYISAM

MYISAM은 테이블 레벨 잠금, FULLTEXT 검색을 제공합니다. MYISAM은 모든 스토리지 엔진에서 가장 유연한 AUTO_INCREMENTED 컬럼 처리 기능을 제공합니다. MYISAM은 거래를 지원하지 않습니다.

이노 DB

INNODB는 거래 안전 스토리지 엔진입니다. INNODB에는 commit, rollback 및 crash-recovery 기능이 있습니다. INNODB는 외래 키 참조 무결성을 지원합니다.


5

MySQL 5.6 변경 사항 포함

이노 DB 스토리지 엔진 :

  • 완전한 ACID (원 자성, 일관성, 격리, 내구성) 준수를 제공합니다. 다중 버전 관리는 트랜잭션을 서로 분리하는 데 사용됩니다.
  • InnoDB는 MySQL 서버 또는 서버가 실행되는 호스트의 충돌 후 자동 복구를 제공합니다.
  • InnoDB는 계단식 삭제 및 업데이트를 포함하여 외래 키 및 참조 무결성을 지원합니다.
  • MySQL 5.6은 기본 스토리지 엔진으로 완전히 통합 된 InnoDB 플랫폼에 구축
  • Persistent Optimizer Stats : InnoDB 인덱스 통계의 정확성과 MySQL 재시작에 대한 일관성을 제공합니다.
  • InnoDB 테이블 캐시 정리 : 테이블 수가 많은 시스템에서 메모리로드를 쉽게하기 위해 InnoDB는 이제 열린 테이블과 연관된 메모리를 비 웁니다. LRU 알고리즘은 액세스하지 않고 가장 긴 테이블을 선택합니다.
  • 전체 텍스트 검색 지원 : 특수한 종류의 인덱스 인 FULLTEXT 인덱스는 InnoDB가 텍스트 기반 열 및 포함 된 단어를 포함하는 쿼리 및 DML 작업을 처리하는 데 도움을줍니다. 이러한 인덱스는 물리적으로 전체 InnoDB 테이블로 표시됩니다.
  • InnoDB는 MyISAM보다 전체 텍스트 검색에서 더 빠릅니다.

따라서 MyISAM이미 5.6으로 업그레이드 한 경우에는 엔진 을 사용할 필요가 없습니다. 그렇지 않은 경우 MySQL 5.6으로 업그레이드하기를 기다리지 마십시오.

MySQL 5.6을 사용한 InnoDB VS MyISAM 성능


2

MyISAM

MyISAM은 MySQL 용 스토리지 엔진입니다. MySQL 5.5 이전에는 MySQL의 기본 스토리지 엔진이었습니다. 이전 ISAM 스토리지 엔진을 기반으로합니다. MyISAM은 읽기 작업이 많고 쓰기가 적거나 전혀없는 환경에 최적화되어 있습니다. MyISAM이 빠른 읽기를 허용하는 이유는 인덱스의 구조입니다. 각 항목은 데이터 파일의 레코드를 가리키고 포인터는 파일의 시작 부분에서 오프셋됩니다. 이런 식으로 레코드를 빠르게 읽을 수 있습니다. 특히 형식이 FIXED 인 경우입니다. 따라서 행의 길이는 일정합니다. MyISAM을 선호 할 수있는 일반적인 영역은 매우 큰 테이블에 대한 쿼리를 포함하기 때문에 데이터웨어 하우스입니다. 이러한 테이블의 업데이트는 데이터베이스를 사용하지 않을 때 (일반적으로 야간) 수행됩니다. 새로운 행이 데이터 파일의 끝에 추가되므로 삽입도 쉽습니다. 하나, 삭제 및 업데이트 작업이 더 문제가됩니다. 삭제는 빈 공간을 두어야합니다. 그렇지 않으면 행의 오프셋이 변경됩니다. 행 길이가 짧아짐에 따라 업데이트도 마찬가지입니다. 업데이트로 인해 행이 길어지면 행이 조각화됩니다. 행을 조각 모음하고 빈 공간을 요구하려면OPTIMIZE TABLE명령을 실행해야합니다. 이 간단한 메커니즘으로 인해 일반적으로 MyISAM 인덱스 통계는 매우 정확합니다. MyISAM의 다른 주요 단점은 거래 지원 및 외래 키가 없다는 것입니다.

InnoDB

InnoDB는 MySQL 용 스토리지 엔진입니다. MySQL 5.5 이상에서는 기본적으로 사용합니다. 외래 키 지원 (Declarative Referential Integrity)과 함께 표준 ACID 호환 트랜잭션 기능을 제공합니다. FULLTEXTOpenGIS 표준에 따라 SQL 및 XA 트랜잭션, 테이블 스페이스, 인덱스 및 공간 작업을 모두 구현합니다 . MySQL AB에 의해 배포되는 대부분의 바이너리에는 표준으로 포함되어 있지만 일부 OEM 버전은 예외입니다. 소프트웨어는 Oracle Corporation에 의해 이중 라이센스가 부여됩니다. GNU 일반 공중 사용 허가서에 따라 배포되지만 InnoDB를 독점 소프트웨어와 결합하려는 당사자에게도 사용 허가를받을 수 있습니다.

포크

MariaDB에는 "MyISAM에 대한 충돌 안전 대안"이라고하는 Aria라는 스토리지 엔진이 있습니다. MariaDB와 Percona Server는 기본적으로 XtraDB라는 InnoDB 포크를 사용합니다. XtraDB는 Percona가 관리합니다. Oracle InnoDB의 변경 사항을 정기적으로 XtraDB로 가져오고 일부 버그 수정 및 추가 기능이 추가되었습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.