MySQL-모든 필드를 색인화하지 않는 이유는 무엇입니까?
최근에 인덱스의 경이로움을 알게되었고 성능이 크게 향상되었습니다. 그러나 내가 배운 모든 것으로이 질문에 대한 답을 찾을 수없는 것 같습니다.
인덱스는 훌륭하지만 테이블을 엄청나게 빠르게 만들기 위해 모든 필드를 인덱싱 할 수없는 이유는 무엇입니까? 이 작업을하지 않는 좋은 이유가 있다고 확신하지만, 30 필드 테이블에 세 개의 필드는 어떻습니까? 30 필드에 10? 어디에 선을 그려야하며, 그 이유는 무엇입니까?
인덱스는 메모리 (RAM)에서 공간을 차지합니다. 인덱스가 너무 많거나 너무 크면 DB가 인덱스를 디스크와 교환해야합니다. 또한 삽입 및 삭제 시간도 증가합니다 (각 인덱스는 삽입 / 삭제 / 업데이트 된 모든 데이터에 대해 업데이트되어야 함).
당신은 무한한 기억이 없습니다. 모든 인덱스가 RAM에 맞도록 만드는 것이 좋습니다.
무한한 시간이 없습니다. 인덱싱해야하는 열만 인덱싱하면 삽입 / 삭제 / 업데이트 성능 저하가 최소화됩니다.
모든 인덱스는 행이 업데이트, 삽입 또는 삭제 될 때마다 업데이트되어야합니다. 따라서 인덱스가 많을수록 쓰기 작업의 성능이 저하됩니다.
또한 모든 인덱스는 추가 디스크 공간과 메모리 공간 (호출시)을 차지하므로 읽기 작업도 잠재적으로 느려질 수 있습니다 (대형 테이블의 경우). 이것 좀 봐
CRUD 요구 사항의 균형을 맞춰야합니다. 테이블 쓰기가 느려집니다. 선을 그릴 위치는 데이터가 액세스되는 방식 (정렬 필터링 등)에 따라 다릅니다.
인덱싱은 드라이브와 램 모두에서 더 많은 할당 공간을 차지하지만 성능도 많이 향상됩니다. 불행히도 메모리 제한에 도달하면 시스템이 드라이브 공간을 포기하고 성능이 저하됩니다. 실제로는 삽입이나 검색 (WHERE 절)이 아닌 어떤 종류의 데이터 순회 알고리즘과도 관련이 없다고 생각할 수있는 필드를 인덱싱해서는 안됩니다. 하지만 그렇지 않다면해야합니다. 기본적으로 모든 필드를 인덱싱해야합니다. 인덱싱 해제를 고려해야하는 필드는 속도가 필요한 경우를 제외하고 중재자 만 쿼리를 사용하는 경우입니다.
테이블의 모든 열을 인덱싱하는 것은 좋지 않습니다. 이렇게하면 테이블을 매우 빠르게 읽을 수 있지만 쓰기 속도도 훨씬 느려집니다. 모든 열이 인덱싱 된 테이블에 기록하려면 해당 테이블에 새 레코드를 넣은 다음 각 열의 정보를 자체 인덱스 테이블에 넣습니다.
이 대답은 제 개인적인 의견입니다. 저는 수학 논리를 사용하여 대답합니다.
두 번째 질문은 멈출 경계에 관한 것이 었습니다. 먼저 몇 가지 수학적 계산을 해보겠습니다. 모든 필드를 인덱싱하면 테이블에 L 필드가있는 N 개의 행이 있다고 가정하면 모든 테이블이 정렬되는 L 개의 새 인덱스 테이블이 생성됩니다. 의미있는 방식으로 인덱스 필드의 데이터, 테이블이 W 가중치이면 언뜻보기에 W * 2가 될 것입니다 (1 테라가 2 테라가 됨) 큰 테이블이 100 개 있으면 (나는 이미 테이블 번호가있는 프로젝트에서 작업했습니다. arround 1800 table)이 공간의 100 배 (100 테라)를 낭비하게됩니다.
모든 테이블에 인덱스를 적용 할 경우 인덱스 업데이트에 대해 생각해야합니다. 하나의 업데이트 트리거가 모든 인덱스 업데이트입니다.
이 시나리오에서 이번에 느슨해지면 선택이나 업데이트에서 손실하는 것이 바람직하다는 결론을 내립니다. 인덱싱되지 않은 필드를 선택하면 모든 필드에서 다른 선택을 트리거하지 않기 때문입니다. 색인화되지 않음
무엇을 색인할까요?
foreign-keys : 필수
primary-key : 누군가이 글을 읽는 것이이 사건에 도움이 될 수 있을지 아직 확실하지 않습니다.
다른 필드 : 첫 번째 자연 답변은 나머지 필드의 절반입니다. 이유 : 더 많은 색인을 생성해야하는 경우 r 더 적은 색인을 생성해야하는 경우 최상의 답변과 멀지 않습니다. 우리는 색인이 나쁘고 모든 색인이 생성되었음을 알기 때문에 멀지 않습니다. 나쁘다.
이 세 가지 점에서 K 키로 구성된 L 필드가있는 경우 한계는 ((L-K)/2)+KL / 10 정도에 가까운 어딘가에 있어야한다는 결론을 내릴 수 있습니다.
이 대답은 내 논리와 개인적인 원칙에 근거합니다.
참고 URL : https://stackoverflow.com/questions/5446124/mysql-why-not-index-every-field
'IT story' 카테고리의 다른 글
| CDN의 여러 파일 대 로컬 파일 하나 (0) | 2020.09.03 |
|---|---|
| war / WEB-INF 폴더의 리소스에 대한 파일 경로? (0) | 2020.09.03 |
| Html.Textbox VS Html.TextboxFor (0) | 2020.09.03 |
| Windows에서 깊은 node_modules 구조로 Node.js 애플리케이션을 배포하는 방법은 무엇입니까? (0) | 2020.09.03 |
| 배치 파일 : 파일을 읽는 방법? (0) | 2020.09.03 |