커버링 인덱스에 대해서 질문드립니다.

안녕하세요. 강의 잘 들어주셔서 감사합니다.결론부터 말씀드리면 커버링 인덱스는 하나의 인덱스 안에 SELECT에 필요한 컬럼들이 모두 포함되어 있어야 동작합니다. 각 컬럼에 단일 인덱스가 따로 존재한다고 해서 커버링 인덱스로 처리되지는 않습니다.따라서 질문 주신 예시에서 (id, name) 복합 인덱스는 id가 선두 컬럼이라 name 검색에는 도움이 되지 않기 때문에 이 상황에서는 name 단일 인덱스를 추가하는 것이 맞는 방향입니다. 그리고 검색 결과에 name 외에도 다른 컬럼들이 함께 조회된다면, 해당 컬럼들까지 포함한 복합 인덱스를 만들어 커버링 인덱스로 설계하는 것도 고려할 수 있습니다.다만 검색 기능을 구현해야 하는 경우에는 일반적인 B-Tree 인덱스 보다 별도의 검색 시스템(예: Full-Text Search나 검색 엔진)을 사용하는 방식을 고려하는 것이 일반적인 접근입니다.

인덱스 설계 시 컬럼 선택 기준

안녕하세요, 선택도와 선택성이라는 표현 때문에 오해가 생긴 것 같은데요."선택도가 낮다 = 조건에 맞는 행의 비율이 낮다(명확히 걸러진다) = 선택성이 높다" 라고 생각해주시면 됩니다.

DOCKER 설치 관련 질문입니다

안녕하세요, 지금 사용 중이신 인텔 맥북의 macOS 버전이 Docker Desktop이 요구하는 최소 사양보다 낮아서 설치 자체가 막힌 상황으로 보입니다. macOS 버전을 업데이트하기 어려우신 상황인가요?

FasAPI Swagger UI에서 단일조회 todo_id 를 사용했는데, 입력값에 1을 넣으니 오류가 뜹니다 ㅠ

안녕하세요, 터미널에 출력되는 에러 메시지를 먼저 확인해보시겠어요?

asgi 를 elasticbeanstalk 으로 배포는 어떻게 할수 있을까요?

안녕하세요, 혹시 requirements.txt에 gunicorn을 추가하셨나요?

AI 도구 학습법 문의

안녕하세요, 저 역시 코드 작업에 AI 도구를 적극적으로 활용하고 있습니다. 경험에 비추어 말씀드리면 AI 코딩 도구는 간단한 리팩터링이나 디버깅 및 로깅 추가, 그리고 반복적인 코드 수정과 같은 구조적인 작업에서 특히 효율적입니다. 그러나 데이터베이스 관련 작업이나 구체적인 비즈니스 로직처럼 맥락과 규칙이 중요한 영역에서는 AI가 실수를 할 가능성이 크기 때문에 사람이 직접 설계하고 검토하는 것이 필요합니다. 따라서 실제 코드 작업에서는 Plan 모드를 활용해 접근 방식을 먼저 점검하고, 이후 적극적인 테스트 코드를 작성해 결과를 검증하는 것이 안전하면서도 효과적인 활용 방법이라고 생각합니다.

인덱스 사용 패턴 질문

안녕하세요, 좋은 질문 감사합니다.말씀하신 대로 WHERE status = 'paid' 조건을 통해 이미 결과 집합이 'paid' 값만을 가지게 되므로, GROUP BY status를 하더라도 그룹은 하나만 남게 됩니다. 또한 ORDER BY status 역시 모든 값이 동일하기 때문에 실제 정렬 연산은 발생하지 않습니다. 인덱스 관점에서 보자면 이 경우 GROUP BY와 ORDER BY가 별도의 성능 향상을 주는 것은 아닙니다. 다만 출력 결과 자체는 다를 수 있습니다.예를 들어 status = 'paid'인 레코드가 10개 있다고 할 때, 단순 조회를 하면 10개가 모두 출력되지만, GROUP BY status를 사용하면 반드시 1개의 결과만 출력됩니다. GROUP BY는 결과를 그룹 단위로 축약합니다. 이번 강의에서는 SQL 문법 자체를 깊게 다루지는 않지만, GROUP BY의 기본 동작을 학습해보시면 이해가 더 잘 되실 겁니다.강의에서 강조하고 싶었던 부분은 WHERE, GROUP BY, ORDER BY가 동일한 컬럼을 사용할 경우, 하나의 인덱스로 세 연산을 모두 효율적으로 처리할 수 있다는 점입니다. 특히 ORM이나 쿼리 빌더를 사용할 때 기본적으로 ORDER BY 절이 자동으로 추가되는 경우가 있는데, 이럴 때도 다른 컬럼으로 정렬을 처리하는 것보다는 WHERE 절이나 GROUP BY 절에 사용한 컬럼을 재활용하면, 불필요한 정렬을 줄일 수 있다 정도로 기억해주시면 좋을 것 같습니다.실제 활용 예시로는 집계 함수를 사용하는 경우를 생각해볼 수 있습니다. 예를 들어 주문 데이터를 기준으로 결제가 완료된 주문 금액의 총합을 구하는 경우 다음과 같은 쿼리를 사용할 수 있습니다.SELECT status, SUM(amount) FROM orders WHERE status = 'paid' GROUP BY status ORDER BY status;이 경우에도 ORDER BY는 큰 역할을 하지 않지만, 인덱스를 활용하면 불필요한 정렬 연산이 추가되지 않는다는 장점이 있습니다.

논리적 삭제 적용시 INDEX 생성 전략

맞습니다. 논리적 삭제시 deleted_at 컬럼이 조회에 사용되기 때문에 인덱스를 추가하는 것이 좋습니다.

ConnectionRefusedError: [WinError 10061]

안녕하세요, 이메일 설정 관련해서 settings.py에 어떤 값을 넣으셨는지 알려주실래요?

CSRF_COOKIE_NAME에러

안녕하세요, 혹시 에러 메시지와 코드를 함께 첨부 해주실 수 있을까요? 추가로 settings가 어떻게 import 되고 있는지도 확인 부탁드립니다 :)