답변:
인덱스 생성은 본질적으로 정렬 작업 이므로 n log n평균적으로 순서의 증가 복잡성 이 있습니다 (일부 경우에는 더 나아질 수 있으며 훨씬 나쁘지는 않을 수 있음).
모든 관련 데이터 페이지가 RAM에 있고 이미 RAM에 있고 인덱스도 맞으며 DBMS가 작성이 완료되기 전에 인덱스 페이지를 강제로 쓰지 않는 경우 (인덱스 블록은 디스크에서 여러 번 업데이트되지 않음) 그런 다음 결과 색인을 디스크에 쓰는 속도가 정렬을 수행하는 데 걸리는 시간보다 훨씬 중요합니다. 따라서 행 수와 색인 작성 시간 사이의 선형 관계에 가까워 질 수 있습니다. 그러나 더 나쁜 경우를 가정하면 불쾌하게 놀라지 않을 것입니다!
작업 중에 프로덕션 데이터베이스에 대한 액세스를 중지하지 않는 한 인덱스 생성은 IO 대역폭 및 / 또는 다른 활동과의 잠금을 위해 경쟁하므로 타이밍 추정 테스트를 수행하는 경우이를 고려해야합니다. 동일하게 구성된 경우에도 다른 시스템에서
또한 테이블의 스핀들에서 인덱스의 스핀들을 분할 할 수 있다면 한 번에 두 개의 디스크에서 작업 할 수 있습니다 (여전히 디스크 컨트롤러의 속도로 제한됩니다) RAID 등이지만 여전히 하나의 디스크보다 빠릅니다).
인덱스를 만드는 것이 완전히 동시 쓰기 작업이 아니라는 것을 알고 있지만 속도가 상당히 빨라집니다.
경고 : 나는 MSSQL 사람이므로 MySQL에 대해 잘 모르겠지만 분할 스핀들 개념이 SQLServer 및 Oracle에만 국한되지 않는다고 상상해야합니다 (IIRC에 대해 이야기 한 것을 들었습니다) ). 나는 그 개념을 설정하는 방법을 모른다. 그러나 SQLServer 용어에서는 별도의 파일 그룹이 PRIMARY있고 다른 파일 그룹에 인덱스를 넣는 것을 의미 합니다. 다른 파일 PRIMARY그룹은 관련되지 않은 스핀들 세트에 할당됩니다 (스핀 서 배치 대 파일 그룹은 완전히 다른 이야기입니다)
따라 다릅니다.
변수 # 1 : MySQL이 즉석에서 인덱스를 빌드하도록 선택하거나 모든 데이터가 들어올 때까지 기다린 경우 정렬 등을 수행하여 인덱스를 빌드하십시오. 참고 : UNIQUE 인덱스를 확인하려면 UNIQUE 인덱스 (제 생각에)를 즉시 작성해야합니다. InnoDB의 PRIMARY KEY는 데이터와 함께 저장되거나 그 반대로도 명시 될 수 있으므로 무작위로 작성해야합니다.
변수 # 2 : 색인은 데이터 (예 : AUTO_INCREMENT 또는 타임 스탬프) 대 임의 (GUID, MD5) 또는 그 사이 (부품 번호, 이름, friend_id) 사이의 데이터를 추적합니다.
변수 # 3 (인덱스가 즉시 구축 된 경우) : 인덱스가 캐시 (key_buffer 또는 innodb_buffer_pool)에 맞거나 디스크에 유출 될 수 있습니다.
데이터를 추적하는 인덱스는 # 1에 대한 답변에 관계없이 효율적이고 사실상 선형입니다.
임의의 ID는 고통입니다. 인덱스가 캐시에 맞지 않으면 다른 변수에 관계없이 인덱스를 빌드하는 시간이 선형보다 훨씬 나쁩니다. (이 경우 Rolando에 동의하지 않습니다.) PK에 대한 GUID가있는 거대한 InnoDB 테이블은 고통스럽게 느리게 삽입됩니다. 일반 디스크의 경우 초당 100 행을 계획합니다. SSD가있는 경우 1000입니다. LOAD DATA 및 배치 된 INSERT는 랜덤 스토리지의 속도 저하를 지나치지 않습니다.
3.53에서 5.6까지 – 별다른 변화는 없었습니다.
여러 스핀들? RAID 스트라이핑은 여기와 여기에 수동으로 할당하는 것보다 거의 모든 상황에서 더 좋습니다. 수동 분할은 불균형 상황을 초래합니다. 테이블 스캔이 데이터 디스크에 멈춰 있습니다. 인덱스 전용 작업이 인덱스 디스크에 붙어 있습니다. 단독 쿼리는 먼저 인덱스 디스크에 도달 한 다음 데이터 디스크에 겹칩니다 (중복 없음). 기타