데이터베이스 인덱스는 실제로 어떻게 내부에서 일합니까?

데이터베이스에 왜 색인을 만들어야 하는지 간단한 예부터 설명하자.
가령 우리가costing이라는 표를 가지고 있다면, 그중에 세 열의company id, unit, unit cost가 있는데, 이것은 완전히 무질서한 것이다.

만약 우리가 아래의 조회를 실행한다면 -

SELECT
    company_id,
    units,
    unit_cost
FROM
    costing
WHERE
    company_id = 18

데이터베이스는 모든 기록을 하나하나 검사하고 일치하는 데이터 집합을 검색해야 한다.일단 표의 크기가 증가하면, 그것은 점점 시간을 소모하게 될 것이다.
질의 실행의 시각적 표현

이것은 거의 모든 데이터베이스를 사람의 눈으로 훑어보는 것과 같다. 매우 느리고 조금도 매끄럽지 않다.이것이 바로 이른바 전체 시계 스캐닝이다.
여기서 색인이 나타나기 시작합니다.색인의 역할은 검색 조건이 있는 열을 정렬 순서대로 설정하여 검색 성능을 최적화하는 데 도움을 주는 것이다.
색인이 company id에 있는 경우 테이블은 다음과 같습니다.

현재 데이터베이스는 정렬 순서에 따라 어떤 기록을 검사하고 언제 정지하는지 알고 있다.
색인의 주요 목적은 표에서 데이터베이스 검사를 필요로 하는 기록/줄의 수량을 줄여 검색 조회의 속도를 가속화시키는 것이다.

그렇다면 색인은 실제로 어떻게 작동합니까?

우선, 우리가 검색 성능을 최적화하기 위해 열에 색인을 설치할 때 데이터베이스 테이블은 다시 정렬되지 않습니다.

An index is a data structure, (most commonly its B-tree {Its balanced tree, not binary tree}) that stores the value for a specific column in a table.

B-트리의 주요 장점은 그 중의 데이터가 정렬할 수 있다는 것이다.또한 B-트리 데이터 구조는 시간 효율성이 있어 대수 시간 내에 검색, 삽입, 삭제 등의 작업을 완료할 수 있다.
그래서 색인은 이렇게 해야 돼요. - 네.

여기서, 모든 열에 대해 데이터베이스 내부 식별자 (지침) 로 비추고, 이 식별자는 줄의 정확한 위치를 가리킨다.현재, 만약 우리가 같은 조회를 실행한다면.
질의 실행의 시각적 표현

따라서 색인은 시간의 복잡도를 o(n)에서 o(logn)로 낮출 뿐이다.
또 어떤 종류의 색인이 있습니까?
01 해싱 색인 -
해시표는 색인에 사용되는 또 다른 데이터 구조이다.해시 인덱스를 사용하는 이유는 해시 테이블이 값을 검색할 때 매우 유효하기 때문이다(시간 복잡도 0(1).
따라서 현재, 우리가 앞에서 논의한 검색이 o (logn) 검색이 아니라, 해시 인덱스가 o (1) 의 해시 테이블에서 직접 바늘 값을 가져오면, 검색이 더욱 빨라집니다.
그렇다면, 만약 해시 색인 속도가 이렇게 빠르다면, 왜 모든 곳에서 그것을 사용하지 않겠는가?
응, 해시 색인에 결점이 좀 있어.이 검색어들은 정렬되지 않았고, 많은 종류의 검색어들이 있는데, 해시 인덱스는 심지어 그것들을 도울 수 없다.예를 들어, 만약 당신이 모든 회사 id가 40보다 작은 회사를 찾고 싶다면.어떻게 해시표 인덱스를 사용하여 이 점을 실현합니까?해시표는 키 값 쌍을 찾는 데만 적용되기 때문에 불가능합니다. 이것은 같은 검색을 검사하는 것을 의미합니다. (예를 들어 "WHERE company id=18")
이것이 바로 산열 인덱스가 데이터베이스 인덱스에서 사용하는 기본 데이터 구조 형식이 아닌 이유입니다. 인덱스 데이터 구조로 사용할 때 B 트리보다 유연하지 않기 때문입니다.
02 R- 나무 -
이러한 인덱스는 R트리 데이터 구조를 사용하여'me 5km 이내의 모든 버스 정류장 찾기'와 같은 공간 문제를 해결하는 데 도움을 준다.
03비트 매핑 인덱스 -
이 인덱스는 부울 값 (true 또는false) 을 포함하는 열에서 잘 작동합니다.
인덱스의 비용은 얼마입니까?

색인은'더 빨리 읽고 더 느리게 쓴다'.테이블에 대한 쓰기, 업데이트, 삽입 작업도 색인을 해야 합니다.

Thing to note, MySQL put indexes in memory.

또 다른 일은 공간이다. 표가 클수록 색인이 크다.

가장 일반적인 인덱스 트랩
대부분의 개발자들은 색인이 매우 멋있다고 생각한다.어떤 열에 색인을 만들면 검색 성능이 급등하지만 사실은 그렇지 않다.열에 색인을 추가할 때, 우리는 몇 가지 일을 고려해야 한다. (여기서 우리는 MySQL에 대해 토론할 것이다.)
예를 들면 다음과 같습니다.
예를 들면, 우리는 주문서라는 탁자가 하나 있다.order id, amount, createdAt 등 약 200만 줄이 있습니다.우리는 2020년의 모든 주문서의 총계를 찾아야 한다.
그래서 우리는 이렇게 할 수 있다-

SELECT total(amount)
    FROM orders
    WHERE YEAR(createdAt) = 2020;

그것은 정확한 출력을 제공했지만, 조회 속도가 매우 느리다.그래서 우리는 색인을'created At'열에 놓고 성능을 봅니다.그러나 조회는 여전히 같은 시간이 필요하다.만약 우리가 조회 실행 상황을 살펴보면, 우리는 여전히 완전한 표 스캔을 하고 있다는 것을 발견할 수 있을 것이다.그래서 어떤 이유로 우리가 지수가 하나 있어도 고려되지 않았다.
그것은 우리에게 색인의 첫 번째 함정, 즉 함수를 가져다 주었다.만약 우리가 'WHERE' 자구에서 함수를 사용한다면, 우리는 색인을 사용하는 능력을 잃게 될 것이다.

It's worth noticing that MySQL v8.0.13 and above now support functional indexes.

이 검색어를 작성할 수 있는 다른 방법도 있습니다.

SELECT total(amount)
    FROM orders
    WHERE createdAt BETWEEN '2020-01-01 00:00:00' AND '2020-12-31 23:59:59';

그러나, 우리는 'amount' 열을 사용하여 총수를 계산하기 때문에, 전체 테이블 스캔을 실행할 것이다.그래서 우리도 '금액' 열에 색인을 붙여야 한다.
이외에도 색인의 순서는 검색 성능에도 매우 중요하다.

To confirm, index is actually being considered or not, add "EXPLAIN" before the SQL query and check the "type" and "rows", which database is looking at to fetch the result.

읽어주셔서 감사합니다.

Source - Internet.

나에 대해: https://pankajtanwar.in
나는 https://pankajtanwar.in/blogs에 시스템 설계, 백엔드 프로젝트와 네트워크 기술을 썼다