문제

데이터 세트의 크기가 증가함에 따라 인덱싱이 매우 중요하다는 점을 감안할 때 누군가 데이터베이스에 구애받지 않는 수준에서 인덱싱이 작동하는 방식을 설명할 수 있습니까?

필드를 색인화하는 쿼리에 대한 자세한 내용은 다음을 확인하세요. 데이터베이스 열을 인덱싱하는 방법.

도움이 되었습니까?

해결책

왜 필요한가요?

데이터가 디스크 기반 저장 장치에 저장되면 데이터 블록으로 저장됩니다.이러한 블록은 전체적으로 액세스되므로 원자 디스크 액세스 작업이 됩니다.디스크 블록은 연결된 목록과 거의 동일한 방식으로 구성됩니다.둘 다 데이터 섹션, 다음 노드(또는 블록)의 위치에 대한 포인터를 포함하며 둘 다 연속적으로 저장할 필요는 없습니다.

여러 레코드가 하나의 필드에서만 정렬될 수 있다는 사실로 인해 정렬되지 않은 필드에서 검색하려면 선형 검색이 필요하다고 말할 수 있습니다. N/2 액세스 차단(평균), 여기서 N 테이블이 걸쳐 있는 블록의 수입니다.해당 필드가 키가 아닌 필드인 경우(예:고유한 항목이 포함되어 있지 않은 경우) 전체 테이블스페이스를 검색해야 합니다. N 액세스를 차단합니다.

정렬된 필드의 경우 이진 검색을 사용할 수 있습니다. log2 N 액세스를 차단합니다.또한 키가 아닌 필드를 기준으로 데이터가 정렬되므로 더 높은 값이 발견되면 테이블의 나머지 부분에서 중복 값을 검색할 필요가 없습니다.따라서 성능 향상이 상당합니다.

인덱싱이란 무엇입니까?

인덱싱은 여러 필드의 여러 레코드를 정렬하는 방법입니다.테이블의 필드에 대한 인덱스를 생성하면 필드 값과 관련된 레코드에 대한 포인터를 보유하는 또 다른 데이터 구조가 생성됩니다.그런 다음 이 인덱스 구조가 정렬되어 이진 검색이 수행될 수 있습니다.

인덱싱의 단점은 이러한 인덱스가 MyISAM 엔진을 사용하여 테이블에 함께 저장되므로 디스크에 추가 공간이 필요하다는 것입니다. 동일한 테이블 내의 많은 필드가 인덱싱되면 이 파일은 기본 파일 시스템의 크기 제한에 빠르게 도달할 수 있습니다. .

어떻게 작동하나요?

먼저, 샘플 데이터베이스 테이블 스키마의 개요를 살펴보겠습니다.

Field name       Data type      Size on disk
id (Primary key) Unsigned INT   4 bytes
firstName        Char(50)       50 bytes
lastName         Char(50)       50 bytes
emailAddress     Char(100)      100 bytes

메모:디스크 값의 정확한 크기를 허용하기 위해 varchar 대신 char가 사용되었습니다.이 샘플 데이터베이스에는 500만 개의 행이 포함되어 있으며 인덱싱되지 않았습니다.이제 여러 쿼리의 성능이 분석됩니다.다음은 ID (정렬된 키 필드) 및 이름 (키가 아닌 정렬되지 않은 필드)

실시예 1 - 정렬된 필드와 정렬되지 않은 필드

샘플 데이터베이스를 고려하면 r = 5,000,000 레코드 길이를 제공하는 고정 크기의 레코드 R = 204 바이트는 기본 블록 크기를 사용하는 MyISAM 엔진을 사용하여 테이블에 저장됩니다. B = 1,024 바이트.테이블의 차단 요인은 다음과 같습니다. bfr = (B/R) = 1024/204 = 5 디스크 블록당 레코드 수입니다.테이블을 유지하는 데 필요한 총 블록 수는 다음과 같습니다. N = (r/bfr) = 5000000/5 = 1,000,000 블록.

id 필드에 대한 선형 검색에는 평균이 필요합니다. N/2 = 500,000 id 필드가 키 필드인 경우 값을 찾기 위한 액세스를 차단합니다.그러나 id 필드도 정렬되어 있으므로 평균이 필요한 이진 검색을 수행할 수 있습니다. log2 1000000 = 19.93 = 20 액세스를 차단합니다.즉시 우리는 이것이 급격한 개선이라는 것을 알 수 있습니다.

이제 이름 필드는 정렬되지도 않고 키 필드도 아니므로 이진 검색이 불가능하고 값이 고유하지 않으므로 테이블에서 정확한 값을 끝까지 검색해야 합니다. N = 1,000,000 액세스를 차단합니다.인덱싱이 바로잡는 것이 바로 이러한 상황이다.

인덱스 레코드에는 인덱스된 필드와 원본 레코드에 대한 포인터만 포함되어 있으므로 해당 레코드가 가리키는 다중 필드 레코드보다 작을 것으로 보입니다.따라서 인덱스 자체에는 원본 테이블보다 더 적은 디스크 블록이 필요하므로 반복하는 데 더 적은 블록 액세스가 필요합니다.인덱스에 대한 스키마 이름 필드는 아래에 설명되어 있습니다.

Field name       Data type      Size on disk
firstName        Char(50)       50 bytes
(record pointer) Special        4 bytes

메모:MySQL의 포인터 길이는 테이블 크기에 따라 2, 3, 4 또는 5바이트입니다.

실시예 2 - 인덱싱

샘플 데이터베이스를 고려하면 r = 5,000,000 인덱스 레코드 길이가 다음과 같은 레코드 R = 54 바이트 및 기본 블록 크기 사용 B = 1,024 바이트.인덱스의 차단 요인은 다음과 같습니다. bfr = (B/R) = 1024/54 = 18 디스크 블록당 레코드 수입니다.인덱스를 보유하는 데 필요한 총 블록 수는 다음과 같습니다. N = (r/bfr) = 5000000/18 = 277,778 블록.

이제 다음을 사용하여 검색합니다. 이름 필드는 인덱스를 활용하여 성능을 향상시킬 수 있습니다.이는 평균을 사용하여 인덱스의 이진 검색을 허용합니다. log2 277778 = 18.08 = 19 액세스를 차단합니다.읽기 위해 추가 블록 액세스가 필요한 실제 레코드의 주소를 찾으려면 총계를 다음과 같이 가져옵니다. 19 + 1 = 20 이는 블록 액세스를 찾는 데 필요한 1,000,000개의 블록 액세스와는 거리가 멀습니다. 이름 인덱싱되지 않은 테이블에서 일치합니다.

언제 사용해야 합니까?

인덱스를 생성하려면 추가 디스크 공간(위 예에서 추가로 277,778개 블록, ~28% 증가)이 필요하고 인덱스가 너무 많으면 파일 시스템 크기 제한으로 인해 문제가 발생할 수 있다는 점을 고려하여 올바른 디스크 공간을 선택하려면 신중하게 생각해야 합니다. 색인을 생성할 필드입니다.

인덱스는 레코드 내에서 일치하는 필드를 검색하는 속도를 높이기 위해서만 사용되므로 출력에만 사용되는 인덱스 필드는 삽입 또는 삭제 작업을 수행할 때 단순히 디스크 공간과 처리 시간을 낭비하는 것이 됩니다. 피해야한다.또한 이진 검색의 특성을 고려할 때 데이터의 카디널리티 또는 고유성이 중요합니다.카디널리티가 2인 필드를 인덱싱하면 데이터가 절반으로 분할되는 반면, 카디널리티가 1,000이면 약 1,000개의 레코드가 반환됩니다.이렇게 낮은 카디널리티를 사용하면 효율성이 선형 정렬로 감소하고 카디널리티가 레코드 수의 30% 미만인 경우 쿼리 최적화 프로그램은 인덱스 사용을 피하므로 인덱스가 공간 낭비가 됩니다.

다른 팁

처음 읽었을 때 이 내용은 나에게 매우 도움이 되었다.감사합니다.

그 이후로 나는 인덱스 생성의 단점에 대해 다음과 같은 통찰력을 얻었습니다.테이블에 쓰면 (UPDATE 또는 INSERT) 하나의 인덱스를 사용하면 파일 시스템에 실제로 두 개의 쓰기 작업이 있습니다.하나는 테이블 데이터용이고 다른 하나는 인덱스 데이터용입니다(그리고 해당 데이터의 재정렬(및 클러스터된 경우 테이블 데이터의 재정렬)).테이블과 인덱스가 동일한 하드 디스크에 있으면 시간이 더 많이 걸립니다.따라서 인덱스(힙)가 없는 테이블은 더 빠른 쓰기 작업을 허용합니다.(인덱스가 두 개인 경우 쓰기 작업이 세 번 발생하게 됩니다.)

그러나 인덱스 데이터와 테이블 데이터에 대해 두 개의 서로 다른 하드 디스크에 두 개의 서로 다른 위치를 정의하면 시간 비용 증가 문제를 줄이거나 제거할 수 있습니다.이를 위해서는 원하는 하드 디스크에 해당 파일이 포함된 추가 파일 그룹을 정의하고 원하는 대로 테이블/인덱스 위치를 정의해야 합니다.

인덱스의 또 다른 문제는 데이터가 삽입됨에 따라 시간이 지남에 따라 조각화된다는 것입니다. REORGANIZE 도움이 되려면 루틴을 작성해야 합니다.

특정 시나리오에서는 인덱스가 있는 테이블보다 힙이 더 유용합니다.

예:- 경쟁하는 쓰기가 많지만 보고를 위해 업무 시간 외에 밤에 한 번만 읽는 경우.

또한 클러스터형 인덱스와 비클러스터형 인덱스를 구별하는 것이 다소 중요합니다.

나를 도와 주었다:- 클러스터형 인덱스와 비클러스터형 인덱스는 실제로 무엇을 의미합니까?

인덱스는 데이터베이스의 특정 열을 더 빠르게 검색할 수 있게 해주는 데이터 구조일 뿐입니다.이 구조는 일반적으로 b-트리 또는 해시 테이블이지만 다른 논리 구조일 수도 있습니다.

고전적인 예 "도서의 색인"

1000페이지로 구성된 "책"을 100개의 섹션으로 나누고 각 섹션이 X페이지로 구성되어 있다고 생각해 보세요.

간단하죠?

이제 색인 페이지 없이 문자 "S"로 시작하는 특정 섹션을 찾으려면 책 전체를 스캔하는 것 외에 다른 방법이 없습니다.즉:1000페이지

하지만 처음에 색인 페이지가 있으면 거기에 있습니다.그리고 중요한 특정 섹션을 읽으려면 매번 색인 페이지를 계속해서 살펴보기만 하면 됩니다.일치하는 색인을 찾은 후 다른 섹션을 건너뛰어 해당 섹션으로 효율적으로 이동할 수 있습니다.

그러나 인덱스 페이지를 표시하려면 1000페이지 외에 약 10페이지가 더 필요하므로 총 1010페이지가 됩니다.

따라서 인덱스는 효율적인 조회를 위해 인덱스된 열의 값 + 인덱스된 행에 대한 포인터를 정렬된 순서로 저장하는 별도의 섹션입니다.

학교에서는 일이 간단하지 않나요?:피

이제 이름이 'Abc'인 직원의 모든 세부 정보를 찾기 위해 쿼리를 실행한다고 가정해 보겠습니다.

SELECT * FROM Employee 
WHERE Employee_Name = 'Abc'

색인이 없으면 어떻게 될까요?

데이터베이스 소프트웨어는 문자 그대로 Employee 테이블의 모든 단일 행을 조사하여 해당 행의 Employee_Name이 'Abc'인지 확인해야 합니다.그리고 우리는 'Abc'라는 이름이 있는 모든 행을 원하기 때문에 이름이 'Abc'인 행 하나만 찾으면 검색을 멈출 수 없습니다. 왜냐하면 이름이 있는 다른 행이 있을 수 있기 때문입니다. 알파벳.따라서 마지막 행까지 모든 행을 검색해야 합니다. 즉, 이 시나리오에서는 이름이 'Abc'인 행을 찾기 위해 데이터베이스에서 수천 개의 행을 검사해야 합니다.이것이 바로 A라고 불리는 것입니다. 전체 테이블 스캔

데이터베이스 인덱스가 성능에 도움이 되는 방법

인덱스를 갖는 요점은 본질적으로 검사해야 하는 테이블의 레코드/행 수를 줄여 검색 쿼리 속도를 높이는 것입니다.인덱스는 테이블의 특정 열에 대한 값을 저장하는 데이터 구조(가장 일반적으로 B-트리)입니다.

B-트리 인덱스는 어떻게 작동하나요?

B-트리가 인덱스에 가장 널리 사용되는 데이터 구조인 이유는 시간 효율적이기 때문입니다. 조회, 삭제 및 삽입이 모두 로그 시간 내에 완료될 수 있기 때문입니다.그리고 B-트리가 더 일반적으로 사용되는 또 다른 주요 이유는 B-트리 내부에 저장된 데이터를 정렬할 수 있기 때문입니다.RDBMS는 일반적으로 인덱스에 실제로 사용되는 데이터 구조를 결정합니다.그러나 특정 RDBMS를 사용하는 일부 시나리오에서는 인덱스 자체를 생성할 때 데이터베이스에서 사용할 데이터 구조를 실제로 지정할 수 있습니다.

해시 테이블 인덱스는 어떻게 작동하나요?

해시 인덱스를 사용하는 이유는 해시 테이블이 값을 찾는 데 매우 효율적이기 때문입니다.따라서 문자열과의 동등성을 비교하는 쿼리는 해시 인덱스를 사용하는 경우 매우 빠르게 값을 검색할 수 있습니다.

예를 들어 앞에서 논의한 쿼리는 Employee_Name 열에 생성된 해시 인덱스를 활용하는 것이 좋습니다.해시 인덱스가 작동하는 방식은 열 값이 해시 테이블의 키가 되고 해당 키에 매핑된 실제 값이 테이블의 행 데이터에 대한 포인터가 된다는 것입니다.해시 테이블은 기본적으로 연관 배열이므로 일반적인 항목은 "Abc => 0x28939"와 유사합니다. 여기서 0x28939는 Abc가 메모리에 저장되는 테이블 행에 대한 참조입니다.해시 테이블 인덱스에서 "Abc"와 같은 값을 찾고 메모리에서 해당 행에 대한 참조를 다시 가져오는 것은 테이블을 스캔하여 Employee_Name 열에서 "Abc" 값이 있는 모든 행을 찾는 것보다 확실히 훨씬 빠릅니다.

해시 인덱스의 단점

해시 테이블은 정렬된 데이터 구조가 아니며 해시 인덱스가 도움을 줄 수 없는 쿼리 유형도 많습니다.예를 들어, 40세 미만의 직원을 모두 찾고 싶다고 가정해 보겠습니다.해시 테이블 인덱스로 어떻게 그렇게 할 수 있습니까?글쎄, 해시 테이블은 키 값 쌍을 찾는 데만 적합하기 때문에 불가능합니다. 즉, 동일성을 확인하는 쿼리를 의미합니다.

데이터베이스 인덱스 안에는 정확히 무엇이 있나요?이제 데이터베이스 인덱스가 테이블의 열에 생성되고 인덱스가 해당 특정 열에 값을 저장한다는 것을 알게 되었습니다.그러나 데이터베이스 인덱스는 동일한 테이블의 다른 열에 값을 저장하지 않는다는 점을 이해하는 것이 중요합니다.예를 들어 Employee_Name 열에 인덱스를 생성하면 Employee_Age 및 Employee_Address 열 값도 인덱스에 저장되지 않음을 의미합니다.다른 모든 열을 인덱스에 저장했다면 이는 전체 테이블의 또 다른 복사본을 만드는 것과 같을 것입니다. 이는 너무 많은 공간을 차지하고 매우 비효율적입니다.

데이터베이스는 언제 인덱스를 사용해야 하는지 어떻게 알 수 있나요?"SELECT * FROM Employee WHERE Employee_Name = 'Abc' "와 같은 쿼리가 실행되면 데이터베이스는 쿼리되는 열에 인덱스가 있는지 확인합니다.Employee_Name 열에 인덱스가 생성되어 있다고 가정하면 데이터베이스는 검색 중인 값을 찾기 위해 인덱스를 사용하는 것이 실제로 적합한지 여부를 결정해야 합니다. 데이터베이스 인덱스를 사용하는 것이 실제로 덜 효율적인 일부 시나리오가 있기 때문입니다. , 전체 테이블을 스캔하는 것이 더 효율적입니다.

데이터베이스 인덱스를 보유하는 데 드는 비용은 얼마입니까?

공간을 차지하며 테이블이 클수록 인덱스도 커집니다.인덱스의 또 다른 성능 저하는 해당 테이블에서 행을 추가, 삭제 또는 업데이트할 때마다 동일한 작업이 인덱스에 수행되어야 한다는 사실입니다.인덱스는 인덱스가 다루는 테이블 열에 있는 것과 동일한 최신 데이터를 포함해야 한다는 점을 기억하십시오.

일반적으로 인덱스 열의 데이터를 자주 쿼리하는 경우에만 테이블에 인덱스를 생성해야 합니다.

또한보십시오

  1. 일반적으로 좋은 인덱스를 만드는 열은 무엇입니까?
  2. 데이터베이스 인덱스는 어떻게 작동하나요?

간단한 설명!!!!!!!!!!!!

인덱스는 테이블의 특정 열에 대한 값을 저장하는 데이터 구조일 뿐입니다.테이블의 열에 인덱스가 생성됩니다.

예를 들어, 이름, 나이, 주소라는 세 개의 열이 있는 User라는 데이터베이스 테이블이 있습니다.User 테이블에 수천 개의 행이 있다고 가정합니다.

이제 이름이 'John'인 사용자의 모든 세부 정보를 찾기 위해 쿼리를 실행한다고 가정해 보겠습니다.다음 쿼리를 실행하면.

SELECT * FROM User 
WHERE Name = 'John'

데이터베이스 소프트웨어는 문자 그대로 User 테이블의 모든 단일 행을 조사하여 해당 행의 이름이 'John'인지 확인해야 합니다.시간이 오래 걸립니다.
여기서 인덱스는 "검사해야 하는 테이블의 레코드/행 수를 본질적으로 줄여 검색 쿼리 속도를 높이는 데 사용됩니다".
색인을 만드는 방법

CREATE INDEX name_index
ON User (Name)

인덱스는 열 값으로 구성됩니다(예:John) 한 테이블에서 해당 값이 데이터 구조에 저장된다는 사실을 알 수 있습니다.
이제 데이터베이스는 인덱스를 사용하여 John이라는 직원을 찾습니다. 인덱스는 아마도 사용자 이름을 기준으로 알파벳순으로 정렬되기 때문입니다.그리고 정렬되어 있기 때문에 "J"로 시작하는 모든 이름이 색인에서 서로 바로 옆에 있기 때문에 이름 검색이 훨씬 더 빠릅니다!

그냥 빠른 제안..인덱싱에는 추가 쓰기 및 저장 공간이 필요하므로 애플리케이션에 더 많은 삽입/업데이트 작업이 필요한 경우 인덱스가 없는 테이블을 사용하는 것이 좋지만 더 많은 데이터 검색 작업이 필요한 경우 인덱싱된 테이블을 사용해야 합니다.

데이터베이스 색인을 책의 색인으로 생각하십시오.개에 관한 책이 있고 예를 들어 독일 셰퍼드에 대한 정보를 찾고 싶다면 책의 모든 페이지를 넘겨서 원하는 것을 찾을 수 있지만 이는 물론 시간이 많이 걸리고 그리 많지는 않습니다. 빠른.또 다른 옵션은 책의 색인 섹션으로 이동한 다음 찾고 있는 개체의 이름(이 경우 German Shepherds)을 사용하고 페이지 번호를 확인하여 원하는 내용을 찾을 수 있다는 것입니다. 원하는 것을 빨리 찾으세요.데이터베이스에서 페이지 번호는 엔터티가 위치한 디스크의 주소를 데이터베이스에 지시하는 포인터를 의미합니다.동일한 German Shepherd 비유를 사용하여 다음과 같은 것을 가질 수 있습니다("German Shepherd", 0x77129). 여기서 0x77129는 German Shepherd에 대한 행 데이터가 저장되는 디스크의 주소입니다.

간단히 말해서, 인덱스는 쿼리 검색 속도를 높이기 위해 특정 열의 값을 테이블에 저장하는 데이터 구조입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top