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 공식문서에는 관련된 내용을 못 찾겠네요..)

안녕하세요. 좋은 강의 감사드립니다.강의 내용 중, VARCHAR타입 컬럼에 더 긴 문자열로 UPDATE 작업 시 이전 공간은 delete marking 된다고 하셨습니다.PostgreSQL의 경우에도 비슷한 매커니즘을 사용하기 때문에 VACUUM을 사용해 단편화 문제를 해결하는 것으로 알고 있고, 찾아보니 OPTIMIZE TABLE문을 통해 비슷한 작업을 할 수 있는 것 같습니다.PostgreSQL의 경우에는 VACUUM을 주기적으로 수동으로 해줘야 한다고 알고 있습니다만 MySQL의 경우에는 OPTIMIZE TABLE을 수동으로 해줄 필요가 있는지, 있다면 어느 정도 주기가 좋은지 궁금합니다.

TEXT, LONGTEXT 타입 칼럼이 존재하는 테이블의 경우에 informatino_schema.TABLES에 존재하는 avg_row_length의 값은 LOB 칼럼들의 평균바이트 수도 같이 계산이 되는걸까요?

안녕하세요. 1,2 강의 전부 잘봤습니다!! 많은 도움 되었습니다.근데 강의에 대한 질문은 아닌데 도저히 여쭤볼 사람이 딱히 없어서요..현재 백엔드 취준생인데 프로젝트에 mysql 레플리카를 도입해서 master / slave1,2 아키텍처를 구성 하였습니다.--master[mysqld]log_bin = mysql-binserver_id = 10binlog_do_db = reservationdefault_authentication_plugin = mysql_native_password-- slave[mysqld]log_bin = mysql-binserver_id = 11relay_log = /var/lib/mysql/mysql-relay-binlog_slave_updates = ONread_only = ONdefault_authentication_plugin = mysql_native_password master와 slave에 맞게 설정을 해주고 master의 LOG_FILE, LOG_POS를 토대로 각각의 슬레이브에 설정하여Slave_IO_Running, Slave_SQL_Running slave1,2 각각 YES 인걸 확인하고 데이터 복제 및 인덱스 복제 까지 잘 동작하는것 까지 확인하였습니다. 그래서 백엔드 로직에서 ReadOnly 쿼리 비지니스로직은 SLAVE1,2의 dataSource가 할당 되어서 동작 하도록 구성하였고 실제로 테스트 해봤는데 master가 아닌 SLAVE1,2에서만 읽는것을 확인 하였습니다. 근데 여기서 문제인게 읽기작업에 대해서만 부하를 줘서 성능테스트를 진행하였는데 실제로 레플리카를 도입하기 이전 1대의 mysql 서버만 존재했을때가 성능이 20~30% 가 더좋게 나옵니다.저는 실제로 이미 쓰기작업을 끝낸 데이터에 대해 읽기 작업을 slave1,2가 트래픽을 분산(라운드 로빈 방식으로 정확히 50프로 확률로 분산) 하여 처리하니까 성능이 올라갈것으로 기대했는데 왜그런지 도저히 모르겠습니다.추가로 쓰기작업(JPA 긍정적 락), 읽기작업을 동시에 요청하는 부하테스트도 진행 했는데 물론 이 경우도 쓰기는 master만 진행하고 읽기작업은 나머지 slave1,2에서만 진행하는걸 확인했지만 성능 결과 1대의 mysql서버가 읽기,쓰기를 다 처리하는것이 성능이 더 좋았습니다. 그래서 제가 내린 결론은 만약 제가 한 테스트 방법이 잘못되지 않았다고 가정할 경우SLAVE 아키텍처를 가져 갈 경우 성능 향상보다는 부하를 분산시켜 최대 허용 TPS 향상 및 아키텍쳐의 안정성을더 해주는게 의미가 있다고 생각되고,만약에 SLAVE1,2를 두었는데 무조건 읽기작업의 성능향상이 이뤄져야 한다고 말씀 하시면 어떤 부분에서제가 무엇을 잘못 설정한걸 수 도있는지 아니면 어떤 이유가 존재할 수도 있는지 해결가능성이 있는 키워드정도 알려주시면 정말 감사하겠습니다. 추가로 상황에 따라 다르겠지만, 마스터 슬레이브 간의 동기화 문제를 해결하는 가장 보편적이고 추천 해주실만한 방법(제가 생각한 방법은 쓰기작업 직후의 읽기작업은 슬레이브가 아닌 마스터에서 하는 방식)이 있는지 알려주시면 정말 감사하겠습니다! 긴글 읽어주셔서 감사합니다.

인덱스가 null인 컬럼을 포함하고 있고대상컬럼이 nullable column인지 not null column인지상관없이 어떤 인덱스를 읽어도 테이블의 정확한 레코드 수를 가져올 수 있다는게 무슨 뜻인지 이해가 잘안가서 질문 드립니다. 1. 인덱스가 null인 컬럼을 포함하고 있다는것은,인덱스가 존재하지 않는 컬럼을 의미하는 건가요 아니면 nullable 컬럼에 생성한 인덱스를 의미하는 건가요?2.nullable column이 존재하더라도 not null column에서 레코드를 읽는 덕분에 라는 건가요?

안녕하세요.8:01에서 FULL GROUP BY 형태에 대해 설명해 주시고 있습니다. 그 중 오른쪽의 FULL GROUP BY의 쿼리에 질문이 있습니다. GROUP BY로 fd1을 명시했으니 적절한 쿼리는SELECT fd1, SUM(fd1), COUNT(*) FROM tab GROUP BY fd1이 되어야 하지 않을까요?*변경 부분: SUM(fd2) -> SUM(fd1)

안녕하세요 강사님Client Side PreparedStatement 는 어떻게 SQL Injection을 막을 수 있다는게? 에 set하기전에 application에서 체크해서 막는다는의미인가요?

안녕하세요 강사님 gpt o1에게 물어보다가 질문이 생겼습니다.read committed 상태일 때 select for update를 쓰면 해당 statement가 끝나면 lock이 풀린다는데 이는 잘못된거지요?

안녕하세요 강의 잘 듣고 있습니다.강의 내용 중 오른쪽 쿼리에서 LEFT JOIN이 불필요하게 들어가서 쿼리들에서 LEFT JOIN을 제거하는게 쿼리 성능에 도움이 된다고 하셨는데요.LEFT JOIN 대신 INNER JOIN을 사용하는 것으로 이해하는게 맞을까요? 제거하라하면 JOIN 자체를 제거하라는 의미인지 헷갈려서 질문 남기게 되었습니다. 감사합니다.

안녕하세요. 강의 마지막에 카테고리별 조회수가 가장 높은 3개 기사를 추출 하는 쿼리 소개해 주셨는데요. 관련해서 질문 있습니다. Q1) 만약 categories 테이블에 id가 1,2,3인 데이터가 있다면 SELECT FROM WHERE category_id = 1 ORDER BY LIMIT 3SELECT FROM WHERE category_id = 2 ORDER BY LIMIT 3SELECT FROM WHERE category_id = 3 ORDER BY LIMIT 3이렇게 3번의 서브쿼리가 실행되고 각 결과를 전부 Union해서 최종 결과를 반환하게 되는건가요?Q2) LIMIT 3을 제거했을 때 내림차순 정렬이 안된 상태로 데이터가 반환되는데요. 그 이유가 뭔지 알 수 있을까요? 

5강 2분50초쯤에 '사용자의 수를 가져오는 함수'를 예시로 설명해 주셨는데요.- 이 Stored Function이 실행되는 순간에도 사용자의 가입은 계속된다.- 그로 인해 이 Stored Function은 호출할 때마다 결과값이 달라질 수도 있다.- 하지만 이러한 사용자 테이블의 레코드가 달라지는 것도 입력이 달라지는 것이라고 생각하기 때문에 MySQL서버에서 SELECT를 포함해서 하나의 Statement는 반드시 시작 시점의 스냅샷을 보도록 구현되어 있다.- 그래서 MySQL서버에서 실행되는 쿼리 문장 하나는 동일한 데이터 상태를 보게 된다.- 따라서 하나의 문장 내에서는 Stored Function이 여러번 호출되더라도 테이블의 데이터는 해당 시점의 스냅샷을 보기 때문에 함수의 인자만 동일하다면 입력이 달라지지 않는 것으로 본다.Q) DETERMINISTIC으로 정의된 함수에 대해서 스냅샷을 바라보도록 설정돼 있고, 이로 인해 함수가 참조하는 데이터(인자)가 변경돼도 그 외 나머지 입력값이 동일하다면 동일한 결과값을 반환하게 된다는 내용이 맞을까요?

안녕하세요deterministic 관련해서 궁금증이 있어 질문드립니다. 그럼 mysql stroed function을 생성할때 무조건 deterministic 으로 생성을 해야하는지요??예를들면, 함수 내에는 파라미터값을 받아서 select 결과값을 도출하는 가령, id값등등 있다고 가정하겠습니다. 그럼 select * from test where 함수('value') 등으로 넣어서 값을 도출받아 where 조건에 걸수있다고 가정해보면non deterministic 일 경우 fullscan을 탈거같은데요. 결론적으로 , 모든 함수를 전부 deterministic 으로 명시를 해줄경우 단점이 무엇인가요?? 감사합니다.