MySQL 큰 테이블 의 count()최적화 실현

다음은 제 가 B+트 리 의 데이터 구조 와 실험 결과 에 대한 추측 을 결합 하여 판단 한 것 입 니 다.만약 오류 가 있 으 면 지적 해 주 십시오!
오늘 MySQL 의 count()조작 최 적 화 를 실험 해 보 았 습 니 다.다음은 mysql 5.7 InnoDB 저장 엔진,x86 윈도 우즈 운영 체 제 를 바탕 으로 합 니 다.
만 든 표 의 구 조 는 다음 과 같 습 니 다(데 이 터 량 은 100 만 입 니 다).

우선 mysql 의 count(*),count(PK),count(1)중 어느 것 이 빠 른 지 에 대한 질문 입 니 다.
실현 결 과 는 다음 과 같다.
 
 
 
다 를 게 없어!WHERE 자 구 를 더 한 후 3 개의 조회 시간 도 같 아서 나 는 사진 을 붙 이지 않 겠 다.
전에 회사 에 있 을 때select count(*) from tableSQL 문 구 를 썼 는데 데이터 가 많 을 때 매우 느 렸 다.그래서 어떻게 최적화 할 까요?
이 는 이 노 DB 의 인덱스 부터 말하자면 이 노 DB 의 인덱스 는 B+Tree 다.
메 인 키 색인 에 있어 서:잎 노드 에 만 데 이 터 를 저장 합 니 다.키 는 메 인 키 이 고 value 는 전체 데이터 입 니 다.
보조 색인 에 있어 서 키 는 색인 을 만 드 는 열 이 고 value 는 메 인 키 입 니 다.
이것 은 우리 에 게 두 가지 메 시 지 를 준다.
1.메 인 키 에 따라 전체 데 이 터 를 찾 을 수 있 습 니 다.
2.보조 색인 에 따라 홈 키 만 찾 을 수 있 고 홈 키 를 통 해 나머지 정 보 를 찾 아야 합 니 다.
따라서 count(*)작업 을 최적화 하려 면 짧 은 열 을 찾 아 보조 색인 을 만들어 야 합 니 다.
나의 예 에서status,비록 그것 의'severelity'는 거의 0 이지 만.
먼저 색인 만 들 기:ALTER TABLE test1 ADD INDEX (status);그리고 다음 그림 을 조회 합 니 다.
 
조회 시간 이 3.35s 에서 0.26s 로 13 배 가까이 빨 라 진 것 을 볼 수 있다.
색인 이str열 이 라면 결 과 는 어 떨 까?
먼저 색인 만 들 기:alter table test1 add index (str)결 과 는 다음 과 같다.

시간 은 0.422s 로 빠 르 지만status보다 1.5 배 가량 차이 가 난다.
좀 더 대담 하 게 실험 을 해 보 겠 습 니 다.저 는status이 열의 색인 을 삭제 하고status과left(omdb,200)(이 열 평균 1000 글자)의 공동 색인 을 만 든 다음 에 조회 시간 을 보 겠 습 니 다.
색인 만 들 기:alter table test1 add index (status,omdb(200))결 과 는 다음 과 같다.
 
시간 은 1.172s

alter table test1 add index (status,imdbid);

보충!!
색인 이 효력 을 잃 는 상황 에 주의해 야 합 니 다!
색인 을 만 든 후 정상 적 인 모습:
 
키 를 볼 수 있 습 니 다len 은 6 이 고 Extra 의 설명 은 using index 입 니 다.
색인 이 효력 을 잃 으 면:

색인 이 효력 을 잃 는 것 은 여러 가지 상황 이 있 습 니 다.예 를 들 어 함수 사용,!=조작 등 구체 적 으로 는 공식 문 서 를 참고 하 시기 바 랍 니 다.
MySQL 에 대해 깊이 연구 하지 않 았 습 니 다.이상 은 제 가 B+트 리 의 데이터 구조 와 실험 결과 에 대한 추측 을 결합 하여 판단 한 것 입 니 다.만약 에 오류 가 있 으 면 지적 해 주 십시오!
MySQL 큰 표 의 count()최적화 실현 에 관 한 이 글 은 여기까지 소개 되 었 습 니 다.더 많은 관련 MySQL 큰 표 count()최적화 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 조회 하 시기 바 랍 니 다.앞으로 많은 응원 바 랍 니 다!