@Transactional의 readOnly 속성의 의미

@Transactional 어노테이션은 readOnly 속성을 갖고 있다.

• 기본값 : false
• true 로 설정하면 → "이 트랜잭션은 읽기만 하고 쓰지 않는다"는 의미 (= 읽기 전용)

단순히 쓰기를 금지하는 것을 넘어, 여러 계층에서 성능 최적화 효과를 얻을 수 있다.

---

1. JPA / Hibernate 레벨

JPA를 사용할 때 효과가 가장 크다. 핵심은 Dirty Checking 생략이다.

평소 동작 (readOnly = false)

JPA는 엔티티를 조회할 때 "스냅샷"을 함께 저장해둔다. 트랜잭션이 끝나는 시점에 현재 엔티티와 스냅샷을 비교해, 변경된 필드가 있다면 UPDATE 쿼리를 실행한다.

readOnly = true일 때

• 스냅샷 자체를 만들지 않는다 → 메모리 절약
• 변경 감지(Dirty Checking) 로직을 건너뛴다 → CPU 절약
• Flush^[각주:1]를 수행하지 않는다

💡 대량 조회 시 차이가 크다. 예를 들어 1만 건을 조회하면, 기본 설정에서는 1만 개의 스냅샷이 메모리에 쌓인다.

---

2. DB 드라이버 / 커넥션 레벨

JDBC 레벨에서 Connection.setReadOnly(true)가 호출된다. 이는 DB에게 "이 커넥션은 읽기 전용"이라는 힌트를 전달하는 역할이며, DB는 이 힌트를 바탕으로 내부 최적화를 수행할 수 있다.

예시: MySQL InnoDB

InnoDB는 readOnly 힌트를 받으면 트랜잭션 ID(TRX ID)를 할당하지 않는다.

구분	일반 트랜잭션	읽기 전용 트랜잭션
TRX ID 발급	O	X
언두 로그[각주:2] 기록	O	X
MVCC 관리 대상	O	X

이런 오버헤드를 생략하므로 성능이 향상된다.

---

3. Read Replica 라우팅

Master-Slave 구조에서, 읽기 전용 트랜잭션을 Slave(Replica)로 라우팅하는 전략을 구현할 수 있다. Master의 부하를 줄이고 읽기 처리량을 분산시킬 수 있다.

1. 변경 사항을 실제 DB로 내보내는 작업. [본문으로]
2. 트랜잭션이 데이터를 변경하기 이전 상태를 저장해두는 로그. 롤백과 MVCC(다른 트랜잭션이 커밋 전 데이터를 락 없이 이전 버전으로 읽는 기능)에 사용된다. [본문으로]