디렉토리
1. InnoDB의 여러 개념 인덱스 테이블
2. 표를 다시 인덱스를 덮고
3. 페이징 쿼리
4. 지연 관련 최적화
사설
다음 선택에 도입 MySQL의 데이터베이스와 이노 디비 엔진을위한 기초. 최적화와 관련된 쿼리 속도 페이징 지연을 가속화 이유의 인덱스 우리가 이해하는 데 도움이 몇 가지 개념을 배울 수 있습니다.
A, 이노 디비 여러 개념 인덱스 테이블
이노 테이블은 클러스터 된 인덱스의 설립을 기반으로합니다.
일반적으로 메인 인덱스 통상 인덱스 키 인덱스 (보조 인덱스), 클러스터 인덱스, 기본 키 인덱스 인덱스 형 등 개인이 아니라 데이터 저장 나누어. 각각의 인덱스에 대한 인기있는 인덱스 정보 저장되는 B + 트리 클러스터 된 인덱스가 동일한 구성에 저장된 트리 B + 기본 키 인덱스를 통해 데이터 선, 즉 트리 B + 데이터 파일의 구조를 수립 ( 인수는 온라인 인덱스 및 데이터) 같은 파일에 저장하므로 클러스터 된 인덱스는 데이터 저장입니다된다는 것입니다.
인덱스의 개념에 익숙하지 않은 경우, 그것은 관련 정보에 대한 액세스를 연구하는 것이 좋습니다, 인덱스가 거대한 지식의 구조입니다.
디비는 테이블 기본 키 인덱스 접미사 구축 .MYD의 테이블 저장 파일을 일반적인 지표 도출 B + 트리 구현 첨자 저장 .MYI의 문서, 구체적인 구성은 아래와 같이된다 :
기본 키 인덱스가 쿼리에서 동일하지 않습니다 무엇 일반 인덱스의 선택?
예를 들어 다음과 같은 성명의 경우 :
· SELECT * 표에서 ID = WHERE 5]. ( ID 검색 프로세스 위와 같이 메인 인덱스 트리 직접 검색된 마스터 키에 따른 녹색 화살표 키 인덱스 기반)
· SELECT * 테이블 WHERE NAME = "빌 게이츠"; ( 이름 일반 인덱스) 검색 처리에 보이는 적색 화살표 얻어진 일반 인덱스 트리 인덱스의 일반 검색에 따른 ID 이다 5 하고 생성하도록 ID 차 인덱스 트리를 검색 결과. 이 과정에서 기본 키 인덱스 다시 탐색 트리의 과정에, 우리는 테이블에 다시 전화.
여기에서 볼 수 있듯이, 그것은 아닌 기본 키 인덱스의 쿼리를 기반으로 인덱스 트리의 여러 스캔을 필요로한다. 따라서, 우리는 응용 프로그램에서 기본 키 쿼리를 사용하려고합니다.
색인 및 검색 일반 기본 키 인덱스의 과정을 설명 후,의 인덱스에 포함되는 것을 살펴 보자.
다시 테이블에 두 번째로, 커버리지 지수와.
무엇입니까 " 커버 인덱스 " ?
쿼리의 열은 테이블에 다시없이 내장 된 보조 인덱스에 의해 덮여있다. 다시 테이블에보고하지 않고 인덱스 트리에서 직접받을 수 있습니다 데이터를 확인하기 위해, 제 고장에 의해 설명된다.
주 : 인덱스의 모든 유형이 포함 인덱스가 될 수 있습니다. 그래서 컬럼의 인덱스 및 해시 인덱스의 값을 저장해야합니다 커버링 인덱스, 공간 인덱스 및 전체 텍스트 인덱스는 인덱스 컬럼에 저장되지 않습니다 MySQL은 에만 사용할 수있는 B 트리 인덱스가 커버링 인덱스를 할
위의 예와 관련하여 :
· SELECT ID 테이블 WHERE NAME = "빌 게이츠", 즉, 피복 률.
셋째, 페이징 쿼리 사용 시나리오
수요 : 최신의 정보 7 개 일간의 주문 및 페이지 매김을한다. Orders 테이블 데이터의 양 : 3000W .
최적화되지 않은 SQL :
선택 * t_trade_order에서을
여기서 '2019년 10월 17일'사이 CREATE_TIME '2019년 10월 25일'
제한 1000000, 10;
에 따르면 설명 출력의 결과 것은이 속도가 느린 쿼리 것을 보여준다 쿼리는 느린 비즈니스 환경을 허용하지 않습니다.
우리 모두가하고 매김을 사용할 때 알아 제한 키워드를 필요로하는 데이터를 필터링 제한 수용 1 일 또는 2 개 매개 변수를 첫 번째 매개 변수는 데이터를 가져 오는 시작하는 행 두 개의 매개 변수를 받아들이 오프셋을 나타냅니다, 두번째 매개 변수는 행수가 페치 될 나타낸다. 단지 하나의 파라미터가 대응하는 경우의 오프셋 0 . 같은 오프셋이 큰 경우 이러한 제한이 100000,10 제 취할 100001-100010 기록, MySQL이 제거 100010 개 그 앞에 기록 100000 개 레코드 삭제를, 성능이 엄청난 낭비이다.
마지막으로 질문에 돌려, 우리는 그것을 최적화하는 방법을해야 하는가?
넷째, 지연 최적화와 관련된
"고성능 MySQL의 사실은"이 책은 또한 상황에 대해 설명합니다 :
관련 지연 최적화 : 원래의 테이블과 연관된 마스터 키에 따라 필요한 데이터를 획득 한 후, 리턴하는데 필요한 기본 키 인덱스 쿼리 범위를 사용함으로써.
t_trade_order t에서 *를 선택
내부 조인 (
t_trade_order에서 ID를 선택
여기서 '2019년 10월 17일'사이 CREATE_TIME '2019년 10월 25일'
제한 1000000, 10
) 전자
t.id = e.id 일;
에 따르면 설명 분석, 쿼리 시간이 아니라 0.31 일반 페이징보다 빨리 크기 순서를 쿼리.
확실히 당신은 일반적인 페이징 쿼리 최적화 지연 관련 대비가 이러한 효과를 재생할 수 있습니다 이유를 알고 싶은 것?
이 인덱스로 다시 테이블에 적용되는 위에서 언급 한 두 가지 중요한 개념에 관한!
의이 구현 프로세스의이 두 문장을 살펴 보자 매우 분명하다.
전에 최적화 :
선택 * t_trade_order에서을
여기서 '2019년 10월 17일'사이 CREATE_TIME '2019년 10월 25일'
제한 1000000, 10;
( CREATE_TIME이 경우 일반 인덱스 테이블 구축되도록 설정한다)
1. 에서 CREATE_TIME 인덱스 트리 찾을 CREATE_TIME = '2019년 10월 17일' 의 획득 기록, ID를 .
2. 다음에 대해 발견 된 주요 인덱스 트리에 아이디 기록
3. 수 미만이며 10 , 업데이트 시간 단계의 루프 1 , 2
4. ...
제 에서 CREATE_TIME의 색인 트리 값 제거 = '2019년 10월 25일'를 CREATE_TIME이 조건이 성립하지 않는 때, 상기 루프는 종료된다.
6. 결과 포기하기 전에 백만 행을 반환 10 개 행을
물론, 일반 페이징 쿼리는 일반 인덱스 중 하나에 의해 전달되는 ID 가 다시 테이블 쿼리, 다시 테이블마다 한 번에 IO , 낭비 상당한 성능의 결과.
최적화 후
t_trade_order t에서 *를 선택
내부 조인 (
t_trade_order에서 ID를 선택
여기서 '2019년 10월 17일'사이 CREATE_TIME '2019년 10월 25일'
제한 1000000, 10
) 전자
t.id = e.id 일;
1. 포함 인덱스의 사용 SELECT의 ID CREATE_TIME의 t_trade_order에서 '2019년 10월 17일'사이 '2019년 10월 25일'제한 100, 10 , 포기하기 전에 쿼리 결과 백만 행이 반환 10 행 , 쿼리와 일치하는 범위를 쿼리를 신분증
2 , 다시 획득에 기초하여 상기 연관 테이블에 ID 연관된 마스터 인덱스 테이블 볼륨 매칭 결과. (그냥 한 번 기본 색인 테이블로 돌아)
그것은이 원래의 테이블과 연결된 기본 키를 기반으로 원하는 행을 필요로 돌아간 다음 얻을 범위 인덱스 쿼리 기본 키를 사용하여 볼 수 있습니다, 이것은 줄일 수 있습니다 MySQL의 테이블에 다시 번호를, 또한 피하기 위해 MySQL의 원래 테이블에 직접 드롭 할 필요가 주사선의 수를 (실제로는 일반 인덱스의 나무는 훨씬 더 빨리, 스캔).
내가 너희에게 쓰는 기사, 나는 약간의 도움을 최적화와 관련된 지연을 이해하고 싶다.
