mysql 인덱스 덮어 쓰기 실례 분석
인덱스 덮어 쓰기
검색 열 이 색인 의 일부분 이 라면 검색 은 색인 파일 에서 만 진행 되 며 디스크 로 돌아 가 데 이 터 를 찾 을 필요 가 없습니다.이 검색 속 도 는 매우 빨 라 서'색인 덮어 쓰기'라 고 부른다.
t15 표 가 있다 고 가정 하고 표 에 연합 색인 을 만 들 었 습 니 다:cp(catid,price)
아래 sql 문 구 를 사용 하면 색인 이 덮어 쓰 이 는 상황 이 발생 합 니 다.믿 지 않 으 면 살 펴 볼 수 있 습 니 다.여기 Extra 에 Using index 가 표시 되 어 있 습 니 다.이 sql 문 구 는 색인 으로 덮어 쓰 였 음 을 표시 합 니 다.
select price from t15 where cat_id = 1;
문 제 를 보 려 면 t11 표를 만 들 고 이메일 열 에 색인 이 있 습 니 다.우리 가 이런 검색 어 를 사용한다 고 가정 하면:
select eamil from t11 where right(email,4)='.com'
조회 분석:우선 Extra 를 보 세 요.여기 Using index 가 있 습 니 다.색인 커버 를 사 용 했 고 possiblekeys 가 NULL 인 이 유 는 my sql 에 있 는 함 수 를 사 용 했 기 때문에 검색 할 때 email 색인 을 사용 하지 않 았 지만 key 는 email 로 색인 을 사용 하여 정렬 했 음 을 나타 내 고 데 이 터 를 인쇄 해 보 는 것 을 믿 지 않 았 습 니 다.
이곳 의 데 이 터 는 정렬 을 거 친 것 이다.원래 의 데 이 터 는 이렇다.
질문
create table A (
id varchar(64) primary key,
ver int,
…
)
표 에는 몇 개의 긴 필드 varbinary(3000)가 있 고 id,ver 에 연합 색인 이 있 으 며 모두 10000 개의 데이터 가 있 습 니 다.왜
select id from A order by id
너무 느 려 요?아주 빠르다.
질문:id,(id,ver)모두 색인 이 있 습 니 다.select id 는 모두'색인 덮어 쓰기'효 과 를 내야 합 니 다.왜 전 자 는 느 리 고 뒤 는 빠 릅 니까?
사고:innodb 클 러 스 터 와 my isam 색인 이 다 르 기 때문에 색인 은 이 두 가지 측면 에서 고려 합 니 다.
(1)이 표 가 Myisam 의 색인 을 사용한다 고 가정 하면 이 두 sql 문 구 는 모두 줄 을 돌려 데 이 터 를 찾 을 필요 가 없다.그러면 그들의 속 도 는 많 지 않 을 것 이다.
(2)이 표 가 InnoDB 의 색인 을 사용한다 고 가정 하면 selection id from A order by id 라 는 sql 은 메 인 키 색인 에 사 용 됩 니 다.InnoDB 의 모든 메 인 키 가 이 줄 의 데 이 터 를 마 운 트 하고 이 문제 에 특별한 필드 가 몇 개 있 기 때문에 id 를 찾 을 때 상대 적 으로 느리게 가 야 합 니 다.한편,selection id from A order by id,ver 라 는 sql 은 id,ver 연합 색인 을 사 용 했 습 니 다.InnoDB 저장 엔진 에서 차 색인 은 메 인 키 색인 에 대한 응용 프로그램 을 저장 하기 때문에 차 색인 은 이 줄 의 데 이 터 를 마 운 트 하지 않 습 니 다.그러면(id,ver)색인 에서 id 를 빨리 찾 을 수 있 습 니 다.해당 하 는 노드 트 리 를 찾 을 때 메 인 키 색인 위 치 를 다시 찾 으 면 이 줄 의 데 이 터 를 얻 을 수 있 습 니 다.이렇게 하면 비교적 빠르다.
추정:
(1)표 가 myisam 엔진 이 라면 두 문장 은 속도 에 현저 한 차이 가 없 을 것 이다.
(2)innodb 표 는 클 러 스 터 색인 으로 인해 id 색인 이 디스크 에 N 여 개 를 뛰 어 넘 어야 하기 때문에 속도 가 느 립 니 다.
(3)innodb 엔진 이 있 더 라 도 그 몇 개의 varbinay 장 열 이 없 으 면 두 문장의 속도 에 현저 한 차이 가 없 을 것 이다.
t12 표,메모리 엔진 은 MyISAM 이 고,메 인 키 인덱스 와(id,ver)인덱스 에 부합 되 며,몇 개의 커 진 필드 가 있 습 니 다.테스트 추론 1
t13 표,저장 엔진 은 InnoDB 이 고 메 인 키 인덱스 와(id,ver)가 인덱스 에 부합 되 며 몇 개의 커 진 필드 추론 2 가 있 습 니 다.
t14 표,저장 엔진 은 InnoDB 이 고,메 인 키 인덱스 와(id,ver)가 인덱스 에 부합 되 며,커 진 필드 추론 이 몇 개 없습니다.
t12,t13,t14 매 표 에 1W 개의 데이터 가 있 는 다음 에 테스트 를 실시 했다.테스트 결 과 는 다음 과 같다.우리 의 추론 은 정확 하 다.
더 많은 MySQL 관련 내용 에 관심 이 있 는 독자 들 은 본 사이트 의 주 제 를 볼 수 있다.,,,,,,,
본 논문 에서 말 한 것 이 여러분 의 MySQL 데이터베이스 계획 에 도움 이 되 기 를 바 랍 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
MySQL에서 JSON 인덱싱 - aarondfrancis사람들은 종종 MySQL로 JSON을 인덱싱할 수 없다고 말하지만 완전히 정확하지는 않습니다. MySQL로 JSON 열을 인덱싱하는 것은 완전히 가능합니다! 사람들은 종종 MySQL로 JSON을 인덱싱할 수 없다고 ...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.