인덱스 효율성 측면에서 보면 공동 인덱스가 확실히 더 효율적입니다. 여러 필드를 사용하여 쿼리하는 경우에는 공동 인덱스 사용을 고려해야 합니다. 그러나 상황이 완전히 절대적이지는 않으며 색인 생성에 따른 오버헤드도 고려해야 합니다. 조건을 예로 들어 key가 레코드를 고유하게 결정할 수 있다고 가정하면 parentId을 추가할 필요가 없나요? 한 발 뒤로 물러서 key가 유일하게 하나를 판별할 수 없더라도, 5개 레코드, 10개 레코드 등 특정 작은 범위 내에서 결과 집합을 판별할 수 있다면 parentId 이 조건은 이것에 지나지 않습니다. 10개 레코드를 다시 스캔하여 적절한 레코드를 찾습니다. 인덱스에 추가함으로써 발생하는 쓰기, 저장, 메모리 오버헤드와 비교하면 아예 공동 인덱스에 넣지 않는 것을 선택할 수도 있습니다. 조건에서 필터링할 수 있는 레코드가 많을수록 "선택성"이 더 좋아집니다. 일반적인 상황에서는 인덱스를 구축할 때 선택성이 좋은 조건을 앞쪽에 배치하고 선택성이 나쁜 조건을 뒤쪽에 배치해야 합니다. 충분히 나쁘다면 들여보내지 마세요. 이것은 실제로 시간과 공간의 균형입니다. 인덱스에 입력되는 조건은 저장 시간(CPU 시간, 쿼리 시간 포함)과 공간(저장 공간, 메모리 공간 포함)에 포함되지 않는 조건입니다. 대부분 우리는 전자를 기대합니다. 후자를 선택하는 시기는 실제 상황에 대한 귀하의 평가에 달려 있습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
인덱스 효율성 측면에서 보면 공동 인덱스가 확실히 더 효율적입니다. 여러 필드를 사용하여 쿼리하는 경우에는 공동 인덱스 사용을 고려해야 합니다.
그러나 상황이 완전히 절대적이지는 않으며 색인 생성에 따른 오버헤드도 고려해야 합니다.
조건을 예로 들어
key가 레코드를 고유하게 결정할 수 있다고 가정하면parentId을 추가할 필요가 없나요?한 발 뒤로 물러서
key가 유일하게 하나를 판별할 수 없더라도, 5개 레코드, 10개 레코드 등 특정 작은 범위 내에서 결과 집합을 판별할 수 있다면parentId이 조건은 이것에 지나지 않습니다. 10개 레코드를 다시 스캔하여 적절한 레코드를 찾습니다. 인덱스에 추가함으로써 발생하는 쓰기, 저장, 메모리 오버헤드와 비교하면 아예 공동 인덱스에 넣지 않는 것을 선택할 수도 있습니다.조건에서 필터링할 수 있는 레코드가 많을수록 "선택성"이 더 좋아집니다. 일반적인 상황에서는 인덱스를 구축할 때 선택성이 좋은 조건을 앞쪽에 배치하고 선택성이 나쁜 조건을 뒤쪽에 배치해야 합니다. 충분히 나쁘다면 들여보내지 마세요.
이것은 실제로 시간과 공간의 균형입니다. 인덱스에 입력되는 조건은 저장 시간(CPU 시간, 쿼리 시간 포함)과 공간(저장 공간, 메모리 공간 포함)에 포함되지 않는 조건입니다. 대부분 우리는 전자를 기대합니다. 후자를 선택하는 시기는 실제 상황에 대한 귀하의 평가에 달려 있습니다.