내 데이터베이스에는 두 개의 큰 테이블이 있습니다. 첫 번째 행 (A)에는 170 만 개의 행이 있고 두 번째 행 (B)에는 2.1 백만 개가 있습니다. A와 B의 레코드는 상당히 동일한 크기입니다.MySQL - 큰 테이블의 기본 문제
A에서 어떤 작업을 할 수 있습니다. 시간이 걸리지 만 작동합니다. B에서는 아무것도 할 수 없습니다. 간단한 선택 카운트 (*)조차도 단 한 건도 없습니다. 문제는 어떤 오류도 보이지 않는다는 것입니다. 프로세스 목록을 표시 할 때 단지 "업데이트 중"이라고 표시됩니다.
1.7에서210 만 사이의 작은 델타 (백분율 기준)가 (가장 간단한 작업을 수행 할 수 없어도 모든 것을 할 수있는 것에서부터) 그러한 차이를 만들 수 있다는 것이 이상하게 보입니다.
2 백만 행의 하드 제한이있을 수 있습니까?
저는 Linux 2.6 이상이며 innoDB를 사용합니다.
감사합니다. 피에르
각 행의 데이터 양이 총 행 수보다 많은 것으로 나타납니다. 행에 데이터가 거의없는 경우 반환되는 최대 행 수는 데이터가 더 많은 행보다 높습니다. 추가 정보를 원하시면이 링크를 확인하십시오
http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html
행 크기 (한 행을 저장하는 데 필요한 바이트 수) 두 번째 테이블 훨씬 클 수 있습니다. Count (*)는 전체 테이블 스캔을 요구할 수 있습니다. 즉, 디스크의 전체 테이블을 읽는 것입니다. 큰 행은 더 많은 I/O와 더 긴 시간을 의미합니다.
인덱스의 유무가 다를 수 있습니다.
초기 게시물에서 말한 것처럼 두 테이블은 상당히 유사하므로 두 테이블에서 행 크기가 상당히 비슷합니다. 그래서 나는 조금 놀랐다. 그리고 어쩌면 아마도 어딘가에 2 백만의 한도가 설정되었다고 생각하기 시작했다.
내 테이블이 손상된 것으로 나타났습니다. 일부 레코드 (다른 테이블과의 조인 사용)에 여전히 액세스 할 수 있었고 mySQL이 "불평하지"않았기 때문에 기이합니다. 나는 CHECK TABLE을 실행 함으로서 발견했다 : 그것은 어떤 에러도 반환하지 않았지만 매번 mysqld를 추락시켰다. ...
어쨌든, 당신의 도움에 감사드립니다.
피에르
Cassis the Magnificent는 귀하의 색인 생성 전략과 관련이 있습니다. – JohnFx
테이블에서 더 많은 데이터가 더 천천히 나타납니다. 사실이야. 그러나 좋은 색인 생성이 도움이 될 수 있도록 색인을 자세히 살펴보십시오. – B4NZ41
또한 InnoDB에 관한 db 설정을 확인하십시오. 디폴트 설정은 InnoDB 용으로 최적화되어 있지 않습니다. –