인덱스가 아래와 같을때idx_orders_user_status(user_id, status, created_at)아래 쿼리문이 왜 문제인지 궁금합니다.select * from orders where 1=1 and status = 'pending' and user_id = 123강의 내용(11분 30초)에서는 인덱스의 컬럼 순서와 조건문(where)의 컬럼 순서가 틀려 효율적이지 못하다고 설명해 주시는 거 같습니다.하지만 이는 옵티마이저에 의해 where절의 컬럼 순서를 재계획 하는 걸로 알 고 있습니다.강의의 의도는 left prefix index rule 때문에 인덱스 순서를 조심해야 한다는 내용인 거 같은데... 혹시 꼭 순서를 지켜야 하는 이유가 있을까요??(첫 번째 인덱스 미사용, 중간 컬럼 미사용, 커버링 인덱스 등의 특정 상황 제외)

안녕하세요. 항상 영상 잘 시청하고 있습니다.이번에 강의를 시청과 실무에서 업무를 하면서 궁금한 사항이 있어서 질문을 작성합니다.실무에서 인덱스 및 DB에 대해서 최근에 고민이 있습니다. 하나의 테이블에 어쩔 수 없이 컬럼이 많아지는 경우 인덱스가 많아지는 경우가 있어 고민이 됩니다. 물론 상황마다 다르겠지만 강사님의 의견이 궁금하여 질문을 드립니다. 질문인덱스 : 조회의 다양한 경우가 있어서 인덱스가 과도하게 많아지는 경우가 있습니다.ex) 복합 인덱스 (A,B,C)가 있다고 가정하면 선행 인덱스가 포함되지 않는 경우에 그냥 인덱스를 추가를 하시는지 궁금합니다. 간단하게 강의에서 post를 기준으로 (title, content)의 인덱스에서 나중에 content만 필터를 해야 되는 경우 ( 실제로 content에 인덱스는 적절하지 않다고 생각하지만 예시 ) 1-1. 만약에 추가를 하게 된다면 하나의 Table에 최대 인덱스 개수는 몇개로 지정을 하시는지 궁금합니다. 너무 많아지게 되면 Write작업에 대해서 부화를 가지기 때문에 측정을 하시는 기준점이 있는지 궁금합니다. ( 상황마다 다르겠지만 일반적으로 생각하시는 기준 )  MySQL에서 집계에 대한 아키텍처하나의 재고를 row로 표현하는 테이블이 있다고 가정하면 특정 상품의 재고를 구하기 위해서 count를 사용을 해야됩니다. (하나의 row는 상품 1개)캐싱을 처리하면 데이터의 정합성에 문제가 생기고 매번 쿼리를 실행하면 성능 및 DB에 부화가 발생합니다.이것을 개선하기 위해서 만약에 집계 테이블을 만들어 Redis, Kafka에서 이벤트가 발생하면 집계 테이블에 개수를 수정하는 방식으로 실무에서 많이 사용되는지 궁금합니다.만약에 많이 사용이 된다면 주의사항이 어떤게 있을까요??  

현재 강의를 시작하는 단계입니다. 뒷 강의에서 설명이 나올지 모르겠지만 현재 프로시저만 보았을 때 CALL 명령에서 GenerateUsers만 진행하고 Account는 부르지 않고있는데 의도하신걸까요?

안녕하세요(2) LEFT JOIN 사용 방법 준수 - 오타 질문 (3:58 부근) 에서 첫 번째 SQL이 아래와 같이 써있는데요 select u.id, u.name, ua.value from user u left join user_attribute ua on ua.user_id=u.id where ua.name='address' where 조건에 ua.name이 아니고, ua.value가 아닐까 의미적으로 맞는게 아닌가 싶어서 질문드립니다. 전체 스키마가 있는게 아니다보니 제가 오해한 걸수도 있어서, user, user_attribute 테이블 전체 스키마를 주시면 감사하겠습니다!

안녕하세요, count(1) 대신 count(*)을 쓰라고 하셨는데요, count(1)이 성능이 더 좋다고 알고 있는데 제가 잘못 알고 있는 부분일까요? 성능적인측면에서도 답변 부탁드리면 감사하겠습니다~

기존강의들.. 대폭할인 이벤트는 더 이상 하지 않으시겠죠..?한번씩 최신강의들 대폭 할인 하시던데.. 아쉬워서 한번 여쭤봅니다..

1분이 넘어가도록 실행이 끝나질 않습니다.

레코드를 저장할 위치가 같은 페이지내에 존재하지 않으면 다른 페이지에 저장될까요?

안녕하세요, 강의 잘 듣고 있습니다. 04 페이징 쿼리 작성 강의 > 데이터 개수 기반 방식 (동등 조건 사용 시) (9:36 부근) 에 나온 예시에 대한 질문입니다. KEY index_userid_id (user_id, id)로 인덱스가 있는데요, user_id +id 가 아닌, user_id만 인덱스로 걸어도 N회차 쿼리가 잘 동작 할까요? where 절에 user_id, id를 사용하고, ORDER BY 에 id가 있기 때문에 user_id + id 인덱스가 필요한 걸까요? 조금 더 자세히 알려주시면 감사하겠습니다.

안녕하세요, ppt 자료제공이 안되는 건가요?일년 전 문의 글이 있어보니, 문제가 있어 당장에 공개를 안하고 있다고 하신글을 봤늗네 아직도 해결 되지 않으신걸까요?구매하였는데, 당황스럽네요...

문자열 형식의 숫자를 정렬하는 팁을 알려주셨는데,ORDER BY a=1 ASC; 가 어떻게 숫자를 정렬시킬 수 있는걸까요? 결국 결과는 boolean으로 a가 1인 컬럼은 true가 되면서 맨위로 오고 나머지는 모두 false가 되고 정렬은 옵티마이저 선택에 따라 뒤죽박죽일꺼같은데 설명 한번 부탁드립니다.

10강 LEFT JOIN 주의사항 및 튜닝에서explain select u.id, u.name, uc.coupon_id, uc.use_ynfrom user u left join user_coupon uc on uc.user_id = u.i and uc.coupon_id = 3;위 쿼리의 실행계획으로type ALL 이 나왔는데요왜 u.id는 primary key인데 왜 index가 나오지 않고 ALL이 나오는 걸까요?left join 시 where 절에 조건이 없으면 드라이빙 테이블은 항상 ALL로 읽나요?혹시 u.name을 select절에 포함해서 ALL이 나오는걸까요?

해당 강의와 직접적으로 연관있지는 않으나, Lock 관련하여 공부하던 중 성욱님의 MySQL GAP Lock (두번째 이야기) 글을 보게 되었습니다.우선 정말 많은 도움이 되었음에 감사드리며, 해당 글 관련하여 질문을 드리고 싶습니다. (SELECT FOR UPDATE와도 관련있는 내용이라, 이곳 게시판을 통해 질문 드립니다.)위 글의'왜 supremum 레코드를 잠그나요 ?' 단락에서, 8, 9 번째 과정을 보면 다음과 같습니다.8. 다음 페이지에서 id=137 보다 큰 (첫번째) 레코드인 id=138 읽기9. WHERE 조건에 일치하지 않으므로 잠금 걸지 않음그런데 그 아래에서 다음과 같은 내용을 말씀해 주십니다.'REPEATABLE-READ 격리 수준을 사용하는 MySQL 서버에서는 검색하고 스캔했던 인덱스 레코드를 잠근다는 아주 기본적인 규칙 때문에 잠금이 발생하고 있었던 것이죠. 사용자 데이터가 아닌 시스템 레코드(supremum)까지도 말이죠.'그러나 이 설명에 따르면, '왜 supremum 레코드를 잠그나요 ?' 에서 언급한 동작에 모순이 발생하는 것 같습니다.5,6,7 번 과정에서는 supremum record를 읽었기에 잠갔음에도 불구하고,8, 9번의 과정에서는 id=138 읽었지만 잠그지 않고 종료했기 때문입니다.위 내용이 모순된 것이라 가정하고,왜 supremum record에 Lock이 걸리도록 동작했는지에 대한 이유를 개인적으로 찾아보고 공부한 내용들에 기반하여 추측해 보았습니다. (아직 내용을 완벽히 공부하지 못해 틀린 내용이 있을 수 있습니다. 혹시 틀린 부분이 있다면 지적해주시면 감사하겠습니다!)MySQL 의 공식 문서의 내용에 따르면, Gap Lock은 Gap Lock 의 기준이 되는 index record 이전의 간격을 잠급니다.A next-key lock on an index record also affects the “gap” before that index record- MySQL 공식문서 - Next Key Lock그러나 Gap락이 특정 index record 이전의 간격을 잠근다는 위 설명에 따르면, 어떤 index의 가장 마지막 record 이후의 간격을 잠글 수 있는 방법이 없어집니다. (Gap Lock 은 이전 간격을 잠그는 것이므로)따라서, 마지막 record 이후의 값을 잠글 수 있기 위해 supremum pseudo record 를 두었을 것이라 예상합니다.supremum pseudo record(인덱스가 가질 수 있는 가상의 가장 큰 값) 에 대한 GAP Lock은 supremum pseudo record 이전의 간격들을 잠그기 때문입니다.이는 공식 문서의 다음과 같은 내용을 통해 뒷받침할 수 있을 것 같습니다.'Suppose that an index contains the values 10, 11, 13, and 20. The possible next-key locks for this index cover the following intervals, where a round bracket denotes exclusion of the interval endpoint and a square bracket denotes inclusion of the endpoint:'(negative infinity, 10] (10, 11] (11, 13] (13, 20] (20, positive infinity)For the last interval, the next-key lock locks the gap above the largest value in the index and the “supremum” pseudo-record having a value higher than any value actually in the index. The supremum is not a real index record, so, in effect, this next-key lock locks only the gap following the largest index value.- MySQL 공식문서 - Next Key Lock이를 바탕으로 '왜 supremum 레코드를 잠그나요 ?' 의 원인을 분석해보면 다음과 같습니다.- 우선 3,4 번 과정에서 id=137 인 index record를 읽습니다. - 이때 id는 PK 이므로 값이 유니크하기에, BETWEEN 136 AND 137 조건을 통해 137이라는 값을 찾았으면, 해당 값이 조건을 만족하는 가장 마지막 값이라는 것을 알 수 있습니다.- 따라서 id=138 을 더 이상 탐색하지 않고 종료하게 되는데, 이때 id=137은 해당 PK 인덱스(리프노드 페이지) 의 가장 마지막 값이므로, supremum 레코드를 이용하여 추가적인 간격을 잠구는 것이지 않을까 하는 생각이 들었습니다.위 부분에 대한 성욱님의 의견을 듣고 싶어 질문드렸습니다.---이와 별개로, 추가 궁금증이 있습니다.1. MySQL 공식 문서에서도 언급되었던 InnoDB performs row-level locking in such a way that when it searches or scans a table index, it sets shared or exclusive locks on the index records it encounters. 라는 문장에서 검색되거나 스캔된 의 의미가 잘 이해되지 않습니다.예를 들어, id를 PK로 갖는 어떤 테이블에서, id = 3 인 row 를 탐색하기 위해서는,B-tree의 root 부터 시작 ~ leaf 노드로 이동 후, leaf node의 페이지의 전체 데이터를 스캔해야 하지 않나요?예를 들어 id=3 인 record 가 들어있는 leaf 노드의 페이지에 id가 1 ~ 5 까지 있다고 하면,leaf 노드의 페이지로 진입하여 1부터 순차 탐색을 진행할 것 같은데, 그렇게 되면 1~5 까지의 index 값 사이에서 3을 탐색하는 데 1과 2를 먼저 찾을 것이므로, id가 1, 2, 3인 row가 모두 잠겨야 하지 않나 하는 생각이 들었습니다. 혹시 공식문서에서 언급한 검색 혹은 스캔된의 의미가, 조건에 사용된 인덱스가 걸린 필드 값만 확인하는 것은 포함하지 않는 것일까요?(ex - 위 예시에서 id가 1인 인덱스 확인조건에 부합되지 않으므로 넘어감. (스캔되었다고 보지 않음)id가 2인 인덱스 확인조건이 부합되지 않으므로 넘어감id가 3인 인덱스 확인조건에 부합되므로 나머지 값 읽어옴.)위 내용들에서, 제가 어떤 부분을 잘못 생각하고 있는지 알 수 있을까요?정말 좋은 강의와 글 공유해 주셔서 감사합니다. 

데이터 개수 기반 방식 (동등 조건 사용시) 에서 이미 인덱스를 설정 했기 때문에KEY ix_userid_id (user_id, id)따로 후에 ORDER BY id를 해주지 않아도 정렬이 되어 있을 것이라고 예상되는데 작성해 줘야 하는 이유가 무엇일까요

안녕하세요~!강의에 오타가 있는 것 같아서 질문 드립니다.e2 서브쿼리에 user_id도 select 절에 포함되야 할 것 같아요!select sum(sign_up) as signed_up, sum(complete_purchase) as completed_purchase, (sum(complete_purchase) / sum(sign_up) * 100) as conversion_rate from ( -- 1월에 새로 가입한 유저 목록 select user_id, 1 as sign_up, min(created_at) as sign_up_time from user_events where event_type = 'SIGN_UP' and created_at >= '2024-01-01' and created_at < '2024-02-01' group by user_id ) e1 left join ( -- 처음 결제한 시점 정보 목록 select user_id, 1 as complete_purchase, min(created_at) as complete_purchase_time from user_events where event_type = 'COMPLETE_PURCHASE' group by user_id ) e2 on e2.user_id = e1.user_id and e2.complete_purchase_time >= e1.sign_up_time and e2.complete_purchase_time < date_add(e1.sign_up_time, interval 7 day);

안녕하세요. 2강을 수강하면서 궁금한 점이 있어 질문 글 남깁니다. VARCHAR(30) vs VARCHAR(255) 둘 중에서 데이터 타입을 선택할 때 실제 사용하는 길이만큼만 명시해 주는 게 메모리 사용 효율을 높일 수 있다고 말씀해주셨는데요.VARCHAR(30)와 VARCHAR(255) 모두 저장되는 데이터의 길이 정보를 1 바이트(0~255 표현 가능)로 저장하는 것이 맞는걸까요?강의 자료에 VARCHAR(30) vs VARCHAR(255) 차이를 설명할 때 '디스크 공간 효율 차이도 미미하게 존재(1바이트 vs 2바이트)'라고 적혀 있어 VARCHAR(255)에서 저장되는 데이터 길이 정보에 2바이트의 공간을 할당한다는 의미로 이해되어서요. 좋은 강의 감사합니다.

안녕하세요. 강의 잘 듣고 있습니다. 제가 이해한바로는 LIMIT, OFFSET은 앞에서부터 data를 순차적으로 읽기때문에 성능 상 좋지 않고 이를 개선하기 위해 범위 기반 방식을 사용한다고 이해하였습니다.범위 기반 방식은 직접 ID 값을 지정 해주는 방식이며, id 기반으로 5000단위로 조회한다고 가정하면1회차: select * from users where id > 0 AND id <= 50002회차: select * from users where id > 5000 AND id <= 1000위와 같이 구현될 것으로 예상됩니다.관련해서 궁금한 점이 생겼는데요. 결국 두번째 쿼리를 실행 시 5000보다 큰 id를 찾는 과정에 시간이 소요될 것으로 예상되는데요, id가 index로 지정되어있어 LIMIT, OFFSET 방식보다 빠르게 찾을 수 있는 것인가요??LIMIT, OFFSET 방식 사용 시 어떤 컬럼이 index로 지정되어있는지와 상관없이 무조건 순차 탐색이 일어나는 것이고 범위 기반으로 조회 시 index로 서치하기때문에 더 빠르게 시작점을 탐색할 수 있다고 이해하면 될까요?

안녕하세요?먼저 좋은 강의 감사합니다. 7:50쯤 unique 제약조건이 걸린 상황에서 deadlock이 발생하는 경우에 질문이 있어서 글 남깁니다. 말씀주신 시나리오는unique index가 걸린 컬럼이 delete가 수행되면서, 동시에 insert into 구문이 들어오는 상황으로 말씀주셨는데요. unique index는 s-lock을 꼭 필요로 한다면,delete가 선행되지 않는 상황에서도 deadlock이 발생해야되는거 아닌가? 싶습니다. 상상하는 예시는 다음과 같습니다.tx-1 : begin; insert into tab(pk) values(2) (index 2 또는 그 범위에 s-lock) tx-2 : begin; insert into tab(pk) values(2) (index 2 또는 그 범위에 s-lock)tx-1 : commit; -> index 2에 x-lock을 잡으려고 하지만 tx-2가 s-lock을 잡고 있어서 잡을 수 없음 하지만, 실제로 테스트 해보았을 때는tx-1이 commit시에 정상적으로 insert 되고, tx-2는 duplicated key 오류를 반환합니다. 왜 이런지 알 수 있을까요?감사합니다 😃 다시 한 번 생각해보니, tx-1은 pk=2 가 없기 때문에 insert 후 x-lock으로 전환하고, tx-2는 x-lock으로 인해 lock_wait인 것 같습니다. 혹시 맞을까요?delete 가 선행된 경우는 이미 있는 레코드에 tx-1,2가 s-lock이을 잡으면서 delete가 commit된 시점에 tx-1,2가 x-lock을 획득하려는데서 dead lock이 발생하는 것이고요

안녕하세요? 질문이 있습니다.6분 20초쯤 "여러 데이터를 수정할 때는 발생하는 lock의 순서를 지켜주자" 라는 말을 이해하지 못했습니다. 좀 더 자세히 설명 가능하실까요?트랜잭션 X에서는 A -> B 를 수정한다. 트랜잭션 Y에서는 B -> A 를 수정한다. Deadlock 발생할 가능성이 있음은 이해했습니다. 여기서 lock의 순서를 지킨다는 것이 무슨 뜻일까요?트랜잭션 Y도 A -> B 흐름으로 수정하도록 만들라는 뜻인가요?그렇다면 이해는 되지만, 트랜잭션 Y가 B -> A 로만 수정해야하는 상황이라면 어떻게 해소해야 하는지 궁금합니다. 감사합니다 :)

안녕하세요. MySQL 사용에 있어 Where절 내 조건의 순서가 쿼리 성능에 영향을 미치는지 여쭙고자 문의드립니다. 기본적으로는 옵티마이저가 쿼리를 최적화하기 때문에 Where절의 순서가 중요하지 않은 것으로 알고 있는데, DBMS에 따라 통계정보를 활용하는 데 있어 차이가 있다는 이야기를 들은 바 있어 호기심에 여쭤봅니다. (MySQL 공식문서에는 관련된 내용을 못 찾겠네요..)