2009-08-31 3 views
10

400 만 개의 행이있는 MyISAM 테이블이있는 MySQL 데이터베이스가 있습니다. 일주일에 한 번이 테이블을 약 2000 개의 새 행으로 업데이트합니다. 업데이트 한 후, 나는 다음과 같은 테이블을 변경 :매우 큰 테이블의 MySQL ALTER TABLE - 실행하는 것이 안전할까요?

ALTER TABLE x ORDER BY PK DESC 

나는 내림차순으로 기본 키 필드로 테이블을 주문한다. 이것은 제 개발 기계 (3GB 메모리가있는 Windows)에서 제게 어떤 문제도주지 않았습니다. 3 번 나는 실제 Linux 서버 (512MB RAM - 그리고 매번 약 6 분 동안 결과로 정렬 된 테이블을 얻음)에서 성공적으로 시도했지만, 마지막으로 시도한 결과 약 30 분 후에 쿼리를 중단하고 다시 빌드해야했습니다. 데이터베이스를 백업합니다.

512MB 서버가 그러한 큰 테이블의 alter 문을 처리 할 수 ​​있습니까? ALTER TABLE 명령을 수행하기 위해 임시 테이블이 작성되었음을 읽었습니다.

질문 :이 변경 명령을 안전하게 실행할 수 있습니까? 테이블 변경 예상 시간은 얼마입니까?

+1

"매우 큰 테이블"은 아마도 과장된 것 같습니다. 4M 행은 매우 큰 테이블이 아닙니다. 10 억은 될 수 있습니다. – MarkR

답변

0

나는 대신 PK 값에 의해 정렬 된 뷰를 만들 것이므로 한가지 방법으로 ALTER가 수행되는 동안 그 거대한 테이블을 잠글 필요가 없습니다.

+0

답장을 보내 주셔서 감사합니다 ... 어쨌든 오프라인 상태가되므로 업데이트하는 동안 테이블을 잠그지 않아도됩니다. –

+0

여기보기가 도움이 될 것 같지 않습니다. MySQL은 뷰 해상도를 위해 [MERGE]와 [TEMPTABLE] 두 가지 전략 [1]을 가지고있다. 병합을 사용할 때 정의가 제출 된'SELECT' 문과 병합되기 때문에 어떤 이득도 얻지 못할 것입니다. 'TEMPTABLE'은 이름에서 알 수 있듯이 임시 테이블을 생성합니다. 그러나 임시 테이블을 만드는 것은 원래의 문제의 원인입니다. 따라서 유지 보수를 어렵게하는 것 이외에는 아무 것도 얻지 못할 것입니다. [1] : http://dev.mysql.com/doc/refman/5.0/en/view-algorithms.html – exhuma

3

방금 ​​읽은 것처럼 ALTER TABLE ... ORDER BY ... 쿼리는 특정 시나리오에서 성능을 향상시키는 데 유용합니다. PK 인덱스가 도움이되지 않는다는 것에 놀랐습니다. 그러나 the MySQL docs에서 InnoDB 인덱스를 사용합니다. 그러나 InnoDB는 MyISAM처럼 느려지는 경향이 있습니다. 즉, InnoDB를 사용하면 테이블을 재정렬 할 필요가 없지만 MyISAM의 놀라운 속도는 잃어 버릴 것입니다. 그것은 여전히 ​​가치가있을 수 있습니다.

문제를 설명하는 방식으로, 너무 많은 데이터가 메모리에로드되어있는 것 같습니다 (어쩌면 스와핑이 진행되고 있을지도 모릅니다). 메모리 사용량을 모니터링하여 쉽게 확인할 수 있습니다. 내가 잘 모르는 MySQL로 말하기는 어렵다.

다른 한편으로 나는 당신의 문제가 매우 다른 장소에 있다고 생각한다 : 당신은 4Mio 이상의 행을 포함하는 테이블을 가진 데이터베이스 서버로서 단지 512 메가의 RAM을 가진 머신을 사용하고있다. 그 머신의 전체 테이블에서 매우 메모리가 많이 소모되는 작업. 그것은 512 메가가 거의 충분하지 않을 것으로 보인다.

내가 본 것은 훨씬 더 근본적인 문제입니다. 프로덕션 환경과 매우 다른 환경에서 개발을하고 있습니다. 당신이 설명하고있는 문제의 종류가 예상됩니다. 개발 기계는 생산 기계보다 6 배 많은 메모리를 가지고 있습니다. 나는 프로세서가 훨씬 빠르다고 안전하게 말할 수 있다고 믿는다. 이 경우 프로덕션 사이트를 모방 한 가상 컴퓨터를 만드는 것이 좋습니다. 그렇게하면 생산 현장을 방해하지 않고 프로젝트를 쉽게 테스트 할 수 있습니다.

+0

InnoDB의 최근 개선으로 대부분의 시나리오에서 MyISAM과 동등한 성능을 보였습니다. –

+0

@Bill : 흥미 롭습니다. 그래서 InnoDB가 실제로 갈 길이 란 말을 할 수 있습니다. 동일한 성능, 더 많은 기능. 당신의 프로필을 본 후에, 나는 당신을 믿을 수 있다고 생각합니다. 아직도 그걸 가지고 갈 증거가 있습니까? – exhuma

0

당신이해야 할 일은 전체 테이블과 모든 인덱스를 다시 작성하는 것입니다. 특히 데이터가 램에 맞지 않는 경우에는 비용이 많이 드는 작업입니다. 완료 될 것입니다, 그러나 데이터가 램에 들어 가지 않으면 대단히 느려질 것입니다. 특히 많은 인덱스가있는 경우에는 더욱 그렇습니다.

프로덕션 환경에서 이러한 작은 메모리가있는 컴퓨터를 실행하기로 결정한 경우 귀하의 판단에 의문이 있습니다. 어쨌든 :

  • 이 ALTER TABLE은 실제로 필요합니까? 어떤 특정 쿼리를 사용하여 속도를 높이고 자 시도 했습니까?
  • 개발 기계를 더 생산적이라고 생각하십니까?내 말은, 더 많은 메모리를 가진 dev 박스를 사용하는 것은 결코 좋은 생각이 아니며, 다른 OS를 사용하는 것은 분명히 아닙니다.

도움을주기 위해 할 수있는 조정이있을 수 있습니다. 주로 스키마 (특히 인덱스)에 따라 다릅니다. 4M 행은 그다지 많지 않습니다 (정상 양의 RAM이있는 기계의 경우).

+0

안녕하세요 마크 ... 답장을 보내 주셔서 감사합니다 ... 메모리상의 한도는 예산 고려 사항으로 인한 것입니다 ... 사이트가 서버의 사양을 업그레이드한다면 ... 그러나 그 이유는 ALTER를하는 것은 사용자가이 테이블을 쿼리하는 저장 프로 시저를 실행할 수 있으며 "가장 먼저 삽입 된"순서로 결과를 반환하려고합니다. 쿼리 자체에서 ORDER BY를 사용하여이 작업을 수행 할 수 있지만 불행히도이 작업은 비용이 많이 들고 쿼리가 상당히 느려질 수 있습니다. 따라서 테이블을 업데이트 할 때 PK 순서로 사전 순서를 지정하여이 ORDER BY를 건너 뜁니다. –

+0

ORDER BY 쿼리를 정렬 할 필요가 없도록 적절한 인덱스를 만들어야합니다. EXPLAIN을 사용하여이를 확인할 수 있습니다 (쿼리가 SP에없는 경우에만). ALTER TABLE ... ORDER BY는 솔루션이 아닙니다. 주문 된 데이터가 보장되는 것은 아닙니다. – MarkR

+0

안녕하세요. 이 테이블에는 8 개의 인덱스가 있습니다. PK 필드 (desc로 정렬하기를 원함)를 각 인덱스의 맨 오른쪽 부분에 추가하면 색인은 WHERE 절을 만족시키는 데 계속 사용되며, 주문 필드가 맨 왼쪽이 아닐지라도 인덱스의 접두어 (각 인덱스의 맨 오른쪽에 추가 할 예정 임), ORDER BY에 여전히 사용할 수 있습니까? 감사. –

0

InnoDB를 사용하는 경우 삽입 후 또는 쿼리 할 때 ORDER BY 명시 적으로 수행 할 필요가 없습니다. MySQL의 5.0 매뉴얼에 따르면, 쿼리 결과에 대한 기본 키 순서에 이노 이미 기본값 :

http://dev.mysql.com/doc/refman/5.0/en/alter-table.html#id4052480

MyISAM 테이블은 오직에 추가 할 경우 잘 작동 할 수있는 대신에, 기본적으로 삽입 순서대로 레코드를 반환 표를 사용하여 UPDATE 쿼리를 사용하여 모든 행을 수정하십시오.

1

은 기본 키 auto_increment입니까? 그렇다면 ALTER TABLE ... ORDER BY를 수행하면 모든 것이 순서대로 삽입되므로 아무 것도 향상시키지 않습니다.

(많은 삭제가없는 한)

+0

답장을 보내 주셔서 감사합니다. 그러나 문제는 기본 키 순서의 역순으로 결과를 제공하려는 것입니다. –

+1

그런 다음 저장 프로 시저, 쿼리 및 서버 설정을 최적화해야하며 ALTER TABLE, myisam 테이블의 버크 (quirk) 때문에 작동합니다. 저장된 프로 시저와 쿼리의 성능이 정렬 할 때 문제가 발생하면 새 질문을 열고 CREATE TABLE 문, 쿼리/프로 시저 및 EXPLAIN 출력을 게시해야합니다. 그러면 쿼리 또는 서버 구성을 최적화하는 데 도움을받을 수 있습니다. – longneck

관련 문제