MyISAM 구조

MySQL의 옛 기본 스토리지 엔진(storage engine)이다. 트랜잭션(transaction)을 지원하지 않는다. 현재 신규 OLTP(Online Transaction Processing, 온라인 트랜잭션 처리) 설계에서 선택할 이유는 드물다. 키 캐시(key cache)·힙 저장(heap storage)·테이블 락(table lock) 세 가지로 InnoDB와의 차이를 이해한다.

구조 세 줄

• 키 캐시: 인덱스 블록만 담는 전용 메모리 캐시다. 데이터는 OS가 최근 읽은 파일 내용을 메모리에 남겨 두는 OS 파일 캐시에 맡긴다. 데이터와 인덱스를 한곳에 캐시하는 InnoDB 버퍼 풀(buffer pool)과 대비된다.
• 힙 저장(heap storage): 행을 빈 곳에 순서 없이 쌓고, 인덱스가 행 위치를 직접 가리킨다. 행을 PK(Primary Key, 기본 키) 순서로 저장하는 클러스터링 방식이 아니라서 PK 조회도 두 단계다. 먼저 인덱스에서 행 위치를 찾고, 그 위치로 가서 행을 읽는다.
• 테이블 락: 읽을 때는 여럿이 함께 걸 수 있는 공유 락(shared lock)을, 쓸 때는 혼자만 거는 배타 락(exclusive lock)을 테이블 단위로 건다. 쓰기 하나가 테이블 전체를 막으니 쓰기 동시성은 포기한 구조다.

파일은 테이블당 3개다. 테이블 정의를 담은 .sdi, 데이터 .MYD, 인덱스 .MYI다. 8.0부터 정의 파일이 .sdi로 바뀌었다.

현재 위치 — 레거시 호환

• COUNT(*)를 즉시 반환한다. 테이블의 전체 행 수를 메타데이터에 따로 들고 있기 때문이다.
• 기존 MyISAM 테이블의 호환·이관·복구 작업에 쓴다.
• 전문 검색(full-text search)의 레거시로 남아 있다. 전문 검색용 FULLTEXT 인덱스는 긴 글 속 단어로 검색하게 해 주는 인덱스인데, 현재 InnoDB도 지원하므로 신규 선택 근거로는 약하다.

COUNT(*)가 빠르다는 이유만으로 신규 테이블에 채택하면 잃는 대가가 훨씬 크다. 트랜잭션, 행 단위 잠금, 크래시 복구(crash recovery)를 모두 포기해야 한다. "왜 아직 있나"에 대한 답은 주로 하위 호환이다.

면접 포인트

• "MyISAM의 특징 세 가지?" → 트랜잭션 없음·테이블 락·힙 저장.
• "키 캐시와 버퍼 풀의 차이?" → 인덱스만 vs 데이터+인덱스. 데이터 캐시를 OS에 맡긴다는 점.
• "COUNT(*)가 왜 빨라요?" → 전체 행 수를 저장하고 있어서. 단 WHERE가 붙으면 소용없다.