Index 및 MySQL 인덱스 원리와 느린 쿼리 최적화란 무엇입니까?

색인의 목적은 질의 효율성을 높이는 것으로, 사전과 비교할 수 있다. "MySQL" 이라는 단어를 확인하려면 문자 M 을 찾은 다음 아래에서 위로 문자 Y 를 찾은 다음 나머지 SQL 을 찾아야 합니다. 색인이 없다면 원하는 단어를 찾기 위해 모든 단어를 읽어야 할 것이다. M 으로 시작하는 단어를 찾으려면 어떻게 해야 합니까? 아니면 ze 로 시작하는 단어인가요? 너는 이 물건이 지표가 없으면 안 된다고 생각하니?

색인 정책

사전을 제외하고 색인의 예는 기차역의 기차 시간표, 책의 목록과 같이 생활 곳곳에서 볼 수 있다. 그들은 모두 같은 원리를 가지고 있다. 우리는 원하는 데이터의 범위를 좁혀 최종 원하는 결과를 걸러내고 무작위 이벤트를 순서 이벤트로 바꾼다. 즉, 우리는 항상 같은 검색 방법으로 데이터를 잠근다. (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 성공명언)

데이터베이스도 마찬가지지만, 동등한 조회뿐만 아니라 범위 조회 (>:,<, between, in), 퍼지 조회 (like), 연합 조회 (or) 등에 직면해야 하기 때문에 훨씬 더 복잡합니다. 데이터베이스는 모든 문제를 처리하기 위해 어떻게 선택해야 합니까? 사전의 예를 생각해 봅시다. 데이터를 세그먼트화하고 질의를 분할할 수 있습니까? 가장 간단한 경우는 1000 개 데이터, 1 부터 100 까지 첫 번째 세그먼트,10/kloc-0 으로 나누는 경우입니다 하지만 10 만 개의 레코드라면 몇 개의 세그먼트가 더 좋을까요? 약간의 알고리즘 기반 동창회는 검색 트리를 생각하는데, 그것의 평균 복잡성은 lgN 이고, 조회 성능이 좋다. 하지만 여기서 우리는 중요한 문제를 간과했습니다. 복잡성 모델은 매번 동일한 운영 비용을 기준으로 합니다. 데이터베이스는 복잡하며 데이터는 디스크에 저장됩니다. 성능을 향상시키기 위해 한 번에 일부 데이터를 메모리로 읽어 계산할 수 있습니다. 디스크 액세스 비용이 메모리 액세스의 10 만배 정도라는 것을 알고 있기 때문에 간단한 검색 트리로는 복잡한 애플리케이션 시나리오를 충족할 수 없습니다.

인덱스의 데이터 구조

앞서 생활 속 색인의 예, 색인의 기본 원리, 데이터베이스의 복잡성, 운영 체제에 대한 지식을 설명했습니다. 그 목적은 어떤 데이터 구조도 허공에서 만들어지지 않고 배경과 사용 장면이 있어야 한다는 것을 모두에게 알리기 위함이다. (윌리엄 셰익스피어, 윈스턴, 데이터명언) 이 데이터 구조가 무엇을 해야 하는지 요약해 보겠습니다. 디스크 IO 횟수를 아주 작은 규모로 제어하는 것이 가장 좋습니다. 일정한 양급이 가장 좋습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언) 그래서 우리는 고도로 제어 가능한 다중 경로 검색 트리가 수요를 충족시킬 수 있는지 궁금해했습니다. 이런 식으로 b+ 나무가 생겨났습니다.