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 컬럼에 대해 범위 조건이 주어졌기 때문에 동일하게 동작합니다.그럼 추가로 궁금한 부분 있으시면 다시 말씀해주세요.감사합니다.

LATERAL 키워드는 mysql8 에서 잘 지원 되나요?

안녕하세요.MariaDB에서는 쿼리에서 LATERAL 키워드 사용이 불가하고, 내부적으로 Lateral Derived 최적화를 지원하는 것으로 보입니다.저희 강의 내용은 MySQL 8.0을 기반으로 하므로, 강의에서 소개된 기능 등을 테스트하실 때는 가능하시다면 MySQL 8.0 버전대를 설치해서 테스트해봐주시면 좋을 것 같습니다.추가로 궁금한 부분 있으시면 다시 말씀해주세요.감사합니다.

안녕하세요. 인덱스 관련 질문 있습니다.

안녕하세요. 답변이 늦었습니다.인덱스가 (account_type, joined_at)과 같이 존재할 때, 쿼리 WHERE 절에는 (joined_at, account_type) 순서로 조건이 주어졌다고해서 인덱스를 활용하지 못하는 것은 아닙니다.인덱스를 구성하는 컬럼들이 모두 조건으로 주어져있기 때문에 인덱스는 당연히 사용이 가능합니다.쿼리 WHERE 절에 나열된 순서가 인덱스 내 컬럼 순서와 다르더라도 MySQL 옵티마이저는 인덱스를 사용할 수 있는 조건들을 추려내서 인덱스를 활용하는 최적화를 수행하기 때문에, 순서는 크게 중요하지 않고 인덱스를 구성하고 있는 컬럼들이 조건으로 주어져 있는지가 더 중요하다고 봐주시면 좋을 것 같아요.그리고 추가적으로 쿼리에서 컬럼들에 주어진 조건 형태에 따라 인덱스 내 컬럼 순서가 쿼리 처리 효율에 영향을 줄 수 있는데요.예를 들어, 아래와 같이 쿼리에서 인덱스를 구성하는 컬럼들 모두 동등 조건으로 조건값이 주어진 경우에는 인덱스 내의 컬럼 순서는 어떤 순서든 크게 상관이 없습니다.SELECT * FROM tab1 WHERE account_type = ? AND joined_at = ?그러나 아래와 같이 joined_at이 동등 조건이 아닌 범위 조건으로 사용된 경우에는, 인덱스 내 컬럼 순서가 (account_type, joined_at) 인 것이 좋습니다.SELECT * FROM tab1 WHERE account_type = ? AND joined_at >= ? AND joined_at (account_type, joined_at) 으로 인덱스가 구성돼있는 경우, 쿼리 처리 시 인덱스에서 실제 조건에 만족하는 인덱스 데이터들만 스캔하지만, (joined_at, account_type) 순서로 인덱스가 구성돼있는 경우 인덱스 선두에 위치한 joined_at 조건 범위에 속한 인덱스 데이터를 모두 스캔하게 되기 때문입니다.관련해서 모든 내용을 댓글로 다 설명드리기는 어려워서.. 혹시 Real MySQL 8.0 책 1권을 가지고 계시다면, "8.3.7.1 비교 조건의 종류와 효율성" 부분을 읽어보시는 것을 추천드립니다.추가로 궁금한 부분 있으시면 다시 말씀해주세요.감사합니다.

LATEAL 사용 관련 질문

안녕하세요. 답변이 늦었습니다.일단 질문 주신 내용으로 미루어보았을 때, 일반 서브쿼리와 Lateral Derived Table을 동일한 서브쿼리 형태로 인지하고 계신 것 같은 느낌을 받았는데요.일반 서브쿼리와 Lateral Derived Table은 사용 형태과 처리 방식이 완전히 다릅니다. 특히나 Lateral Dervied Table은 조인 형태로도 사용할 수 있고, 이로 인해 일반 서브쿼리 보다 유연한 쿼리 작성이 가능하고 DB 내부적으로도 좀 더 최적화된 형태로 처리될 수 있습니다. 그래서 제 개인적으로는 언급해주신 권장 사항들이 어떤 경우든 항상 옳다고 볼 수는 없을 것 같아요.Lateral을 사용하면 좋은 대표적인 경우들에 대해서는 제가 강의에 언급해둔 터라, 강의에 나와있는 예시들을 참고해주시면 좋을 것 같습니다.혹시 추가로 더 궁금한 부분 있으면 다시 말씀해주세요!감사합니다.

파티셔닝의 자원 사용 효율 증가 관련 질문

안녕하세요.말씀하신 것처럼 파티셔닝키에 인덱스를 생성하고 해당 인덱스를 통해 특정 범위에 해당하는 데이터만 주로 접근한다면 테이블을 파티셔닝하지 않더라도 자원을 어느정도 효율적으로 사용할 수 있을 것으로 예상합니다.예를 들어, 로그 데이터가 저장되는 테이블에 생성 일자 컬럼(e.g. created_at)에만 인덱스를 생성하고 생성 일자 컬럼 기반으로만 데이터를 조회하는 경우가 이에 해당됩니다.하지만 일반적으로는 이와 같이 아주 간단한 형태보다는 좀 더 복잡한 형태로 테이블을 사용하고, 테이블에서 다양한 쿼리들을 사용함에 따라 보조 인덱스들도 많이 존재하게 되는데요.파티셔닝하지 않은 일반 테이블의 경우, 특히나 데이터가 많이 저장돼있다면 이와 같은 인덱스들에 대한 유지보수 비용이 파티셔닝하지 않은 테이블에 비해 클 수 있습니다. 일반 테이블에서는 하나로 통합된 거대한 인덱스로 존재하지만, 파티션 테이블의 경우 각 파티션 별로 인덱스가 나뉘어져 있기 때문입니다.그래서 앞서 얘기드렸던 것과 같은 아주 간단한 형태로만 테이블을 사용하신다고 했을 때는, 데이터 삭제 등과 같은 부분을 고려해서 테이블 파티셔닝 적용 유무를 결정해주시면 좋을 것 같고, 좀 더 다양한 액세스 패턴으로 테이블을 사용하는 경우라면 주로 사용되는 패턴들을 중점적으로 고려해서 파티셔닝을 적용했을 때 얻을 수 있는 이점과 단점들을 비교해보고 최종적으로 결정해주시면 좋을 것 같습니다.테이블에 파티셔닝을 적용하는 것이 좋을지는 쉽게 결정할 수 있는 경우도 있겠지만 그렇지 않은 경우들도 많고, 사실 실무에서는 DB를 운영/관리하고 있는 상황이나 기타 다른 요구사항 등 고려해야할 부분들이 많기 때문에 답변드린 내용이 다소 형식적이라고 느끼실 수 있을 것 같은데, 혹시 추가로 더 궁금한 부분 있으시면 언제든지 편하게 문의주세요.감사합니다.

복합 인덱스의 컬럼중 선행 컬럼을 조건에서 누락해도 인덱스가 사용될 수도 있나요?

안녕하세요. 벌써 2회차시라니! 열심히 수강해주셔서 감사합니다. 😊문의주신 내용 관련해서는, 혹시 테스트하신 users 테이블 스키마를 좀 알 수 있을까요?테스트하신 테이블이 혹시 id, account_type, joined_at 이렇게 세 컬럼으로만 구성돼있었던건지 확인이 필요해서 여쭤봅니다.

SKIP LOCKED 부분에서 INNER JOIN이 아니고 LEFT JOIN이 걸릴수 있다면

안녕하세요.궁금하신 부분이 강의에 나와있는 예제는 INNER JOIN이 사용된 쿼리이지만, LEFT JOIN을 사용하는 쿼리에서는 SKIP LOCKED가 어떻게 동작하는건지 그 부분이 궁금하신거 맞을까요?