0
MRG 테이블에는 여러 개의 작은 테이블에 걸쳐 1B + 행이 있습니다. 추가 관측치가 MRG 테이블에 추가되어 MRG 테이블이 마지막 기본 테이블에 추가됩니다.MyIsam MRG - 고유성을 관리하는 모범 사례
같은 이유에서 동일한 기본 키를 공유하는 몇 개의 중복 행이있는 것으로 보입니다. 나는 이것이 MRG 테이블의 한계라는 것을 알고 있으며 우리의 경우에는 실제로 문제가되지 않는다 (단순히 쓸데없는 중복을 의미한다). 우리는 복제본이 시스템 충돌 후 삽입되어 아카이브에 삽입되기 전에 임시 테이블에서 복제본을 삭제하는 응용 프로그램의 코드에 의해 재 처리가 제대로 처리되지 않는다고 생각합니다.
너무 많은 처리 시간을 필요로하지 않는 고유성을 유지하는 모범 사례가 있습니까?
질문이 많은 견인력을 갖게 될지 의심 스럽습니다. 나는 MRG를 15 년 전에 사용 했었고, 그 이후로 그것을 사용하는 사람에 대해서는 들어 본 적이 없습니다. MyISAM은 사라지고 있으며, MRG도 함께 가고 있습니다. 'PARTITIONing'은 대체로 그것을 대신합니다; 그러나 그것도 거의 사용하지 않습니다. 거대한 테이블 대신 MRG를 사용하는 이유는 무엇입니까? –
하루에 한 번 수 백만 개의 행이 업데이트됩니다. 더 작은 테이블의 콜렉션을 사용하면 병렬 처리가 가능합니다. 훨씬 빠르고 컴팩트 한 백업이 가능하기 때문에 myIsam을 고수하십시오. 하지만 그렇습니다. 그리 멀지 않은 미래에 분할 된 innodb로 전환 할 가능성이 큽니다. 그 동안 고유성을 강화하기 위해 기본 키가있는 통합 테이블을 사용합니다. 이상적이지는 않지만 일을 수행한다 – user3127882
MyISAM이 PARTITIONing을 처리하므로 유일성 검사. –