eunbinbaeck0088

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

eunbinbaeck0088

Bài viết