효율적으로 분할하려는 큰 테이블 (수억 개의 행)이 있습니다. 내 질문은 파티션 크기와 파티션 수 사이에 트레이드 오프가 있는지 여부입니다. 내가 이해하는 한, 쿼리는 (대부분의 쿼리의 경우) 쿼리에 적용 가능한 파티션 내에서만 검색하기 때문에 파티션에서 사용되는 열에 대한 대부분의 쿼리가 더 빠릅니다. 따라서 효율성을 최대화하려면 큰 테이블을 최대 파티션 수로 나누어야하므로 각 파티션을 가능한 작게 만들어야합니다. MySQL의 경우 이는 1024 개의 파티션을 의미합니다. 그러나 많은 수의 파티션을 사용하면 성능이 저하됩니까? 그렇다면 최적의 파티션 수를 어떻게 찾습니까?

참고 : stackoverflow에 대해서는 다소 비슷한 질문이 있지만 한 가지 대답 만 있습니다. 그래서 나는 내 자신의 방식으로 질문을 진술 할 것입니다 ...

그들을 비교하자

파티션 크기

다음이있는 경우 :

• 테이블에 1 억 행
• BTREE 인덱싱
• BTREE의 각 페이지에는 1024 개의 키가 있습니다.

측정 항목은 어떻게 표시됩니까?

LOG (100000000) / LOG (2) = 26.575424759099이므로 페이지 트리 노드 당 1024 개의 키가있는 BTREE 인덱스의 트리 높이는 3 (CEILING (LOG (100000000) / LOG (1024)))입니다. 세 페이지 노드 만 있으면 액세스 된 각 트리 노드에서 필요한 키를 이진으로 검색하면 약 30 개의 키를 잘라 내고 격리 할 수 ​​있습니다.

파티션 수

다음이있는 경우 :

• 테이블에 1 억 행
• BTREE 인덱싱
• BTREE의 각 페이지에는 1024 개의 키가 있습니다.
• 1024 개의 패리티 션을 생성합니다

숫자는 약간 다를 수 있습니다.

각 파티션에는 약 97656 개의 행이 있어야합니다. 이제 지표는 무엇입니까?

LOG (97656) / LOG (2) = 16.575421065795이므로 페이지 트리 노드 당 1024 개의 키가있는 BTREE 인덱스의 트리 높이는 2 (CEILING (LOG (97656) / LOG (1024)))입니다. 두 페이지 노드 만 있으면 액세스 된 각 트리 노드에서 필요한 키를 이진으로 검색하면 약 20 개의 키를 잘라 내고 격리 할 수 ​​있습니다.

결론

키를 펼치면 하나의 트리 수준 만 제거되지만 기본적으로 1024 개의 인덱스가 생성됩니다. 쿼리는 차이점을 모릅니다. 검색 시간은 아마도 파티션에 유리하게 공칭 일 것입니다. 그러나 모든 데이터가 활성화되어 있는지 확인하십시오. Otheriwse, 거의-액세스하지 데이터를 다른 파티션은 단지 공간을 차지하여 분할을 정당화하기 위해 충분히 자주 액세스되지 않습니다 동안 당신은 몇 파티션을 타격 할 수있다 . XFS , ext3 vs ext4 등의 내부 조각 모음 과 같이 더 솔직한 것에 대해 걱정해야 할 성능 메트릭이 다를 수 있습니다 . 또한 다음과 같은 이유로 사용중인 스토리지 엔진에 대해 걱정해야합니다.

• 클러스터형 인덱스를 관리해야하기 때문에 InnoDB 인덱싱은 MyISAM에 비해 약간 더 복잡합니다.
• InnoDB는 현재 로그 파일 (ib_logfile0 또는 ib_logfile1)뿐만 아니라 ibdata1에 데이터를 두 번 쓰지 않습니다.