조용한 개발 노트

1편에서 트랜잭션이 왜 본질적으로 느릴 수밖에 없는지, Undo Log와 Redo Log의 비용 관점에서 살펴봤다.이쯤에서 자연스럽게 이런 의문이 든다.“그런데 읽기 트랜잭션은 왜 락 없이도 동작할 수 있을까?”이 질문에 대한 답이 바로 MVCC(Multi-Version Concurrency Control)다.MVCC가 등장한 이유전통적인 락 기반 동시성 제어에서는 읽기와 쓰기가 서로를 쉽게 막는다.읽는 동안 쓰기가 대기한다쓰는 동안 읽기가 대기한다동시 사용자가 늘어날수록, 처리량은 급격히 떨어진다.InnoDB는 이 문제를 해결하기 위해 “락을 덜 거는 방법”이 아니라 과거 버전을 읽게 하는 방법을 선택했다.그 결과물이 MVCC다.MVCC의 핵심 아이디어MVCC의 핵심은 단순하다.“읽을 때 현재 값을 보..

백엔드 개발을 하다 보면 이런 순간을 만나게 된다.“로직은 단순한데, 트랜잭션을 걸자마자 성능이 확 떨어졌다.”이때 보통 다음부터 의심한다.쿼리가 느린가?인덱스가 부족한가?락이 걸렸나?하지만 이 질문들은 모두 결과를 보고 추측하는 단계다. 트랜잭션이 느린 이유는 그보다 훨씬 앞단에 있다.이 글에서는 MySQL(InnoDB) 공식 문서를 기준으로, 트랜잭션이 왜 본질적으로 비용이 드는 작업인지를 내부 구조 관점에서 정리한다.트랜잭션을 시작한다는 것은 무슨 의미일까애플리케이션 코드에서 트랜잭션은 보통 이렇게 보인다.@Transactional 하나, 또는 BEGIN / COMMIT.하지만 InnoDB 입장에서 트랜잭션을 시작한다는 것은 단순한 모드 전환이 아니다.내부적으로 다음 준비 작업이 동시에 시작된다.일..