필드를 고유하게 만들면 색인이 생성됩니까?

10

내가 한 경우 unique필드에 제약을, 나 또한 확장 삽입 시간을 얻기 위해 해당 필드에 인덱스를 만들 필요합니까? 또는 이것이 나를 위해 이루어 졌습니까 (사용하는 색인에 공개적으로 액세스 할 수 없더라도)

특히, 프로토 타입 제작을 위해 Apache Derby와 협력하고 있지만, 가까운 시일 내에 MySQL로 옮길 것입니다. 또한 SQL 표준에 이것에 대해 말하는 것이있을 수 있기를 바랍니다.

이 필드로 검색 할 필요가 없으므로 쓸모없는 색인을 만들지 않습니다. 그러나 O(n)삽입 시간 보다 쓸모없는 색인을 원합니다 .

— 코 시카
소스

2

내가 아는 바로는 고유 인덱스를 사용하여 고유 제약 조건이 구현됩니다. 이 질문 에서이 상황에 대한 의견을 볼 수 있습니다 : 고유 인덱스 대신 고유 제약 조건을 사용해야하는 시점?

— Marian

해당 링크에 대한 @Marian 감사합니다. 매우 통찰력이있었습니다.

— corsiKa

2

--편집하다--

내 원래의 답변 (아래)은 아마도 unique제약 문제를 다루지 않기 때문에 전혀 유용하지 않을 것 입니다. 다른 사람들이 말했듯이, 이러한 제약 조건은 일반적으로 암시 적 고유 인덱스로 구현됩니다. 특별한 경우 이것은 사실이 아닐 수 있습니다 (예 : disable novalidateOracle의 경우).

질문은 다음과 같습니다. 인덱스없이 고유성을 시행 할 수 있습니까? 일반적으로 대답은 아니지만 경우에 따라 클러스터형 인덱스 는 인덱스와 테이블이 동일한 객체임을 의미합니다.

-끝 편집-

당신은 "O (n) 삽입 시간보다 오히려 쓸모없는 인덱스를 갖고 싶다"고 말했지만 일반적으로 데이터베이스에는 O (n) 삽입 시간이 없습니다. 고려해야 할 두 가지 경우가 있습니다.

인덱스가 있거나없는 일반 테이블 :

새 행이 힙 맨 위에 덤프됩니다. RDBMS는 아마도 1 블록 만 보이 므로 O (1)뿐만 아니라 매우 작은 O (1)입니다.

테이블에 인덱스가 있으면 행에 대한 포인터가 각각에 추가됩니다. 이것은 일반적으로 O (log (n)) 작업입니다.
인덱스 구성 테이블 또는 Oracle 용 클러스터 또는 SQL Server 용 클러스터형 인덱스 와 같은 클러스터링이 진행중인 테이블 :

새로운 행이 분할 또는 오버 플로우 블록이 발생할 수 있습니다 특정 블록에 삽입하지만 O 아직도 무슨 일이 생기면된다 (로그 (N)) 또는 더 나은 , 블록을 찾기 위해 사용되는 B- 트리 또는 유사한 구조에 의해 발생합니다.

— 잭은 topanswers.xyz 시도
소스

그러나 인덱스가없는 고유성 O(n)은 전체 테이블을 확인해야합니다. 그것이 내가 피하려고하는 것입니다.

— corsiKa

이것은 실제로이 질문에 대한 최고의 답변입니다! +1

— RolandoMySQLDBA

@ 트릭-네, 처음에는 오해했습니다. 지수는 내가 두려워하는 고유성 제약에 대해 지불하는 가격입니다. 귀하의 경우에 클러스터 색인을 사용할 수 있습니까?

— 잭 topanswers.xyz 시도라고

1

@JackPDougless 표준 "인덱스"를 사용하고 O(lg n)삽입 시간을 얻을 수 있습니다. 그건 문제가되지 않습니다. 내 질문은 적절한 삽입 시간을 얻으려면 인덱스가 필요하다는 것을 알고 시스템이 나에게 인덱스를 만드는 것입니다.

— corsiKa

2

기본 키> = 고유> = 색인 == 키

InnoDB 데이터는 PK에 의해 정렬됩니다. MyISAM PK는 UNIQUE와 동일하게 작동합니다.

INSERT는 가지고있는 각각의 모든 인덱스에 "행"을 추가해야합니다. 시간이 좀 걸립니다. (보통 시간이 충분하지 않습니다.) 인덱스는 모두 BTree 형식으로 저장됩니다. MyISAM BTree 블록은 1KB입니다. InnoDB는 16KB를 사용합니다.

InnoDB에 삽입하면 PK와 데이터가 동시에 업데이트됩니다.

MyISAM에 삽입하면 일반적으로 .MYD에 데이터를 "추가"합니다. 별도로 PK에 행을 추가합니다 (있는 경우).

INSERT는 먼저 PRIMARY 또는 UNIQUE 키에 대한 중복 키가 없는지 확인해야합니다. 이것은 색인을 사용하여 수행됩니다. 따라서 UNIQUE 및 FOREIGN KEY CONSTRAINT가 실제로 인덱스를 작성하는 이유는 무엇입니까? 효율적인 캐싱 인 경우 O (logN)이지만 일반적으로 I / O가 아닌 CPU입니다.

— 릭 제임스
소스

UNIQUE제약 조건이 사용자가 만들 색인을 지정하지 않고 색인을 생성 한다고 언급하는 InnoDB 사양에 인용 이 있습니까?

— corsiKa

흠 ... 아니, 몇 년의 경험.

— Rick James

그리고 그것을 테스트하는 방법이 있습니다 ... 2 차 인덱스가없는 테이블을 생성하십시오; SHOW TABLE STATUS-Index_length는 0입니다. 그런 다음 고유 인덱스를 추가하십시오. 표 상태에 이제 무언가가 표시됩니다. (테이블에 사소한 양의 데이터를 넣어야 할 수도 있습니다.)

— Rick James

1

굵게 표시된 질문에 대답하려면 : 예, 필드를 고유하게 만들면 기본 키처럼 색인이 생성됩니다. 사실, 다른 고유 한 (Candidate) 키와 구별하기 위해 자신의 이름을 가진 기본 키 와 관련하여 또 다른 질문으로 이것을 논의 했습니다 .

제약 조건과 관련하여 제약 조건 패러다임이 설정되도록 색인이 생성됩니다. 제약 조건이 제약 조건 패러다임과 별도로 개인적으로 만든 다른 UNIQUE 키를 참조하지 않는 한 UNIQUE 키를 포함하여 중복 인덱스를 제거 할 수 있어야합니다.

이 필드를 검색 할 필요는 없지만 MySQL은 키의 유효성을 확인하고 ON DELETE CASCADE 및 ON UPDATE CASCADE 작업 수행 방법을 결정하기위한 경로로 확인해야합니다.

UNIQUE 인덱스는 테이블의 모든 행에서 튜플 (싱글 톤, 페어, 트리플렛, ..., n- 튜플 등)의 고유성을 보장합니다.

테이블에서 원하는 제약 조건 패러다임을 깨지 않는 한 중복 인덱스를 제거하는 것은 재량입니다.

— RolandoMySQLDBA
소스

1

이것은 내 질문에 대답하지 않습니다. 내 질문은 삽입 시간과 관련이 있습니다. 고유 제한 조건이있는 경우 시스템은 삽입 전에 필드의 고유성을 보장해야합니다. 필드에 색인이없는 경우 전체 테이블 ( O(n)) 을 검색해야합니다 . 인덱스가 있으면 조회 속도가 훨씬 빠릅니다 (아마도 O(lg n)). 그게 내 문제 야 나는 참조 무결성 메커니즘을 잘 알고 있으며 성능에 대해서만 (이 질문의 목적으로) 관심이 있습니다.

— corsiKa