최근에 인덱스의 경이로움을 알게되었고 성능이 크게 향상되었습니다. 그러나 내가 배운 모든 것으로이 질문에 대한 답을 찾을 수없는 것 같습니다.
인덱스는 훌륭하지만 테이블을 엄청나게 빠르게 만들기 위해 모든 필드를 인덱싱 할 수없는 이유는 무엇입니까? 이 작업을하지 않는 좋은 이유가 있다고 확신하지만, 30 필드 테이블에 세 개의 필드는 어떻습니까? 30 필드에 10? 어디에 선을 그려야하며, 그 이유는 무엇입니까?
최근에 인덱스의 경이로움을 알게되었고 성능이 크게 향상되었습니다. 그러나 내가 배운 모든 것으로이 질문에 대한 답을 찾을 수없는 것 같습니다.
인덱스는 훌륭하지만 테이블을 엄청나게 빠르게 만들기 위해 모든 필드를 인덱싱 할 수없는 이유는 무엇입니까? 이 작업을하지 않는 좋은 이유가 있다고 확신하지만, 30 필드 테이블에 세 개의 필드는 어떻습니까? 30 필드에 10? 어디에 선을 그려야하며, 그 이유는 무엇입니까?
답변:
인덱스는 메모리 (RAM)에서 공간을 차지합니다. 인덱스가 너무 많거나 너무 크면 DB가 인덱스를 디스크와 교환해야합니다. 또한 삽입 및 삭제 시간이 늘어납니다 (각 인덱스는 삽입 / 삭제 / 업데이트 된 모든 데이터에 대해 업데이트되어야 함).
당신은 무한한 기억이 없습니다. 모든 인덱스가 RAM에 맞도록 만드는 것이 좋습니다.
무한한 시간이 없습니다. 인덱싱해야하는 열만 인덱싱하면 삽입 / 삭제 / 업데이트 성능 저하가 최소화됩니다.
모든 인덱스는 행이 업데이트, 삽입 또는 삭제 될 때마다 업데이트되어야합니다. 따라서 인덱스가 많을수록 쓰기 작업의 성능이 저하됩니다.
또한 모든 인덱스는 추가 디스크 공간과 메모리 공간 (호출시)을 차지하므로 읽기 작업도 잠재적으로 느려질 수 있습니다 (대형 테이블의 경우). 이것 좀 봐
CRUD 요구 사항의 균형을 맞춰야합니다. 테이블 쓰기가 느려집니다. 선을 그릴 위치는 데이터가 액세스되는 방식 (정렬 필터링 등)에 따라 다릅니다.
이 대답은 제 개인적인 의견입니다. 저는 수학 논리를 사용하여 대답합니다.
두 번째 질문은 멈출 경계에 관한 것이 었습니다. 먼저 몇 가지 수학적 계산을 해보겠습니다. 모든 필드를 인덱싱하면 테이블에 L 필드가있는 N 개의 행이 있다고 가정하면 모든 테이블이 정렬되는 L 개의 새 인덱스 테이블이 생성됩니다. 의미있는 방식으로 인덱스 필드의 데이터, 테이블이 W 가중치이면 언뜻보기에 W * 2가 될 것입니다 (1 테라가 2 테라가 됨) 큰 테이블이 100 개 있으면 (나는 이미 테이블 번호가있는 프로젝트에서 작업했습니다. arround 1800 table)이 공간의 100 배 (100 테라)를 낭비하게됩니다.
모든 테이블에 인덱스를 적용 할 경우 인덱스 업데이트에 대해 생각해야합니다. 하나의 업데이트 트리거가 모든 인덱스 업데이트입니다.
이 시나리오에서 이번에 느슨해지면 선택이나 업데이트에서 손실하는 것이 바람직하다는 결론을 내립니다. 인덱싱되지 않은 필드를 선택하면 모든 필드에서 다른 선택을 트리거하지 않기 때문입니다. 색인화되지 않음
무엇을 색인할까요?
foreign-keys : 필수
primary-key : 누군가이 글을 읽는 것이이 사건에 도움이 될 수 있을지 아직 확실하지 않습니다.
다른 필드 : 첫 번째 자연 답변은 나머지 필드의 절반입니다. 이유 : 더 많은 색인을 생성해야하는 경우 r 더 적은 색인을 생성해야하는 경우 최상의 답변과 멀지 않습니다. 우리는 색인이 나쁘고 모든 색인이 생성되었음을 알기 때문에 멀지 않습니다. 나쁘다.
이 세 가지 점에서 K 키로 구성된 L 필드가있는 경우 한계는 ((L-K)/2)+K
L / 10 정도에 가까운 어딘가에 있어야한다는 결론을 내릴 수 있습니다.
이 대답은 내 논리와 개인적인 원칙에 근거합니다.
테이블의 모든 열을 인덱싱하는 것은 좋지 않습니다. 이렇게하면 테이블을 매우 빠르게 읽을 수 있지만 쓰기 속도도 훨씬 느려집니다. 모든 열이 인덱싱 된 테이블에 기록하려면 해당 테이블에 새 레코드를 넣은 다음 각 열의 정보를 자체 인덱스 테이블에 넣는 작업이 포함됩니다.