MySQL InnoDB의 락

1. 들어가며원래는 다음 글에 InnoDB의 락을 정리했었습니다. https://rawshrimpsushi.tistory.com/68그런데 다른 글 주제와 함께 쓰다보니 원하는 만큼 정리하지 못하고 요약하여 정리하는 문제가 있었습니다. 당연한 얘기겠지만 MySQL의 락은 하나의 글로 정리하기 힘들 정도로 큰 내용이다보니, 위 글에서 정리한 내용과 함께 따로 글로 정리하고자 합니다.기본적인 락 개념과 MVCC에 대한 내용은 다음 글을 참조해주세요!https://rawshrimpsushi.tistory.com/38 MySQL 아키텍쳐본 내용은 real MySQL 책을 참조하여 쓰여졌습니다!  1. 기본 아키텍쳐  크게 MySQL 엔진과 스토리지 엔진으로 구분할 수 있습니다. MySQL 엔진: 1)    커넥..

• format_list_bulleted Backend/DB
• · 2025. 1. 1.
• textsms

MySQL DEAD LOCK

1. 들어가며멀티 스레드를 다룰 때 데드락을 디버깅하는 것은 쉽지 않습니다. 발생 조건을 항상 재현할 수 있는 것도 아니고, 코드가 복잡할 수록 원인 분석이 더 어려워집니다. 거기에 더해 MySQL의 데드락은, MySQL이 가진 락의 종류와 걸리는 조건이 단순하지 않기 때문에 더 골치 아픈 문제로 다가올 때가 많은 것 같습니다. https://rawshrimpsushi.tistory.com/80 MySQL InnoDB의 락1. 들어가며원래는 다음 글에 InnoDB의 락을 정리했었습니다. https://rawshrimpsushi.tistory.com/68그런데 다른 글 주제와 함께 쓰다보니 원하는 만큼 정리하지 못하고 요약하여 정리하는 문제가 있었습니rawshrimpsushi.tistory.com 이 글에..

• format_list_bulleted Backend/DB
• · 2024. 12. 28.
• textsms

MySQL의 JSON 타입 사용 시 주의사항

1. 들어가며 보통 JSON 타입하면 NoSQL, 특히 MongoDB를 많이 떠올릴 것 같습니다. 하지만 MySQL에서도 Json 타입을 제공하고 있는데요. JSON 형식의 column을 만들고, 해당 데이터를 일부만 업데이트 하거나, 심지어 json의 특정 키에 대해서 인덱스까지 만들 수 있습니다.기본적인 JSON 데이터 형식이나 저장 방법 등은 생략하고 JSON 타입을 사용할 때 주의해야될 점을 위주로 살펴보겠습니다. 2. JSON 데이터 부분 업데이트 JSON 데이터를 변경할 때 전체 데이터를 바꿀 일은 흔치 않습니다. 보통 json에는 많은 key, value가 혼재되어 있고 그 중 특정 값만 수정될 일이 많을 것입니다. 그래서 mySQL에서는 특정 키 값만 변경 시 변경된 키 값에 대해서만 데이..

• format_list_bulleted Backend/DB
• · 2024. 12. 28.
• textsms

SELECT ... FOR UPDATE - NO WAIT & SKIP LOCKED

1. 들어가며 예전 시간에 SELECT ... FOR UPDATE와 함께 MySQL의 다양한 락들에 대해 알아보았습니다. 오늘은 SELECT ... FOR UPDATE라는 무거운 친구를 다양하게 튜닝해볼 수 있는 NO WAIT와 SKIP LOCKED에 대해 알아보겠습니다. 2. SELECT ... FOR UPDATE NOWAIT정의잠금 대상 레코드가 이미 다른 세션에 의해 잠겨있는 경우, 잠금을 대기하는 것이 아니라 바로 에러를 반환하는 것을 말합니다.ERROR 3572 (HY000): Statement aborted because lock(s) could not be acquired immediately and NOWAIT is set. 쿼리의 최대 잠금 시간인 InnoDB lock time을 0으로 ..

• format_list_bulleted Backend/DB
• · 2024. 12. 28.
• textsms

COUNT 쿼리의 실행계획, 인덱싱

1. 들어가며 https://rawshrimpsushi.tistory.com/65 COUNT(*) & COUNT(DISTINCT) 튜닝1. 들어가며실무에서 COUNT 쿼리를 사용할 일은 생각보다 자주 있습니다. 다만 COUNT 쿼리가 가볍다는 일반적인 인식이 있어서, 잘못된 쿼리로 예상치 못한 성능 이슈를 겪는 경우도 있습니다. 오늘rawshrimpsushi.tistory.com위 글에서 COUNT 쿼리에 대한 잘못된 인식과 ORM과 함께 사용하였을 때의 COUNT(DISTINCT)의 문제점에 대해 알아보았었습니다. 오늘은 COUNT 쿼리를 사용할 때 주로 쓰는 (*) 키워드와 column을 넣었을 때의 차이점, 그리고 일반적으로 권장되는 방법에 대해 자세히 알아보고자 합니다. 2. COUNT(*) vs..

• format_list_bulleted Backend/DB
• · 2024. 12. 28.
• textsms

풀스캔 쿼리 패턴 및 튜닝

1. 들어가며 풀스캔 쿼리라는 건 백엔드 개발자에게 정말 무서운 말인 것 같습니다. 실제 테이블 레코드 건수가 적다면 큰 부하가 아니겠지만 실무에서 그런 경우는 흔치 않습니다. 특히 서비스의 메인이 되는 테이블에 풀스캔 쿼리가 발생하는 일 만큼은 피해야 합니다. 오늘은 풀스캔 쿼리가 발생하는 주된 패턴을 살펴보고 풀스캔 쿼리를 피하는 방법에 대해 살펴보도록 하겠습니다. 2. 풀스캔 쿼리 패턴 1) 컬럼이 가공되는 경우컬럼이 연산에 포함되는 경우 인덱스를 사용할 수 없게 됩니다. 인덱스는 컬럼 원본 값으로 만들어져 있기 때문입니다.SELECT * FROM tb1 WHERE count + 10  연산의 경우: id에 1만 곱해서 사실 동일한 값일텐데도 인덱스 사용 못하고 full scan을 하지 못합니다.함..

• format_list_bulleted Backend/DB
• · 2024. 12. 26.
• textsms