DB 쿼리를 설계하면서 항상 궁금했던 점이 있습니다. 쿼리가 점점 복잡해지다 보면 Sort , GROUP BY 등의 연산을 DB에서 처리하는 것보다, 데이터를 애플리케이션으로 가져온 후 애플리케이션에서 처리하는 것이 더 효율적이지 않을까 하는 생각이 들 때가 있습니다. 그렇다면 일반적으로 DB 쿼리를 최적화할 때는 애플리케이션으로 데이터를 가져와 처리하기보다는, 적절한 Index 설계를 통해 가능한 한 DB에서 연산을 처리하는 것이 맞는 방향일까요? 아니면 상황에 따라서는 필요한 데이터를 DB에서 조회한 후, 일부 연산을 애플리케이션에서 처리하는 것도 하나의 최적화 방법이 될 수 있을까요? 제가 생각하는 방향 자체가 잘못된 것인지, 아니면 실제로 상황에 따라 고려할 수 있는 방법인지 궁금해서 질문드립니다.
안녕하세요 영한님! 강의에서 말씀해 주신 것처럼, 인덱스를 생성한다고 해서 항상 옵티마이저가 해당 인덱스를 사용하는 것은 아니라는 점은 이해했습니다. 그렇다면 실무에서는 특정 인덱스를 어떤 쿼리나 사용 패턴을 고려해서 만들었는지, 그리고 어떤 의도로 설계했는지를 별도로 기록하거나 관리하는 방법이 있을까요? 예를 들어 시간이 지나 다른 개발자가 인덱스를 보더라도, “이 인덱스는 특정 조회 쿼리의 성능을 개선하기 위해 만들었다”와 같은 설계 의도를 파악할 수 있도록 관리하는지가 궁금합니다. 설계 1편에서 소개해 주신 용어 사전처럼 별도의 문서나 규칙을 두고 관리하는 방법이 있는지, 혹은 실무에서 일반적으로 사용하는 다른 방법이 있는지도 궁금합니다!
[질문 내용] 여기에 질문 내용을 남겨주세요. 저는 1번문제에서 FK -> PK 로풀었습니다 영한님은 PK -> FK 로 푸셨던것에 질문입니다. FK -> PK는 항상 다대일으로 e.managed_id가 가리키는 PK 행은 0~1개라서 조인해도 왼쪽 테이블 행이 늘지 않아서 왼쪽 테이블이 행을 정하고, 조인은 컬럼만 붙인다고 생각했습니다. PK -> FK는 일대로써 한 행이 여러 행으로 늘어나는데, 그럼 on 조건까지 다 읽어야 이해되지 않을까 해서 여쭤봅니다. select e.employee_id, e.name, e.managed_id, m.name as manager_name from employees e join employees m on e.managed_id = m.employee_id where m.name = '최과장';
김영한의 실전 데이터베이스 입문 - 모든 IT인을 위한 SQL 첫걸음(SQL부터 차근차근)
리뷰를 남기라고 하셨는데...리뷰를 어디에 남기는지 모르겠네요... 에너지 회사에서 시황 데이터와 거래 데이터를 많이 다루는 50대 입니다....sql말만 듣고 동영상 듣기까지 한 10년 정도 걸린거 같네요.. 도메인 지식만 가지고 최근 ai의 도움으로 여기까지 오게 되었습니다. 선생님 다른 강의도 잘 보겠습니다. ^^
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. 강의안 제목은 외부 조인이지만 앞에서 내부 조인 얘기를 함께 하기도 하고 명령어도 단순히 JOIN(내부)로 사용하셔서 부모가 자식과 조인을 할 때 행 개수는 유지되거나 증가할 수 있다는 얘기를 이해하기 힘들었습니다. 내부 조인의 경우에는 행이 감소할 수도 있으니까요 강의안 '조인의 특징' 섹션 내 코드의 JOIN 명령어들을 LEFT JOIN으로 변경 또는 외부 조인의 특징이라고 명시해주시면 더 정확할 거 같아요. 섹션 제목이나 본문에 어디에도 '조인'이라고만 나와있어서..ㅠㅠ 당연한 얘기인데도 많이 헷갈렸어요 심지어 내부 조인 명령어를 썼는데도 행 개수가 감소하지가 않는 예시들이어서요
안녕하세요~ 강의 수강중 통계정보 갱신에 대해 여쭤보고싶은게 있습니다. 운영중에 간혹가다 옵티마이저가 실행계획을 잘못 선택해서 쿼리를 실행해서 슬로우 쿼리가 발생되는 경우가 종종있었습니다. 이때 use index 를 사용해서 주로 해결했었는데 이번 강의에서는 문제가 되는 테이블의 통계정보를 갱신하면 이런 문제들이 해결된다고 하시던데 운영중인 db 에 통계정보 갱신을 했을때 트레이드 오프같은게 없을까요? 실무에서 보통 어떻게 하셨는지 궁금하네요.
안녕하세요! PK 설계와 관련하여 궁금한 점이 있어 질문드립니다. 강의에서는 AUTO_INCREMENT 를 사용하면 PK가 순차적으로 증가하기 때문에 랜덤한 위치에 데이터가 삽입되는 것을 줄이고, 페이지 분할을 최소화할 수 있어 사용을 권장한다고 이해했습니다. 그런데 한편으로는 MSA 환경에서 PK로 UUID를 많이 사용한다는 이야기를 들었습니다. UUID를 사용하면 각 서비스에서 ID를 독립적으로 생성할 수 있다는 장점이 있다고 하는데, 서비스별로 데이터베이스와 테이블이 분리되어 있다면 각 테이블의 PK는 해당 테이블 내에서만 유일하면 되기 때문에 AUTO_INCREMENT 를 사용해도 문제가 없지 않을까 생각했습니다. 그래서 다음 내용이 궁금합니다. 실제 MSA 환경에서는 일반적으로 PK로 UUID를 많이 사용하는지 UUID 사용으로 인한 인덱스 크기 증가와 페이지 분할 등의 단점보다 UUID의 장점이 더 커지는 판단 기준은 무엇인지 찾아보니까 시간 순서 특성이 있는 UUID v7 라는 것도 있는데 이를 사용하는 건지 이런 궁금증이 생기는데 시원하게 해결이 되지 않아서 질문으로 남깁니다. 항상 좋은 강의 올려주셔서 감사합니다. 다음 강의에 해당 내용에 대한 설명이 다 있는 것을 확인하였습니다. 감사합니다!
커버링 인덱스가 아니라고 가정한다면 클러스터링 인덱스까지 2번의 B+Tree 탐색을 하지만 커버링 인덱스라면 이런 탐색을 한번 줄여 발생하는 IO 작업을 최적화 하는것으로 이해 했습니다 커버링 인덱스 말고도, 자주 사용되는 페이지의 위치를 자동으로 InnoDB에서 어댑티브 해시 인덱스라는 공간에 저장 하는것으로 알고 있는데 이 방식도 IO 작업을 최적화 하는 것인지 궁금 합니다
