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

-- 높은 재귀(반복) 횟수를 허용하도록 설정-- (아래에서 생성할 더미 데이터의 개수와 맞춰서 작성하면 된다.)SET SESSION cte_max_recursion_depth = 1000000; -- 더미 데이터 삽입 쿼리INSERT INTO users (name, age)WITH RECURSIVE cte (n) AS( SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 1000000 -- 생성하고 싶은 더미 데이터의 개수)SELECT CONCAT('User', LPAD(n, 7, '0')), -- 'User' 다음에 7자리 숫자로 구성된 이름 생성 FLOOR(1 + RAND() * 1000) AS age -- 1부터 1000 사이의 랜덤 값으로 나이 생성FROM cte;-- 잘 생성됐는 지 확인SELECT COUNT(*) FROM users; SELECT n + 1 FROM cte WHERE n < 1000000 -- 생성하고 싶은 더미 데이터의 개수SELECT n + 1 이 먼저 실행되고 FROM cte WHERE n < 1000000 이부분이 실행되니까.n이 999999까지 실행되고 n + 1 =1000000 이니까 FROM cte WHERE n < 1000000이부분에 걸려서 1000000이 실행 안되는게 맞지 않나요?

 1.제가 비전공도 할수있는 데이터베이스강의를 듣고 이 강의를 듣고있는데요. user테이블에 name의 fk가 들어가는게 맞지 않나요? 빨간색 글씨로요. name id pk도 빨간색처럼 pk를 적어야 하지 않나요?아니면 name테이블과 name인덱스 테이블이 따로 있는건가요?2.인덱스가 새로운 테이블을 생성하는건가요?3.풀인덱스스캔 강의 질문있습니다.CREATE INDEX idx_name ON users (name); 이 구문이아래처럼 테이블을 미리 만드는건가요? 

만약 응답해야 되는 데이터는 "많은" 데이터인데데이터베이스에서 조회할 때는 LIMIT, WHERE로 나눠서 가져오고 애플리케이션 로직에서 합쳐서 응답하는게 나은가요?아니면 네트워크를 여러번 타는 것 보다는 이런 경우에는 한번에 가져오는게 더 나을까요?상황에 따라 다르겠지만,, 참고할만한 지침같은게 있을까 싶어서 여쭤봅니다!

EXPLAIN ANALYZE SELECT * FROM users ORDER BY salary LIMIT 100; -> Limit: 100 row(s)  (cost=100569 rows=100) (actual time=338..338 rows=100 loops=1)    -> Sort: users.salary, limit input to 100 row(s) per chunk  (cost=100569 rows=996636) (actual time=338..338 rows=100 loops=1)        -> Table scan on users  (cost=100569 rows=996636) (actual time=0.0672..250 rows=1e+6 loops=1)        CREATE INDEX idx_salary ON users (salary); EXPLAIN ANALYZE SELECT * FROM users ORDER BY salary LIMIT 100; -> Limit: 100 row(s)  (cost=0.0918 rows=100) (actual time=0.0709..0.253 rows=100 loops=1)    -> Index scan on users using idx_salary  (cost=0.0918 rows=100) (actual time=0.0692..0.249 rows=100 loops=1)  여기서 질문이 있는데요. 인덱스를 salary에 적용한 이후에도 analyze이후 actual time이 인덱스가 없을때와 별차이가 없어 보이는데요. 이건 mysql의 실행계획 표시에 오류가 있는걸까요?실제로 실행 속도는 향상은 돼었습니다. 

SELECT e.emp_id , s.avg_salary , s.max_salary , s.min_salary FROM EMP e, (select emp_id, ROUND(AVG(annual_salary), 0) avg_salary, ROUND(MAX(annual_salary), 0) max_salary, ROUND(MIN(annual_salary), 0) min_salary from SALARY where emp_id BETWEEN 10001 and 10100 GROUP BY emp_id) s WHERE e.emp_id = s.emp_id; 처음에 답을 안 보고 제가 개선해본 쿼리인데,필터링 조건을 salary에 넣어주고, 이걸 조인해서(emp의 primary key) 나오는 결과인데 미세하게 더 빠르네요.!  정답 쿼리가 조금 더 느린 이유는 salary 테이블을 3번 접근해서 그런거 같은데(index를 활용하더라도) 맞는지 궁금합니다.

SELECT REGION, GATE, COUNT(*) AS cntFROM ENTRY_RECORDWHERE REGION <> ''GROUP BY REGION, GATE WITH ROLLUP; -- 414ms ROLLUP 사용법이 달라서 구글이나 지피티에 서칭을 해봤습니다. 저처럼 안 되시는 분이 많을 거 같아서 올립니다.

학습 환경은docker + mariadb 입니다.! 현재 힌트를 사용해서 Manager 테이블의 인덱스를 강제시켜서 실행시켰는데 다음과 같이 table full scan으로 변환되었습니다. 이거는 mariadb 내부적으로 hint가 올바르지 않다고 생각해 실행 계획을 바꾼걸까요?EXPLAIN SELECT e.FIRST_NAME, e.LAST_NAMEFROM EMP e,MANAGER m FORCE INDEX (PRIMARY)WHERE e.EMP_ID = m.EMP_ID ; 

SELECT EMP.emp_id, EMP.first_name, EMP.last_name, GRADE.grade_nameFROM GRADE, EMP; -- 카테시안 곱 mariadb로 실습을 진행했는데 hash join이 쓰이는게 아니라flat, BNL join을 사용한다고 되어 있네요?BNL Join은 MySQL이 인덱스가 없거나 사용할 수 없는 상황에서 기본적으로 사용하는 비효율적인 조인 알고리즘이라는데 원인이 무엇일까요?grade 테이블을 hash join table로 사용하지 않네요?

안녕하세요.  강의에서 k6를 실행하기 위해 30명의 가상유저가 10초동안 요청을 무한히 보내도록 설정하셨습니다. 그 결과 http_reqs 값이 1.66/s 가 나왔습니다. 이 값은 시스템의 대역폭 max값으로 이해해도 되나요?30명, 10초 설정값이 아니더라도 100명, 10초 설정값으로 진행해도 1.66/s 에 근사한 값이 나와야하는지 궁금합니다. (시스템이 처리할 수 있는 능력 의 Maximum은 항상 일정해야하지 않을까 라는 생각에 질문드립니다.) 

having에 있는 쿼리문을 where문으로 바꿔서 최적화 시키는 것은 이해가 갔습니다. 강의에는 인덱스 사용이 없어서 제가 한번 적용시켜보려고 멀티 컬럼(year, semester) 이렇게 넣고 explain 해보니 ref와 eq_ref가 떴는데도 불구하고 속도는 차이가 별반 다를게 없네요(2초 후반)인덱스를 어떻게 넣어야할지 알려주시면 감사합니다

안녕하세요. 우선 좋은 강의 만들어주셔서 정말 감사합니다 :)select_type 에서 'simple' 경우 각각의 테이블이 '드라이빙' 또는 '드리븐' 인지 어떻게 알수 있나요? 5-2. 실행계획 항목(1) -> 05:40 영상을 확인해보면 실행계획에서 table 필드 값 "e" 하고 "s" 가 있는데요.여기서 질문 2가지가 있습니다.질문1: 여기서 각각의 테이블이 '드라이빙' 또는 '드리븐' 인지 어떻게 알수 있나요?(실행 계획 통해 조회된 데이터 순서대로 판단하면 되는것인지... 궁금하네요.. 그런데 이걸로 100% 판단하기에 조금 어렵다고 들어서요...)질문2:만약 테이블 "e" 가 드라이빙 테이블이라고 가정시실질적으로 쿼리 수행할때 테이블 "e" 에 대한 where 절 조건을 이용해서 먼저 필터링 한다음에테이블 "s" 하고 조인 수행을 하는것인지 궁금 합니다.즉 드리아빙 테이블 조건절 이용해서 최대한 필터링 하고그다음 드이븐 테이블하고 조인을 수행하는지 궁금합니다.  

GenericJackson2JsonRedisSerializer를 사용할 때 저장되는 캐싱 데이터는 다음과 같았습니다."[{\"@class\":\"org.example.package..\",\"id\":\"123984\",\"title\":\"title0123984\",...,강의상에 나온 데이터 순서?? 와는 조금 다르게 package 다음에 @class 이후 데이터가 저장되는 구조가 나오는 것을 확인했습니다.이때 캐싱된 데이터를 조회하려고 하는데 com.fasterxml.jackson.databind.exc.MismatchedInputException: Unexpected token (START_OBJECT), expected VALUE_STRING: need String, Number of Boolean value that contains type id (for subtype of java.lang.Object) 에러가 발생했습니다.너무 궁금해서 GenericJackson2JsonRedisSerializer에 대해서 알아보고 있는데, 여전히 에러가 발생하는 이유를 잘 모르겠습니다ㅜㅜ데이터가 캐싱되어서 저장될 때 구조가 다르게 들어가는 이유가 궁금합니다   아 물론 강의 후반부처럼 Jackson2JsonRedisSerializer를 사용했을 때는 정상적으로 동작했습니다.

5:12분경 createdAt에서 @CreatedDate를 제외한 나머지 어노테이션들을 특별히 사용하신 이유가 있으실까요?

안녕하세요 레디스를 공부하면서 궁금한게 있습니다.제가 토이프로젝트를 하면서 상품 검색 입력시 버튼 하나씩 누를때마다(이벤트 keyup 사용) 백엔드와 통신하여 입력창 하단에 자동완성 기능창을 만들려고 하고 있습니다.아무래도 버튼 하나씩 누를때마다 통신해야되니 빠르게 통신해야될 것 같아서 redis를 사용했습니다.상품 등록할 때 DB와 redis에 저장하고 (redis에는 상품 이름만 저장했습니다.)입력창 하단의 자동완성은 redis를 통해 상품 이름을 출력하고 출력된 상품이름을 선택시 DB를 통해서 상품 상세정보를 가져오는 식으로 했는데배운대로라면 Cache Aside 전략과 다른데 이럴때는 어떻게 구성해야되나요?아니면 SQL 튜닝만 잘해도 굳이 redis는 필요없는건지 궁금합니다.아무래도 버튼 누를때마다 통신하다보니 SQL은 느릴까봐 싶어 조바심이 나네요ㅠㅠ 알아보니 최근검색어나 인기검색어 같은 경우도 redis로 한다고하는데 이런것들도 굳이 출력하자면 DB로만 사용하여 출력이 될텐데 이게 Cache Aside 전략과 어떤 관계가 있는지 감이 안잡힙니다실무뛰면서 redis를 써본적이 없고 거의 db로만 해결하다보니 redis 사용예시를 잘 모르겠습니다

안녕하세요~!강의에 오타가 있는 것 같아서 질문 드립니다.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);

안녕하세요. 강의 잘 들었습니다.강의를 듣다보니 의문이 드는 점이 있어 질문드립니다.redis를 사용하다 보면 redisinsight같은 gui 툴을 통해 데이터를 확인하는데 운영관점에서 더 편한데요.aws elasticcache redis가 외부 로컬에서 접속이 안되면aws elasticcache는 데이터 확인을 툴로 못하는건가요? 실무에서 운영을 하다보면 분명 직접 데이터를 체크를 해야하는 케이스가 발생하는데 이걸 일일이 cli 명령어 찾는다는 것은 돈을 주고 aws 사용하는 고객입장에서는 너무 불편하다고 생각들어 문의드립니다.

안녕하세요. 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이 발생하는 것이고요