2009-12-31 4 views
4

나는 꽤 큰 테이블 (100 ~ GB)에 대해 실행하는 일부 삭제 쿼리를 가지고 있고, 나는 그들에게 가능한 한 많은 최적화 할 :MySQL의 문 최적화 삭제

delete from table1 where column1 < date_sub(now(), interval 100 hour); 

, 컬럼 내가하는 datetime 열입니다 이 열에 대한 색인을 작성하면 삭제 속도가 빨라 집니다. 그 외에, 내가 여기서 할 수있는 건? date_sub() 함수를 사용하면 쿼리 속도가 느려 집니까? 쿼리를 실행하기 전에 그 값을 계산해야합니까?

delete from table2 where column2 = x; 

column2는 table2의 기본 키이므로 이미 mysql 설명서에 따라 색인입니다. 제 질문은 : 인덱스 종류가 PRIMARY이고, INDEX과 같습니까? 속도 향상을 위해 INDEX 종류의 다른 색인을 만들어야합니까?

delete from table3 where column3 = y; 

table3에는 column3 및 column4 인 복합 기본 키가 있습니다. 그래서 기본 키 인덱스가 있지만 삭제 쿼리를 column4, column3에 대해 별도의 인덱스를 만들지 않습니다 이후로 사용합니까? 또는 결합 된 기본 키가 그것을 할 것인가?

나는 이것들이 꽤 기본적인 질문이라고 생각하지만, 나의 상황에 특정한 확실한 대답을 찾을 수 없기 때문에 어떤 도움을 주시면 감사하겠습니다!

+0

첫 번째 단계는 해당 삭제 명령문에서'EXPLAIN'을 사용하여 수행중인 작업을 확인하는 것입니다. 필요할 경우 붙여 넣으십시오. – Schwern

+2

'EXPLAIN'은'SELECT' 문에서만 작동합니다 (아직). –

+0

나는 column1이'DATETIME'이 아니라'DATE'라고 가정한다. 그렇지 않으면 1 시간 간격으로 바보가됩니다. – Schwern

답변

2

난은 삭제 속도를 높일 것이 열의 인덱스를 만드는 가정합니다.

인덱스가 나중에 사용할 수 있도록 인덱스에 대해 업데이트되어야하기 때문에 올바르지 않습니다.

쿼리를 늦추려면 date_sub() 함수를 사용 하시겠습니까?

아니오, 열 값을 기반으로하지 않으므로 괜찮습니다. C 럼 값에 대해 수행 된 함수는 C 럼에 인덱스가 존재하는 경우이를 사용할 수 없도록합니다.

인덱스 종류가 "PRIMARY"이면 "INDEX"와 같습니까?

주요 부분은 해당 색인의 값이 고유하다는 것을 보장합니다.

내가 속력을 내기 위해 "INDEX"종류의 다른 색인을 만들어야합니까?

아니요. 또한 MySQL은 유형에 따라 단일 테이블에 정의 할 수있는 인덱스의 총 크기를 제한합니다. InnoDB 테이블의 경우 767 바이트는 stated index prefix limitation입니다. MyISAM 테이블의 경우 1,000 바이트입니다.

table3에는 column3 및 column4 인 복합 기본 키가 있습니다. 그래서 기본 키 인덱스가 있지만 삭제 쿼리를 column4, column3에 대해 별도의 인덱스를 만들지 않습니다 이후로 사용합니까? 또는 결합 된 기본 키가 그것을 할 것인가?

두 설정을 모두 테스트하십시오. &을 결정하십시오. 나는 추가적인 색인이 필요하다고 생각하지 않는다.당신의 DELETE가 해당 테이블에있는 행의 대다수를 제거하기위한 것입니다 경우

9

, 사람들이 자주 수행하는 것이 한 가지 사본은 당신이 밖으로 닦아 DROP TABLE 또는 TRUNCATE을 사용 후 중복 테이블에 유지하고 싶은 단지 행입니다 원래 테이블을 훨씬 더 빠르게.

인덱스가 삭제해야 할 행을 찾는 데 도움이 될 수 있지만 삭제하려면 인덱스를 업데이트해야합니다. 많은 행을 삭제 한 후 인덱스가 불균형 일 수 있으며 OPTIMIZE TABLE을 사용하여 유지 관리해야합니다.

함수는 상수 표현식 (행마다 달라지지 않음)이므로 쿼리 최적화 프로그램은 문제를 해결하고 계산을 한 번 수행해야합니다.

기본 키에 대한 추가 색인을 만들 필요가 없습니다. 기본 키 제약 조건은 암시 적으로 비 기본 키 인덱스와 동일한 이점을 제공하는 인덱스를 만듭니다.

검색 색인이 색인의 가장 왼쪽 열을 참조하는 경우 복합 색인은 단일 열 색인처럼 유용 할 수 있습니다. "아마"주의해야 할 점은 개별 인덱스 노드가 더 커져서 인덱스를 캐쉬하기 위해 더 많은 메모리가 필요하기 때문입니다. 그러나 이것은 다른 모든 단일 컬럼 인덱스를 생성하지 않을만큼 작은 요소입니다.