예전에도 이와 같은 고민을 한적이 있다. 당시에는 지금보다 더 짧은 지식으로 '아니 김영한님은 자연키 말고 대리키 써라하고 책에서는 가능하면 성능을 위해서 비즈니스적으로 의미있는 걸로 PK 잡으라하고 어떻게 해야하지?'라고 생각했다.
하지만 이번 책에서 Auto-Increment의 장단점에 대해 나와서 시원했다.
해당 텍스트
SELECT보다는 INSERT에 최적화된 테이블을 생성하기 위해서는 다음 두 가지를 지키면 된다.
단조 증가 또는 감소 값으로 프라이머리 키 선정
세컨더리 인덱스 최소
`자동 증가 값을 프라이머리 키로 해서 테이블을 생성하는 것은 MySQL 서버에서 가장 빠른 INSERT를 보장하는 방법이다. 세컨더리 인덱스가 하나도 없는 테이블이라면 더 좋다.
테이블에 INSERT 되는 레코드가 프라이머리 키의 전체 범위에 대해 프라미어리 키 순서와 무관하게 아주 랜덤하게 저장된다면 MySQL 서버는 레코드를 INSERT할때마다 저장될 위치를 찾아야 한다. 즉 프라이머리키의 B-Tree 전체가 메모리에 적재돼 있어야 빠른 insert를 보장할 수 있는데, 테이블의 크기가 클 수록 더 많은 메모리가 필요해진다. 일반적으로 메모리 크기는 유한하므로 디스크 읽기가 필요해진다 (디스크 읽기는 느리다)
InnoDB 스토리지 엔진을 사용하는 테이블의 프라이머리 키는 클러스터링 키인데, 이는 세컨더리 인덱스를 이용하는 쿼리보다 프라이머리 키를 이용하는 쿼리의 성능이 훨씬 빨라지는 효과를 낸다.
일반적으로 로그를 저장하는 테이블이 이런 류에 속하고, 상품이나 주문, 사용자 정보와 같이 중요 정보를 가진 테이블들은 쓰기에 비해 읽기 비율이 높은 경우가 많다.
주제
Auto-Increment 써야하나 말아야하나
선정 이유
예전에도 이와 같은 고민을 한적이 있다. 당시에는 지금보다 더 짧은 지식으로 '아니 김영한님은 자연키 말고 대리키 써라하고 책에서는 가능하면 성능을 위해서 비즈니스적으로 의미있는 걸로 PK 잡으라하고 어떻게 해야하지?'라고 생각했다.
하지만 이번 책에서 Auto-Increment의 장단점에 대해 나와서 시원했다.
해당 텍스트
SELECT보다는 INSERT에 최적화된 테이블을 생성하기 위해서는 다음 두 가지를 지키면 된다.
`자동 증가 값을 프라이머리 키로 해서 테이블을 생성하는 것은 MySQL 서버에서 가장 빠른 INSERT를 보장하는 방법이다. 세컨더리 인덱스가 하나도 없는 테이블이라면 더 좋다.
테이블에 INSERT 되는 레코드가 프라이머리 키의 전체 범위에 대해 프라미어리 키 순서와 무관하게 아주 랜덤하게 저장된다면 MySQL 서버는 레코드를 INSERT할때마다 저장될 위치를 찾아야 한다. 즉 프라이머리키의 B-Tree 전체가 메모리에 적재돼 있어야 빠른 insert를 보장할 수 있는데, 테이블의 크기가 클 수록 더 많은 메모리가 필요해진다. 일반적으로 메모리 크기는 유한하므로 디스크 읽기가 필요해진다 (디스크 읽기는 느리다)
InnoDB 스토리지 엔진을 사용하는 테이블의 프라이머리 키는 클러스터링 키인데, 이는 세컨더리 인덱스를 이용하는 쿼리보다 프라이머리 키를 이용하는 쿼리의 성능이 훨씬 빨라지는 효과를 낸다.
일반적으로 로그를 저장하는 테이블이 이런 류에 속하고, 상품이나 주문, 사용자 정보와 같이 중요 정보를 가진 테이블들은 쓰기에 비해 읽기 비율이 높은 경우가 많다.
관련 페이지
p.156, 7