MySql 인덱스 디자인

데이터베이스 인덱스는 데이터베이스 테이블의 데이터를 빠르게 쿼리하고 업데이트하는 데 도움이 되는 데이터베이스 관리 시스템의 정렬된 데이터 구조입니다. 인덱스 구현은 일반적으로 B-트리와 그 변형 B+-트리를 사용합니다.

데이터 외에도 데이터베이스 시스템은 특정 검색 알고리즘을 만족하는 데이터 구조를 유지하므로 이러한 데이터 구조는 어떤 방식으로든 데이터를 참조(지시)하므로 이러한 데이터 구조에 고급 검색 알고리즘을 구현할 수 있습니다. . 이 데이터 구조는 인덱스입니다.

테이블에 인덱스를 설정하려면 지불해야 하는 비용이 있습니다. 첫째, 데이터베이스의 저장 공간이 늘어나고, 둘째, 데이터 삽입 및 수정에 더 많은 시간이 걸립니다(인덱스도 이에 따라 변경되기 때문).

그림은 가능한 색인 생성 방법 중 하나를 보여줍니다. 왼쪽에는 총 2개의 열과 7개의 레코드가 있는 데이터 테이블이 있습니다. 가장 왼쪽은 데이터 레코드의 물리적 주소입니다(논리적으로 인접한 레코드가 디스크에서 반드시 물리적으로 인접한 것은 아닙니다). Col2의 검색 속도를 높이기 위해 오른쪽에 표시된 것처럼 이진 검색 트리를 유지할 수 있습니다. 각 노드에는 해당 데이터 레코드의 물리적 주소에 대한 포인터와 인덱스 키 값이 포함되어 있습니다. O(log2n)의 이진 검색 복잡도 내에서 해당 데이터를 얻습니다.

색인을 생성하면 시스템 성능이 크게 향상될 수 있습니다.

첫째, 고유 인덱스를 생성하면 데이터베이스 테이블의 각 데이터 행에 대한 고유성을 보장할 수 있습니다.

둘째, 데이터 검색 속도를 크게 높일 수 있는데, 이는 인덱스를 만드는 주요 이유이기도 합니다.

셋째, 테이블 간의 연결 속도를 높일 수 있는데, 이는 특히 데이터의 참조 무결성을 달성하는 데 의미가 있습니다.

넷째, 데이터 검색을 위해 그룹화 및 정렬 절을 사용하면 쿼리에서 그룹화 및 정렬하는 시간도 크게 줄일 수 있습니다.

5. 인덱스를 사용하면 쿼리 프로세스 중에 최적화 숨기기를 사용하여 시스템 성능을 향상시킬 수 있습니다.

인덱스를 추가하면 많은 이점이 있는데, 테이블의 모든 열에 대해 인덱스를 생성해 보는 것은 어떨까요? 왜냐하면 인덱스를 추가하는 것에도 단점이 많기 때문입니다.

먼저 인덱스를 생성하고 유지하는 데 시간이 걸리며, 이 시간은 데이터 양이 늘어날수록 늘어납니다.

둘째, 인덱스는 데이터 테이블이 차지하는 데이터 공간 외에 각 인덱스도 일정량의 물리적 공간을 차지해야 합니다. 더 커질 것입니다.

셋째, 테이블의 데이터 추가, 삭제, 수정 시 인덱스를 동적으로 유지해야 하므로 데이터 유지 속도가 저하됩니다.

인덱스는 데이터베이스 테이블의 특정 열에 구축됩니다. 인덱스를 생성할 때 인덱스를 생성할 수 있는 열과 인덱스를 생성할 수 없는 열을 고려해야 합니다.

일반적으로 다음 열에 인덱스를 생성해야 합니다.

1. 자주 검색되는 열에서는 검색 속도가 빨라질 수 있습니다.

2. 기본 키 열, 조직 테이블에서 열의 고유성과 데이터 배열 구조를 강제합니다.

3. 연결에 자주 사용되는 열에서 이러한 열은 주로 외래 키이므로 속도가 빨라질 수 있습니다.

4. 인덱스가 정렬되어 있고 지정된 범위가 연속이므로 범위를 기준으로 자주 검색해야 하는 열에 인덱스를 만듭니다. 자주 정렬해야 하는 열에 인덱스를 만듭니다. 인덱스가 정렬되었으므로 쿼리에서 인덱스 정렬을 사용하여 정렬 쿼리 시간을 단축할 수 있습니다.

6. 인덱스를 만듭니다. 조건 판단 속도를 높이기 위해 WHERE 절에서 자주 사용되는 열에 대한 인덱스를 지정합니다.


또한 일부 열에 대해서는 인덱스를 생성하면 안 됩니다. 일반적으로 인덱스를 생성해서는 안 되는 컬럼은 다음과 같은 특징을 가지고 있습니다.

1. 쿼리에서 거의 사용되거나 참조되지 않는 컬럼에 대해서는 인덱스를 생성하면 안 됩니다. 이는 이러한 열이 거의 사용되지 않기 때문에 인덱싱 여부에 관계없이 쿼리 속도가 향상되지 않기 때문입니다. 반대로, 인덱스 추가로 인해 시스템 유지 속도가 감소하고 필요한 공간이 증가합니다.

둘째, 데이터 값이 적은 열의 경우 인덱스를 늘리면 안 됩니다. 이는 이러한 컬럼은 인사 테이블의 성별 컬럼과 같이 값이 매우 적기 때문에 질의 결과에서는 결과 세트의 데이터 행이 테이블의 데이터 행 중 큰 부분을 차지하기 때문입니다. 테이블에서 검색해야 할 데이터 행의 비율이 엄청납니다. 인덱스를 늘려도 검색 속도는 크게 향상되지 않습니다.

셋, 텍스트, 이미지, 비트 데이터 유형으로 정의된 열에는 인덱스를 추가하면 안 됩니다. 이는 이러한 열의 데이터 볼륨이 상당히 크거나 값이 거의 없기 때문입니다.

넷째, 수정 성능이 검색 성능보다 훨씬 높을 경우 인덱스를 생성해서는 안 됩니다. 수정 성능과 검색 성능이 서로 상반되기 때문이다. 인덱스를 추가하면 검색 성능은 향상되지만 수정 성능은 저하됩니다. 인덱스를 줄이면 수정 성능이 향상되고 검색 성능이 저하됩니다. 따라서 수정 성능이 검색 성능보다 훨씬 높을 경우에는 인덱스를 생성하지 않아야 합니다.


데이터베이스 디자이너에서는 데이터베이스 기능에 따라 고유 인덱스, 기본 키 인덱스, 클러스터형 인덱스의 세 가지 유형의 인덱스를 생성할 수 있습니다.

고유 인덱스

고유 인덱스는 두 행이 동일한 인덱스 값을 가질 수 없는 인덱스입니다. 대부분의 데이터베이스는 기존 데이터에 중복된 키 값이 있는 경우 새로 생성된 고유 인덱스를 테이블과 함께 저장하는 것을 허용하지 않습니다. 데이터베이스는 테이블에 중복 키 값을 생성하는 새 데이터 추가를 방지할 수도 있습니다. 예를 들어, 직원 테이블에 있는 직원의 성(lname)에 대해 고유 인덱스가 생성되면 두 명의 직원이 동일한 성을 가질 수 없습니다.

기본 키 인덱스

데이터베이스 테이블에는 테이블의 각 행을 고유하게 식별하는 값을 갖는 열 또는 열 조합이 있는 경우가 많습니다. 이 열을 테이블의 기본 키라고 합니다. 데이터베이스 다이어그램에서 테이블에 대한 기본 키를 정의하면 특정 유형의 고유 인덱스인 기본 키 인덱스가 자동으로 생성됩니다. 인덱스에서는 기본 키의 각 값이 고유해야 합니다. 또한 쿼리에 기본 키 인덱스가 사용될 때 데이터에 빠르게 액세스할 수 있습니다.

클러스터형 인덱스

클러스터형 인덱스에서 테이블 행의 물리적 순서는 키 값의 논리적(인덱스) 순서와 동일합니다. 테이블에는 클러스터형 인덱스가 하나만 포함될 수 있습니다. 인덱스가 클러스터형 인덱스가 아닌 경우 테이블 행의 물리적 순서는 키 값의 논리적 순서와 일치하지 않습니다. 클러스터형 인덱스는 일반적으로 비클러스터형 인덱스보다 더 빠른 데이터 액세스를 제공합니다.

위 내용은 MySql 인덱스 디자인 내용입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지(m.sbmmt.com)를 참고해주세요!