14분44초에 쿼리 질문드립니다.

안녕하세요!우선 14분 44초 화면에서 보여지는 쿼리는 payments 테이블에 대한 쿼리인데요. 그 아래 적어주신 쿼리는 posts 테이블에 대한 쿼리다보니 정확히 어떤 부분을 궁금해하시는건지 파악하기에 어려움이 있습니다. 😢이 부분 한번 확인 후 다시 질문해주시면 해당 내용을 바탕으로 설명드릴게요!수강해주셔서 감사합니다.

LEFT JOIN 시 드라이빙 테이블을 왜 ALL로 읽나요?

안녕하세요! 답변이 늦었습니다.쿼리에 user 테이블에 대한 조건이 없고 또 말씀해주신 것처럼 쿼리의 SELECT 절에 id 컬럼 뿐만 아니라 name 컬럼도 포함되었기 때문에 ALL 이라는 실행계획이 나온것으로 보여집니다.관련해서 추가적으로 궁금한 부분 있으시면 언제든지 말씀해주세요.수강해주셔서 감사합니다. 🙂

ep12. (2) LEFT JOIN 사용 방법 준수 - 오타 질문

안녕하세요! 답변이 늦어져서 죄송합니다.user 테이블은 유저의 이름을 포함한 기본적인 유저 정보가 저장되는 테이블이고, user_attribute 테이블에는 추가적인 유저의 속성 정보들이 저장되는 테이블이라고 보시면 됩니다.user_attribute 테이블에는 속성명(name)/속성값(value) 쌍으로 데이터가 저장되고, 쿼리에서는 유저의 주소 정보를 가져오기 위해 where 절에 ua.name='address' 조건을 사용하는 것이라고 봐주시면 되어요.그럼 추가로 더 궁금한 부분 있으시면 언제든지 말씀해주세요.수강해주셔서 감사합니다. 🙂

LIMIT, OFFSET을 사용하는 것과 범위 기반 방식의 성능 차이

안녕하세요.말씀하신 것처럼 users 테이블에 id가 인덱스로 지정돼있는 상황이라고 보시면 됩니다. 이 경우 범위 기반 방식 형태로 쿼리를 수행하면 조건에 만족하는 데이터만 읽게되므로, OFFSET이 증가할 수록 불필요하게 데이터를 많이 읽는 LIMIT & OFFSET 방식보다는 더 나은 것입니다.예를 들어, 동일하게 users 테이블에 id가 PK라고 가정하고, id가 1부터 10000까지의 데이터를 1000개씩 나눠서 조회한다고 가정해볼게요.LIMIT & OFFSET 방식의 경우 다음과 같이 쿼리를 실행하게 됩니다.1) SELECT * FROM users WHERE id > 0 AND id 0 AND id 0 AND id 반면, 범위 기반 방식의 경우 다음과 같이 쿼리를 실행하게 됩니다.1) SELECT * FROM users WHERE id > 0 AND id 1000 AND id 2000 AND id LIMIT & OFFSET 방식에서 첫 번째 쿼리는 1000개 데이터만을 읽지만, 두 번째 쿼리는 2000개, 세 번째 쿼리는 3000개로 점점 쿼리 처리 시 읽는 데이터 양이 늘어납니다.하지만 범위 기반 방식의 경우 쿼리 조건절에 아예 1000개씩 나눠진 범위가 조건으로 주어졌기 때문에, 각 쿼리마다 조건에 만족하는 1000개의 데이터만 읽게됩니다.결론적으로, 인덱스 사용 유무에 따른 차이라기 보다는 LIMIT & OFFSET은 실제 읽어야 하는 시작지점(OFFSET)을 찾기위해 조건에 만족하는 데이터를 정렬 순서대로 순차적으로 읽어서 시작지점을 찾은 후 LIMIT 절에 해당되는 건수만큼 추가로 더 읽게 되서 범위기반보다 성능이 더 좋지 않다고 볼 수 있습니다.질문 주셔서 감사하고, 추가로 궁금한 부분 있으시면 언제든지 다시 말씀해주세요.수강 감사드립니다. :)

2강. VARCHAR(255) 저장되는 데이터의 길이 정보 질문

안녕하세요. 답변이 늦었습니다.우선 VARCHAR 타입에서 데이터 길이 정보는 저장된 데이터가 255 바이트일때까지는 1바이트, 그 이상의 경우 2바이트가 할당됩니다. 그리고 VARCHAR(255)에서 255는 문자의 길이를 나타내며, 저장되는 바이트 수를 제한하는 것이 아닙니다.그렇기 때문에 질문주신 부분은 하나의 문자를 저장하는 데 몇 바이트를 필요로 하는지에 따라 달라진다고 볼 수 있으며, 이는 문자집합(Character Set)과 연관이 되어있습니다.만약 컬럼이 문자 당 1바이트씩 사용하는 latin1 문자집합으로 설정돼있다면, 말씀하신 것처럼 VARCHAR(30)과 VARCHAR(255) 모두 저장되는 데이터의 길이 정보가 1바이트일 수 있습니다. 그런데 만약 문자 당 1바이트 이상 사용하는 다른 문자집합이라면 VARCHAR(255)는 데이터의 길이 정보로 2바이트를 가지게 됩니다.구체적으로 utf8mb4 문자집합의 경우 최대 한 문자당 4바이트를 사용할 수 있는데요. 이 경우에는 VARCHAR(64)부터 데이터 길이 정보로 2바이트를 가질 수 있다고 보시면 됩니다.좋은 질문 주셔서 감사하고, 추가로 궁금한 부분 있으시면 언제든지 다시 말씀해주세요. :)수강 감사드립니다.

[오타 제보] 선행 데이터를 기반으로 한 데이터 분석

안녕하세요! 말씀하신 것처럼 e2 서브쿼리의 SELECT 절에 user_id 부분이 누락되었네요.강의에는 메모로 남겨두겠습니다.오타 제보 감사합니다!

6강. Top N 데이터 조회와 관련해 질문있습니다.

안녕하세요. 답변이 좀 늦었습니다.질문주신 내용들에 대해 각각 답변을 드리면,Q1) 만약 categories 테이블에 id가 1,2,3인 데이터가 있다면, 3번의 서브쿼리가 실행되고 각 결과를 전부 Union해서 최종 결과를 반환하게 되는건가요?대략 말씀하신 형태로 동작한다고 보시면 되는데요, 독립적으로 실행되는 서브쿼리보다는 조인과 같은 형태로 처리된다고 생각해주시면 좋을 것 같습니다.Q2) LIMIT 3을 제거했을 때 내림차순 정렬이 안된 상태로 데이터가 반환되는데요. 그 이유가 뭔지 알 수 있을까요?이건 쿼리의 실행계획을 봐야하는데요. LIMIT 절이 있을 때는 (category_id, views)로 구성된 인덱스를 뒤에서부터 읽다보니(Backward index scan) 내림차순 정렬로 데이터가 반환됐지만 LIMIT 절이 없는 경우에는 해당 인덱스를 정순으로 스캔하면서 데이터를 읽어와서 오름차순 정렬인 것으로 예상됩니다.사실 이 부분은 현재 제일 바깥쪽 쿼리에 ORDER BY 절이 없기때문에, 쿼리 처리 방식에 따라 최종적인 결과 데이터의 정렬 순서가 예상한 것과는 다를 수 있습니다. 그래서 어떻게 처리되던지 항상 내림차순 정렬을 원하시면 제일 바깥쪽 쿼리에 ORDER BY 절을 명시해주시는 것이 좋습니다. 답변 읽어보시고 혹시 더 추가로 궁금한 부분 있으시면 말씀해주세요!감사합니다.

12강. LEFT JOIN 사용 방법 준수 5:42

안녕하세요.문의주셨던 부분 관련해서 제가 말씀드리고자 했던 요지는LEFT JOIN을 굳이 사용하지 않아도 되는 경우에는 JOIN을 제거본래 목적이 LEFT JOIN이 아닌 INNER JOIN이 맞다면, 명시적으로 INNER JOIN으로 변경입니다!혹시 추가로 궁금한 부분 등이 있으시면 편하게 말씀해주세요.감사합니다.

JPA 사용시 테이블수정에 궁금한점이있습니다

안녕하세요.사용하시는 컬럼에 저장될 수 있는 값의 최대 길이를 비교적 명확하게 파악하고 계신 상황이라면(혹은 파악하실 수 있는 상황이라면), 강의에서 설명드린 것과 같이 DB 서버 자원 사용 효율을 위해 모든 문자열 컬럼들을 VARCHAR(255)로 사용하시기 보다는 실제 사용되는 길이만큼만 지정해서 사용하시는 것을 권고드립니다.감사합니다.

복합인덱스 정렬

안녕하세요.테이블에 (finished_at, id)로 구성된 인덱스가 있다고 가정했을 때, 공유해주신 쿼리가 실행되면 인덱스 데이터에서 finished_at이 '시작날짜' 값 이상인 데이터들을 쭉 스캔하면서 id > 8인 데이터들을 확인하고 이렇게 확인된 데이터가 LIMIT 절에 주어진 30건을 만족하면 쿼리는 종료됩니다.LIMIT 절이 주어지지 않으면 말씀하신 것처럼 기본적으로 finished_at 컬럼에 주어진 조건 범위로 인덱스 데이터를 전부 스캔할 것으로 예상합니다. 쭉 스캔하면서 id 컬럼에 주어진 조건을 만족하는지 추가로 확인하게 됩니다.그리고 이러한 동작 방식은 id 컬럼에 대한 조건이 범위 조건이 아니고 동등조건이라 하더라도, 인덱스의 선두 컬럼인 finished_at 컬럼에 대해 범위 조건이 주어졌기 때문에 동일하게 동작합니다.그럼 추가로 궁금한 부분 있으시면 다시 말씀해주세요.감사합니다.