MySQL 단일 테이블 데이터는 500만 행을 초과해서는 안 됩니다. 경험적 값입니까 아니면 황금률입니까?

오늘은 흥미로운 주제에 대해 논의해 보겠습니다. 단일 MySQL 테이블을 데이터베이스와 테이블로 나누려면 얼마나 많은 데이터를 고려해야 할까요? 어떤 사람들은 2천만 행이라고 말하고 다른 사람들은 500만 행이라고 말합니다. 그렇다면 이 값은 어느 정도가 적당하다고 생각하시나요?

중국 인터넷 기술계에서는 단일 MySQL 테이블의 데이터 양이 2천만 행을 초과하면 MySQL의 성능이 크게 떨어진다는 말이 널리 퍼졌습니다. 실제로 이 루머는 바이두에서 시작된 것으로 전해진다. 구체적인 상황은 아마도 이렇습니다.DBA가 MySQL의 성능을 테스트했을 때 단일 테이블의 크기가 2천만 행에 도달하면 SQL 작업의 성능이 급격히 떨어지는 것을 발견했습니다. 그러다가 바이두 엔지니어들이 업계의 다른 회사로 옮겨가서 이 정보를 가지고 왔다고 해서 이 말이 업계에 퍼졌다고 합니다.

나중에 Alibaba의 "Java 개발 매뉴얼"에서는 단일 테이블의 행 수가 500만 개를 초과하거나 단일 테이블의 용량이 2GB를 초과하는 경우에만 데이터베이스 및 테이블 샤딩을 권장한다고 제안했습니다. 이는 알리바바의 황금철칙에 의해 뒷받침됩니다. 따라서 많은 사람들이 빅데이터 스토리지를 설계할 때 이를 표준으로 사용하여 테이블 작업을 수행합니다.

그럼 이 값은 어떤 것이 적절하다고 생각하시나요? 300만 행이나 800만 행이 아니라 500만 행이 아닌 이유는 무엇입니까? 아마도 이것이 알리의 실제 전투 가치 중 최고라고 말할 수 있을까요? 그렇다면 다시 질문이 생깁니다. 이 값은 어떻게 평가됩니까? 잠깐만요, 잠시만 생각해보세요.

사실 이 값은 실제 레코드 수와는 아무런 관련이 없으며 MySQL의 구성 및 머신의 하드웨어와 관련이 있습니다. 성능을 향상시키기 위해 MySQL은 테이블의 인덱스를 메모리에 로드하기 때문입니다. InnoDB 버퍼 크기가 충분하면 메모리에 완전히 로드될 수 있으며 쿼리에 문제가 없습니다. 그러나 단일 테이블 데이터베이스가 특정 크기의 상한에 도달하면 메모리가 인덱스를 저장할 수 없어 후속 SQL 쿼리에서 디스크 IO가 발생하여 성능이 저하됩니다. 물론 이는 특정 테이블 구조의 설계와도 관련이 있으며, 궁극적인 문제는 메모리 제한이다. 여기서 하드웨어 구성을 늘리면 성능이 즉시 향상될 수 있습니다.

그러므로 하위 데이터베이스와 하위 테이블에 대한 내 견해는 실제 요구 사항과 결합되어야 하며 하위 데이터베이스와 하위 테이블 디자인이 과도하게 설계되어서는 안 된다는 것입니다. 프로젝트 초기에는 사용했지만 비즈니스가 성장함에 따라 최적화를 계속할 수 없는 경우 데이터베이스 및 테이블을 샤딩하여 시스템 성능을 향상시키는 것을 고려하십시오. 이에 대해 알리바바의 '자바 개발 매뉴얼'에는 "데이터 양이 3년 안에 이 수준에 도달하지 못할 것으로 예상된다면 테이블 생성 시 데이터베이스를 테이블로 나누지 말라"고 덧붙였다. 그럼 원래 질문으로 돌아가서, 적절한 가치는 무엇이라고 생각하시나요? 내 제안은 자신의 머신의 상황을 종합적으로 평가하는 것입니다. 염두에 두고 있는 표준이 없다면 일시적으로 500만 라인을 통합 표준으로 사용하는 것이 좋습니다. 이는 상대적으로 절충된 값입니다.

더 많은 MySQL 관련 기술 기사를 보려면 MySQL 튜토리얼 열을 방문하여 알아보세요!

위 내용은 MySQL 단일 테이블 데이터는 500만 행을 초과해서는 안 됩니다. 경험적 값입니까 아니면 황금률입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!