MySQL은 외래 키 열을 자동으로 색인합니까?


답변:


229

네,하지만 오직 . Innodb는 현재 외래 키가 구현 된 유일한 배송 테이블 형식입니다.


1
MySQL이 다른 테이블 유형에 대해 색인화되지 않은 열에서 외래 키를 허용한다고 믿을만한 이유가 있습니까?
Robert Gamble

나는 정말로 대답 할 수 없었다. MySQL 6.0에서 릴리스 될 Maria 및 Falcon 스토리지 엔진을 검색하여 색인이없는 열에서 외래 키를 지원하는지 확인할 수 있습니다.
그랜트 림 베르크

분명히 이것은 사실이 아닙니다. 큰 테이블 (1 백만 레코드)과 count (*)가있는 곳에서 fkey =? 15 초가 걸립니다. fkey 열에 색인을 추가하면 이제 1 초가 채 걸리지 않습니다.
AbiusX

다른 테이블과 천만 개의 레코드를 사용한 동일한 실험. 이것은 ofc MySQL 5.1 InnoDB입니다. 테이블에는 세 개의 필드가 있습니다. 하나는 기본 키 정수이고 다른 하나는 이미 색인화되어 있습니다. 세 번째는 다른 테이블의 기본 키에 대한 외래 키입니다. 명시적인 색인을 추가하지 않고 조회하는 데 몇 초가 걸렸습니다. 테이블의 인덱스 표시에도 인덱스가 표시되지 않았습니다.
AbiusX

@AbiusX 5.1이 너무 오래된 것 같습니다. 아래의 MrAlexander의 답변을 참조하십시오.
e2-e4의

131

robert이 게시 한 링크에 지정된대로 인덱스가 자동으로 생성됩니다 .

InnoDB는 외래 키 검사가 빠르며 테이블 스캔이 필요하지 않도록 외래 키 및 참조 키에 대한 인덱스가 필요합니다. 참조 테이블에는 외래 키 열이 동일한 순서로 첫 번째 열로 나열되는 인덱스가 있어야합니다. 이러한 인덱스는 참조 테이블에 존재하지 않으면 자동으로 작성됩니다. (이는 인덱스를 명시 적으로 작성했거나 외래 키 제약 조건을 작성하지 못한 일부 이전 버전과 대조적입니다.) 제공된 경우 index_name이 앞에서 설명한대로 사용됩니다.

InnoDB 및 FOREIGN KEY 제약


9
문서에서 증명을 제공하는 것으로 선택된 것보다 +1 훨씬 더 나은 답변
Gaz_Edge

6
인용 된 텍스트는 더 이상 MySQL 문서에 포함되지 않은 것으로 보이므로 이것이 여전히 사실인지 확실하지 않습니다.
Courtney Miles

7
@ user2045006 정확한 인용문은 doc 5.0doc 5.6 을 참조하십시오
sactiw

1
현재의 문서들에서는 텍스트에 약간의 변화가 있습니다 (의미가 비슷하다고 가정) :InnoDB permits a foreign key to reference any index column or group of columns. However, in the referenced table, there must be an index where the referenced columns are the first columns in the same order.
Lucas Basquerotto


11

적어도 문서 에 따라 ALTER TABLE (CREATE TABLE 대신)을 수행 하면 링크가 5.1이지만 링크는 5.1이지만 인덱스는 자동으로 인덱스를 얻지 못합니다 .

[...] ALTER TABLE을 사용하여 테이블에 외래 키 제약 조건을 추가 할 때는 필요한 인덱스를 먼저 만들어야합니다.


2
나는 또한 MySQL 5.6에서 시도했고 MariaDB 10과 ALTER TABLE은 색인을 만들었습니다. mysqlindexcheck가 해당 인덱스를 "중복 인덱스"로보고 한 것이 흥미 롭습니다. 삭제하려고했지만 다음 오류가 발생했습니다. "ERROR 1553 (HY000) : 인덱스 'index_name'을 (를) 삭제할 수 없습니다 : 외래 키 제약 조건에 필요합니다." 따라서 해당 인덱스를 삭제하고 외래 키를 유지할 수 없습니다.
Ciprian Stoica

답을 수정하고 싶을 수도 있습니다. MySQL 은 외래 키 검사 가 존재하지 않는 경우 항상 색인을 생성하여 외래 키 검사 속도를 높 입니다. 문서는 외래 키 제약 조건보다 먼저 인덱스를 만들면 속도가 약간 빨라질 수 있다고 말하려고합니다. 예를 들어 외래 키 검사를위한 인덱스 역할을 할 수있는 복합 키 인덱스는 중복 인덱스를 자동 생성하는 대신 InnoDB에서 사용할 수 있습니다.
BMiner

7

5.7 문서 에서 인용문을 찾는 사람들을 위해 :

MySQL은 외래 키 및 참조 키에 대한 인덱스를 요구하므로 외래 키 검사가 빠르며 테이블 스캔이 필요하지 않습니다. 참조 테이블에는 외래 키 열이 동일한 순서로 첫 번째 열로 나열되는 인덱스가 있어야합니다. 이러한 인덱스는 참조 테이블에 존재하지 않으면 자동으로 작성됩니다. 외래 키 제약 조건을 적용하는 데 사용할 수있는 다른 인덱스를 만들면이 인덱스가 나중에 자동으로 삭제 될 수 있습니다. 주어진 경우 index_name이 앞에서 설명한대로 사용됩니다.


4

명시된 바와 같이 InnoDB에 적용됩니다. 처음에는 다른 많은 (특히 MS SQL 및 DB2)이 그렇지 않은 것이 이상하다고 생각했습니다. 테이블 스페이스 스캔은 테이블 행이 매우 적을 때 인덱스 스캔보다 낫습니다. 따라서 대부분의 경우 외래 키를 인덱싱하려고합니다. 그런 다음 필자가 일종의 히트를 쳤다-이것이 반드시 독립형 (한 열) 인덱스 여야한다는 것을 의미하지는 않습니다 .MySQL의 자동 FK 인덱스에 있습니다. 따라서 이것이 MS SQL, DB2 (Oracle I 'm 모르겠 음) 등이 DBA에 맡겨진 이유 일 수 있습니다. 큰 테이블의 여러 인덱스가 모두 성능 및 공간에 문제를 일으킬 수 있습니다.


복합 키 인덱스에 대한 좋은 지적이 있습니다. 그러나 새로 생성 된 복합 키 인덱스가 외래 키 검사를 빠르게 수행해야하는 의무를 충족하는 경우 MySQL은 자동 생성 된 단일 키 인덱스를 자동 / 자동으로 삭제합니다. 솔직히 말해서 MS SQL, DB2 등이 왜 그렇게하지 않는지 모르겠습니다. 그들은 변명의 여지가 거의 없다. 외래 키의 자동 생성 인덱스가 해로운 유스 케이스를 생각할 수 없습니다.
BMiner

2

예, Innodb이것을 제공하십시오. FOREIGN KEY절 뒤에 외래 키 이름을 넣거나 MySQL에서 이름을 만들 수 있도록 남겨 둘 수 있습니다. MySQL은 자동으로 foreign_key_name이름을 가진 인덱스를 만듭니다 .

CONSTRAINT constraint_name
FOREIGN KEY foreign_key_name (columns)
REFERENCES parent_table(columns)
ON DELETE action
ON UPDATE action

0

예, Mysql은 외래 키가있는 테이블을 만들 때 자동으로 외래 키를 색인합니다.


-2

인덱스 키를 자동으로 사용할 수 없습니다

ALTER TABLE (NAME OF THE TABLE) ADD INDEX (FOREIGN KEY)

예를 들어 사진과 같은 FOREIGN KEY와 같이 작성한 테이블의 이름입니다 photograph_id. 코드는 다음과 같아야합니다

ALTER TABLE photographs ADD INDEX (photograph_id);
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.