2021.09.15 기록장

ToDo

• 알고리즘 문제 풀기
• 책 읽기
•  

Done

• 책 읽기

Weekly goal

• 책 읽기

real mysql

 

169p.

자동 증가 락

mySQL에는 auto_increment 속성이 있다. 키 값을 자동으로 증가시켜 주는데

이를 위해 락을 건다.

5.0 버전 이하에서는 insert마다 락을 걸었지만 5.1 버전에서부터는 시스템 변수로 조정이 가능하다.

insert가 몰릴 때 예측이 가능한 양이면 락을 잠깐만 걸고 index값을 예측하여 반환할 수 있다.

근데 insert... select 구조일 경우에는 select시의 변경량을 보장해야 하므로 이때는 락이 끝날 때까지 걸린다.

 

172p.

인덱스 락

innoDB는 레코드 락을 지원하는데 이는 레코드를 잠그는 것이 아니라 인덱스를 잠그는 방식으로 처리된다.

즉 변경해야 할 레코드를 찾기 위해 검색한 인덱스의 레코드를 모두 락을 걸어야 한다.

예로 

update emp set creat_date = now() where first_name = 'dom' and last_name='bom';

만약 테이블에 first name에 인덱스가 걸려 있으면 first는 인덱스를 타지만 last_name은 bom을 위해 last_name 레코드를 모두 잠가야 한다.

이는 성능 저하로 이어질 수 있다.

 

179p.

격리 수준을 살펴보자.

read_uncommitted는 다른 트랜젝션이 변경한 값을 읽을 수 있다. 이로 인해 dirty read 가 발생할 수 있다.

다른 트랜젝션이 변경한 값을 읽었는데 만약 롤백이 되면 읽은 트랜잭션은 정합성이 깨진다.

read_committed는 커밋된 이후의 정보를 읽을 수 있다. 

하지만 이도 한 트랜잭션 안에서 각기 다른 시간에 select를 2번 하면 데이터 정합성이 깨지는 문제가 발생한다.

이를 non-repeatable Read 문제라 한다.

Repeatable read 격리 수준은  innoDB에서 기본으로 사용하는 격리 수준이다.

Repeatable read는 MVCC(multi version concurrency control) 방법을 이용한다.

커밋되면 변경 전의 값을 언두 로그에 버전별로 관리를 해서 하나의 트랜젝션 안에서는 동일한 값을 보장하는 것이다.

innoDB에서는 트랜잭션마다 고유한 번호가 배정이 된다. 

MVCC도 버전 관리를 할 때 이 번호를 사용한다. 트랜잭션 중에 가장 오래된 트랜잭션 번호보다 트랜잭션 번호가 앞선 언두 영역의 데이터는 삭제할 수 없다.

 

여태 다른 트랜잭션의 값을 읽어 발생하는 문제 dirty read와 커밋되어 2번의 select가 다른 버전의 레코드를 가져오는 non-repeatable read 문제를 피할 수 있다,

하지만 repeatable read 격리 수준도 같은 트랜잭션 안에서 다른 시점에 count쿼리를 날리게 된다면, 마침 그 사이에 다른 트랜잭션이 insert 했다면 처음 select보다 하나 증가된 값을 가져올 것이다.

이를 phantom read라고 한다. 

 

하지만 innoDB에서는 갭 락과 넥스트 키 락 덕분에 repeatable read 수준에서도 phantom read가 발생하지 않는다.

 

갭 락은 레코드와 레코드 사이를 잠근다. 그 사이에 새로운 레코드가 insert 되는 것을 방지한다.

 

196p.

mysql 8.0부터는 데이터에 대한 것뿐 아니라 리두나 언두, 바이너리 로그에 까지 암호화를 적용시킨다.

이는 innoDB가 디스크에서 read wirte 할 때만 암호화, 복호화가 진행된다.