https://www.percona.com/blog/a-quick-peek-at-mysql-8-0-34-and-mysql-8-1-0/ A Quick Peek at MySQL 8.0.34 and MySQL 8.1.0 Taking a look at what Oracle delivered with MySQL 8.0.34 and 8.1.0 on July 17th, 2023. www.percona.com 드디어 8.1이 나왔습니다. 공식문서 보다가 버전 선택란에 8.1이 있길래 깜짝 놀람 -_-; 아직 엄청나게 큰 변화는 없는 것 같습니다. 8.0의 지원이 벌써 2년 반 밖에 남지 않은 시점에서, 슬슬 8.1의 추이도 잘 지켜봐야 할 것 같습니다. 아래는 단순 번역본입니다. 이것은 Oracle이 2023년 7월 ..

https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html MySQL :: MySQL 5.7 Reference Manual :: 14.13.1 Online DDL Operations 14.13.1 Online DDL Operations Online support details, syntax examples, and usage notes for DDL operations are provided under the following topics in this section. The following table provides an overview of online DDL support for index operations. An aste..

실무에서 MySQL이 제공해주는 동시 요청 제어 컨트롤을 제대로 이해하지 못하고 유지보수 및 개발자분들의 요청을 처리하다가 장애를 맞은 경험이 있습니다. 다행히도, 서비스 구조상 DB 서버가 MSA로 잘게 나뉘어있어서 상품 목록을 불러오는 기능만 1분 정도 막히는 해프닝으로 넘어갔지만... 아직도 아찔한 경험입니다. 결론부터 말씀드리자면, 이 모든게 !메타데이터 락!에 대한 무지에서 시작되었습니다. 먼저 메타데이터 락과 간단한 예제를 살펴보고 이를 해결하는 방법을 소개드리고 Java + SpringBoot 코드로 이 과정을 자동화 하는 예제도 살펴봅시다 Metadata Lock 메타데이터 락은 MySQL 5.5 버전부터 생긴 개념입니다. MySQL 서버는 메타데이터 락을 통해서 데이터베이스 개체(프로시..

각 타입의 특징 VARCHAR 컬럼에 가변길이 문자열 타입을 지정 1부터 65535의 값을 가질 수 있음 (바이트가 아닌 글자 수) 길이를 표현하기 위한 공간복잡도 오버헤드가 있음 255까지의 길이는 1byte, 256부터는 2byte 오버헤드 존재 CHAR의 경우는 고정길이 문자열 타입이지만 공간복잡도 오버헤드가 없음 인덱스를 생성할 수 있음 TEXT VARCHAR와 동일하게 컬럼에 가변길이 문자열 타입을 지정 최대 65535글자의 글자를 적재할 수 있지만 크기를 미리 지정 불가 길이를 표현하기 위해 무조건 2byte의 공간복잡도 존재 인덱스를 제한적으로 생성 가능함. 부분 prefix 인덱스만 가능 의문: VARCHAR로도 65535의 길이를 모두 표현 가능한데 TEXT를 사용해야 하는 이유가 뭘까?..

개인 게시판 프로젝트를 진행하고 있습니다. 구현한 기술 요구사항 중, 각 게시글의 조회수를 요청마다 한 건씩 바로 업데이트 하는 것이 아니라 어딘가에 모아뒀다가 한번에 Update쿼리를 쏟아내는 방식으로 벌크 업데이트 처리를 한 구현이 있습니다. 이 상황에서, Update 쿼리를 한 트랜잭션에서 모아서 쏴주기는 하지만 단일 트랜잭션에 Update쿼리가 너무 많습니다. 그래서 인프런 JPA의 어머니에게 질문을 남겼던 기억이 있습니다. 아래 이미지는 당시에 답변받은 내용입니다. 아.. 그렇구나.. 김영한님이 안된다면 안되는거구나 하고 그냥 넘겼었습니다. For문 돌리면서 그냥 하나하나 update를 수행했습죠. 그런데 오늘 책을 읽다가 엄청난 것을 발견했습니다. MySQL8.0 버전부터는 레코드 생성 문법으..

11번가 코딩테스트에서 매우 어려운 SQL문제가 나왔습니다. 프로그래머스에서 SQL 고득점 kit를 푼 정도로는 해결할 수 없는 레벨이었습니다. 마감 1분을 남겨두고 제출하긴 했지만, 여전히 제 실력이 부족하다는 것을 느끼게 되는 계기였습니다. 백엔드 개발자는 SQL을 자유자재로 구사해야 합니다. 업무와 밀접하기도 하고, 어떻게 작성하고 튜닝하느냐에 따라 성능이 수백배 차이나기도 합니다. WAS 장애 포인트의 90퍼센트 이상이 DB 성능문제라고 하니, 실행계획을 보고 SQL과 인덱스를 개선하는 능력은 필수입니다. 실무에서 장애를 몸으로 겪으며 성장하는 것이 가장 빠르겠지만, 그럴 수 없으니.... 책으로 미리 경험하고 실무에 투입하면 좋을 것이라고 생각해서 책을 읽기 시작했습니다. RealMySQL을 읽..

최근 운영체제를 복습하며 reader-writer problem 에 대한 토픽을 알게 되었다. MySQL8의 기본 스토리지 엔진 InnoDB는 DDL이 아닌 이상 테이블 잠금이 아니라 레코드 기반 락을 사용한다. 문득, 어떤 식으로 락이 걸리고 어느 정도까지 제한을 두는지 궁금해졌다. 가정은 이렇다. 사실 레코드 하나의 전체에 락을 거는 것이 아니라 인덱스에 락을 거는 방식인데, 그럼 이 때, 해당 인덱스가 아닌 다른 속성들에는 락이 걸리지 않는 것인가? 만약 그렇다면, 해당 인덱스A를 제외한 커버링 인덱스B로 처리되는 또 다른 쿼리문은 해당 인덱스A 락이 풀리지 않아도 처리가 가능할까? 뭔말인지 잘 모르겠다. 일단 해보자 우선 인덱스 생성부터! create index test1 on post (post..

빠른 조회를 위해 테이블 속성에 인덱스를 걸려고 하는 참이었다. 그런데, 다음과 같은 에러가 발생했다. Error Code: 1071. Specified key was too long; max key length is 3072 bytes 다름 아닌 인덱스 키의 최대 크기 제한이 있다는 것을 발견했다. 이것과 관련해서 글도 썼었는데 -_-;;; 이래서 실습이 중요하다.. 궁금하시다면 https://leezzangmin.tistory.com/30 [MySQL8.0] B-Tree 인덱스 사용에 영향을 미치는 요소 이 글은 'Real MySQL 8.0 개발자와 DBA를 위한 MySQL 실전 가이드'를 보고 학습한 내용을 정리한 글입니다. B-Tree 인덱스는 인덱스를 구성하는 1. 칼럼의 크기와 2. 레코드의..

이 글은 'Real MySQL 8.0 개발자와 DBA를 위한 MySQL 실전 가이드'를 보고 학습한 내용을 정리한 글입니다. B-Tree 인덱스는 인덱스를 구성하는 1. 칼럼의 크기와 2. 레코드의 건수 3. 유니크한 인덱스 키 값의 개수 등에 의해 작업 성능 영향을 받습니다. InnoDB 스토리지 엔진에서, 주기억장치(하드디스크)에 데이터를 저장하는 가장 기본적인 단위를 페이지, 블록이라고 합니다. 이론적으로 디스크의 모든 읽기와 쓰기는 페이지 단위 미만이 될 수 없습니다. 또, 페이지는 InnoDB 스토리지 엔진의 버퍼 풀에서 데이터를 버퍼링(캐싱) 하는 기본 단위입니다. 인덱스 구조에서 루트, 브랜치, 리프 노드를 구분하는 기준이 바로 이 페이지 단위입니다. 흔히 오해하기 쉬운 것이, B-Tree가..

지난 프로젝트동안 감사하게도 무려 카카오에 재직중이신 Jack에게 코드리뷰를 받을 기회가 있었습니다. 받았던 코멘트 중, 기능 구현에 급급해 당시에는 넘어갔던 내용 중 다시 살펴보니 흥미로운 내용을 공유해보려고 합니다. 음식상품 데이터를 랜덤으로 추출하는 API를 클라이언트쪽에 제공하고 있었습니다. 초기 데이터를 선택해서 뿌려주는 로직이라 위와 같이 ORDER BY RAND() LIMIT 3 이라는 쿼리문을 작성했고, 잘 작동했습니다. 그런데 위 쿼리는 큰 문제가 있습니다. ORDER BY 의 조건에 RAND()라는 함수가 걸려있어 스토리지 엔진이 비효율적으로 작동하기 때문입니다. RAND() 함수는 쿼리 실행 순간에 레코드에 각각 임의의 값을 할당한 후에 그 할당된 값으로 정렬을 수행하게 됩니다. 비용..