Ikjo's Technology blog

Non-Repeatable Read 는 언제 문제가 되는가? MySQL 의 InnoDB 스토리지 엔진에서 기본으로 사용되는 트랜잭션 격리수준은 Repeatable Read 이다. 이때 Repeatable Read 에서는 다른 트랜잭션 격리수준인 Read Uncommitted 나 Read Committed 에서와 달리 Non-Repeatable Read 현상이 발생하지 않는다. 여기서 Non-Repeatable Read 란 하나의 트랜잭션에서 같은 값을 두 번 select 했을 때 각각 다른 값이 읽히는 현상이다. 참고로 ANSI SQL 1992 에서는 Non-Repeatable Read 현상을 아래와 같이 서술하고있다. 하나의 예시로서 아래와 같은 시나리오들이 존재할 수 있다. 참고로 트랜잭션 A 의 경..

실행 시간이 1시간 이상 소요되는 악성 SQL... 오늘은 실무 초기에 SQL 을 작성하면서 실수했었던 부분에 대해 다루고자 한다. 🐥 실무에서 데이터 마이그레이션을 위해 Update 쿼리를 작성해본 경험이 있었는데, 테스트 환경에서 실행해본 결과 실행 시간이 무려 1시간을 훌쩍 넘긴 일이 있었다...👀 뭔가 잘못됐음을 직감하고 일단 SQL 실행계획부터 확인해보기로 했다. SQL 의 형태는 대략 아래와 같은 구조였다. (참고로, 이름은 임의로 명명했다.) UPDATE a_table a JOIN b_table b ON CAST(a.index_id AS CHAR) = CAST(b.id AS CHAR) JOIN c_table c ds ON b.c_id = c.id SET a.text = ... WHERE a...

트랜잭션 격리수준 Serializable, 왜 사용할까? 온보딩 당시 비지니스 로직을 살펴 보는 중 서비스 레이어 계층에서 스프링이 제공하는 트랜잭션 AOP 기능을 적용 시 트랜잭션 격리수준이 Serializable 로 설정 되어있는 것을 확인할 수 있었다. 참고로, 스프링이 제공하는 트랜잭션 AOP 기능은 개발자가 별도로 트랜잭션 격리수준을 설정하지 않을 경우 데이터소스의 기본 트랜잭션 격리수준을 따르게 된다. @Target({ElementType.TYPE, ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) @Inherited @Documented public @interface Transactional { // ... /** * The transac..

발생 이슈 지난 달 다른 서비스 팀의 친한 백엔드 개발자로부터 원인을 알 수 없는 이상한(?) 현상이 나타나고 있다는 것을 전해 듣고 해당 팀에 가서 어떤 이상한 현상인지 보러갔다. 해당 이슈는 동일한 조회 쿼리를 사용했음에도 불구하고 로컬 환경에서는 데이터 정렬이 정상적으로 처리되어 조회되는데, 개발 서버 환경에서는 데이터 정렬이 비정상적으로 처리되어 조회된다는 것이었다. 👀 쿼리 분석 우선, 그 조회 쿼리가 무엇인지 살펴보았다. 해당 쿼리의 형태는 대략적으로 다음과 같았다. WITH temp_a_tbable AS ( SELECT ... FROM a_table WHERE deleted_at IS NULL ), temp_b_table AS ( SELECT ... FROM b_table WHERE dele..