Real MySQL シーズン 1 - Part 2

안녕하세요?먼저 좋은 강의 감사합니다. 7:50쯤 unique 제약조건이 걸린 상황에서 deadlock이 발생하는 경우에 질문이 있어서 글 남깁니다. 말씀주신 시나리오는u

안녕하세요. 1,2 강의 전부 잘봤습니다!! 많은 도움 되었습니다.근데 강의에 대한 질문은 아닌데 도저히 여쭤볼 사람이 딱히 없어서요..현재 백엔드 취준생인데 프로젝트에 mysql 레플리카를 도입해서 master / slave1,2 아키텍

인덱스가 null인 컬럼을 포함하고 있고대상컬럼이 nullable column인지 not null column인지상관없이 어떤 인덱스를 읽어도 테이블의 정확한 레코드 수를 가져올 수 있다는게 무슨 뜻인지 이해가 잘안가서 질문 드립니다.&

좋은 강의 제공해주셔서 감사합니다!강의를 듣다보니 의문점이 하나 생겼는데요. 에피소드 14의 시퀸셜하지 않은 UUID사용시 범위 검색의 조회 효율성 문제를 언급해주셨는데요 데이터 삽

"테이블 파티셔닝이 필요한 이유"중에 "자원 사용 효율 증가 및 쿼리 성능 향상"을 언급주셨습니다.예를들어 최근에 저장된 데이터들 위주로 조회하는 경우 파티션 프루닝을 통해 최근 데이터만 접근하니까 효율적이라는 내용인데요, 효율적인 부분이 제가 생각했

"DeadLock 예시(2)"에서 INSERT구문이 UNIQUE를 보장하기위해 shared lock을 걸고 확인한다고하였는데요, 그냥 처음부터 exclusive lock을 걸고 값을 확인하게 구현할 수도 있을 것 같은데, 그렇게 안되어있는 특별한 이유가 있을까요?

에피소드 15에서 복합 인덱스의 경우 순서가 중요하다고 하셨는데요.그럼 인덱스 생성 시 (account_type, joined_at) 와 같은 순서일때 조건에 joined_at account_type 순서로 주어지면 인덱스를 활용하지 못하는게 맞을

안녕하세요. 질문 드립니다.1:N 구조의 웹 어플리케이션입니다.종종 동일한 insert 요청이 짧은 시간에 발생 합니다.insert는 N(child) 테이블에 되어야 합니다.해당 테이블에는 유니크 제

안녕하세요. 이제 2회차로 다시 잘 보고 있는 수강생입니다 🙂 Ep15를 보던 중 복합 인덱스의 컬럼들 중 선행컬럼을 조

예제에서는 WHERE 절 때문에 LEFT JOIN이 INNER JOIN으로 최적화되는 것으로 알고 있지만 만약에 LEFT JOIN으로 걸릴 수 있는 쿼리라면 SKIP LOCKED 의 잠금 경합의 결과가 달라질 수도 있나요?

안녕하세요!14분 쯤 나오는 단일 인덱스 크기와 전체 인덱스 크기가 얼마인지 나오는데, 각각 구하는 계산식을 알 수 있을까요..?어떻게 8바이트가 1억건의 테이블이 있을때 6GB가 되는지 잘 모르겠습니다..<li

안녕하세요!좋은 강의 감사합니다!이력 테이블의 대용량 데이터를 저장하기 위해pk값 설정 시 정수형은 제한이 있다고 생각해서시간+uuid로 복합키를 설정하려고 하는데요! 레인지 파티션도 사용하려구

강의 마지막 주의사항 중 아래의 설명이 있었는데요."참조하는 테이블들의 데이터에는 읽기 잠금(Shared Lock) 이 발생하므로, 잠금경합이 발생할 수 있음" 이 부분에 대한 추가적인 궁금증이 있습니다.<

일단 이 강의를 통해서 너무나 좋은 정보를 많이 얻어가서 감사할 따름입니다. Ep.17 강의 마지막의 정리 부분에서 "SKIP LOCKED는 데이터 큐잉 후 배치잡 처리"에 유용하게 사용 가능하다

우선 좋은 강의 기회를 주셔서 너무 감사드립니다 :) 출근길 아니면 퇴근길에 영상에 나오는 자료 보면서 공부 할려고 하는데요.<p