개요이번 글에서는 우테코에서 진행한 투룻 프로젝트를 통해 쿼리 개선을 경험한 내용을 공유하고자 합니다. 프로젝트에서 쿼리 성능을 개선하기 위해 GROUP BY와 JOIN의 순서를 재설계하고, NL(Nested Loop) JOIN의 드라이빙 테이블 크기를 줄이는 작업을 수행했습니다. 이 과정을 통해 쿼리 성능을 최대 264배 개선할 수 있었습니다. 이 글에서는 정렬 시 인덱스를 활용하는 것이 중요하지만, 드라이빙 테이블의 크기가 쿼리 성능에 미치는 영향이 더 클 수 있다는 사실을 다룹니다. 또한 커버링 인덱스를 활용하여 추가적인 성능 개선을 이룬 경험도 함께 다룰 예정입니다.투룻 서비스 소개투룻은 여행기 서비스로, 여행기에 달려있는 태그 기반으로 여행기 목록을 조회하는 기능이 있었습니다. 이 때 여행기 목..

동시성 문제(데드락) 해결기 - X 락인데 왜 공유가 가능하지?????? 동시성 문제(데드락) 해결기 - X 락인데 왜 공유가 가능하지??????이번 글에서는 팀 프로젝트에서 겪은 동시성 문제와 MySQL의 락을 사용하다가 경험한 데드락에 관해 이야기합니다. 특히 갭 락은 X 락이더라도 공유가 가능하므로 데드락이 발생할 수 있다는 사nakhonest.tistory.com 이전 글에서는 동시성 문제를 INSERT IGNORE를 사용해 해결한 경험을 공유했습니다. INSERT IGNORE 는 unique 인덱스가 설정된 상황에서 중복된 unique 키로 삽입을 시도할 경우, 에러를 발생시키지 않고 해당 삽입을 무시합니다. 하지만 매번 INSERT 쿼리를 실행하면 성능이 저하가 우려되어 이를 테스트를 하는 도..

이번 글에서는 팀 프로젝트에서 겪은 동시성 문제와 MySQL의 락을 사용하다가 경험한 데드락에 관해 이야기합니다. 특히 갭 락은 X 락이더라도 공유가 가능하므로 데드락이 발생할 수 있다는 사실을 강조합니다.이 과정에서 MySQL의 락 메커니즘을 깊이 있게 다룹니다. 그리고 이 문제를 락을 사용하지 않고 어떻게 해결했는지 공유합니다.이 글을 통해 MySQL의 락 메커니즘을 이해하고 락을 사용할 때 발생할 수 있는 데드락의 원인을 파악할 수 있습니다. MySQL의 락을 더욱 안전하게 활용하는 데 도움이 되기를 바랍니다. 문제 발생 상황팀에서 여행기 장소를 조회하고 저장하는 기능을 개발하던 중, 여러 사용자가 동시에 장소를 저장할 때 중복된 장소가 저장되는 문제를 겪었습니다.문제 설명 전 알아둘 프로젝트의 사..