index7 존재하지 않은 데이터에 대한 잠금의 영향 들어가며이전 글에서 삽입 연산에 대해서 발생하는 동시성 문제를 해결하기 위해서 Rediss의 분산락 또는 MySQL의 네임드락을 통해 순서를 제어한다는 글을 작성하였습니다. 하지만 이후에 비관적락에 대해 학습하다 보니, 존재하지 않은 데이터에 대해서도 잠금을 걸 수 있다는 것을 알 수 있었습니다. 그렇다면 다시 한번 삽입 과정에서 락을 통해 추가적인 구현을 할 필요성에 대해 생각해봐야 할 것 같아 글을 작성하게 되었습니다. [DB] MySQL NamedLock vs Redisson 락 관리.들어가며이전 글(https://kongdevlog.tistory.com/20)에서 Named Lock을 통해 삽입 작업에서의 동시성을 제어하였습니다.다만 이 과정에서, Redisson을 사용하는 방법이 더 좋은 방법.. 2025. 6. 15. [DB] 인덱스와 잠금 들어가며인덱스를 통해 효율적인 탐색을 하도록 하여 DB의 성능을 높이는데 기여하는 것은 매우 중요한 사실이지만, 그 외에도 인덱스를 통해 탐색을 하며 잠금을 건다는 사실 역시 생성(Insert)/수정(Delete)에도 큰 영향을 미친다는 사실을 확인하고자 글을 작성하게 되었습니다.사전 테이블과 데이터다음과 같이 약 1만개의 데이터를 삽입하였습니다. 이제 인덱스가 걸리지 않은 데이터를 잠그는 경우, 어떤 현상이 발생하는지 직접 확인해보겠습니다.실험현재 name 컬럼에는 인덱스가 존재하지 않기 때문에select * from test_table where name = 'User_7000' for update;쿼리를 실행하고, 어떤 행들에 잠금이 걸리는지 확인해보겠습니다.이와 함께 실제 PK를 확인해보니 1만개.. 2025. 6. 2. [팀 프로젝트 & DB] 쿼리 속도 개선하기. 들어가며특정 게시글 목록을 보여줄 때, 총 3개의 테이블이 조인이 되는 쿼리가 존재하였습니다. 페이지네이션 작업을 진행하면서, 혹시 데이터가 늘어나거나 조회 조건이 추가되면 성능 저하가 있지 않을까? 하는 생각에 더미 데이터를 통한 성능 측정과 이 과정에서 쿼리를 수정하거나 인덱스를 튜닝하여 속도를 개선하는 과정을 기록하고자 글을 작성하게 되었습니다.더미데이터더미데이터를 추가할 때, 이전에 글을 작성한 것과 같이 데이터의 다양성이 떨어지면 의도한 인덱스를 타지 않고 풀스캔을 해버리는 경우. 즉, 인덱스의 효용이 떨어져 DBMS가 풀스캔을 선택하게 되는 상황을 배제하고자 데이터의 분포를 고르게 하고자 하였습니다.INSERT INTO jobs(id, name, created_at) -- 직업 더미 데이터WI.. 2025. 4. 16. [DB] 인덱스 B-Tree 살펴보기! 들어가며인덱스는 어떤 자료구조로 이루어져 있나요? 라는 질문을 들으면, B-Tree 자료 구조로 이루어져 있습니다! 라고 대답할 수는 있지만, B-Tree 가 무엇이냐는 대답할 수 없을 것 같습니다... 하지만 Real MySQL 8.0 책을 읽으면서 B-Tree 가 어떤 형태로 정렬이 되어 있고, 어떤 특징이 있는지 조금은 알게 되었습니다. 따라서 이번 기회에 글을 정리하며 제대로 이해하고자 글을 작성하게 되었습니다. B-Tree 란?다수의 자식을 가질 수 있는 정렬된 균형 탐색 트리로, 데이터 삽입/삭제 시에도 트리의 균형을 유지하며 높이를 최소화하여 검색 성능을 유지하는 자료구조. GPT가 정리해준 B-Tree의 정의입니다. 여기서 B는 Binary가 아닌 Balance를 의미합니다. 그렇다면 왜.. 2025. 4. 7. [DB & 팀 프로젝트] 실행 계획을 통해 인덱스 걸어보기! 들어가며Real MySQL 8.0 1권 책을 읽으며 조회 시, 인덱스의 중요성에 대해서 새삼 느끼게 되었습니다. 따라서 현재 프로젝트에서 작성한 쿼리의 실행 계획을 확인 후, 인덱스를 설정하여 조회 성능을 개선할 수 있는 부분이 있는지 확인해보고자 글을 작성하게 되었습니다!어플리케이션 코드.OtherMemberProfileView otherMemberProfileView = queryFactory .from(member) .leftJoin(hobby).on(hobby.id.in(member.profile.hobbyIds)) .leftJoin(job).on(job.id.eq(member.profile.jobId)) .. 2025. 3. 4. [DB] 행 단위 잠금에 대한 생각 정리. 들어가며최근 Real MySQL 8.0 1권을 읽으면서, 행단위 잠금에 대해 한번 더 생각하게 되었습니다.이전 인턴 업무를 진행할 때에 상품 재고를 업데이트하는 트랜잭션을 작성할 때에도, Update 할 때 발생하는 행 잠금을 활용하여 이슈를 해결하였습니다.이때 특정 행에 대한 잠금을 획득하는 경쟁 상태가 발생할 수 있다는 것을 간과하였습니다.데드락 발생 가능 상황위의 그림을 보시면 아시겠지만, 이를 예방할 수 있는 방법이 존재하였습니다. 바로 잠금 발생의 순서를 오름차순 또는 내림차순으로 강제하는 것입니다. 그렇게 되면, 교착 상태에 빠지는 경우는 사라지게 됩니다.그렇다면 행 단위 잠금만으로 동시성 문제를 해결할 수 있을 것 같은데, 왜 분산락과 같은 기법을 사용할까..?vs 분산락.이전 프로젝트에서 .. 2025. 2. 14. 이전 1 2 다음
