1,000,000 개의 레코드가있는 MySQL InnoDB 테이블이 있습니다. 너무 많나요? 아니면 데이터베이스가이 이상을 처리 할 수 있습니까? 일부 쿼리 (예 : 테이블에서 마지막 행 가져 오기)가 100 개 행보다 100 만 행이있는 테이블에서 더 느리다는 것을 알았 기 때문에 묻습니다.
답변:
1000000 레지스터가있는 MySQL InnoDB 테이블이 있습니다. 너무 많나요?
아니요, 1,000,000 개의 행 (AKA 레코드)은 데이터베이스에 비해 너무 많지 않습니다.
일부 쿼리 (예 : 테이블의 마지막 레지스터 가져 오기)가 100 만 개의 레지스터가있는 테이블보다 100 만 개의 레지스터가있는 테이블에서 더 느리다는 것을 알았 기 때문에 묻습니다.
그 진술에서 설명 할 것이 많다. 일반적인 용의자는 다음과 같습니다.
97,000,000 개 이상의 레코드 ( 30GB 데이터 파일 ) 가있는 데이터베이스가 있으며 문제가 없습니다.
테이블 인덱스 를 정의하고 개선하는 것을 잊지 마십시오 .
따라서 1,000,000 은 많지 않다는 것이 분명합니다 ! (하지만 색인을 생성하지 않으면 예, 많음)
저는 이것이 일반적인 오해라고 생각합니다. 데이터베이스 확장 성과 관련하여 크기는 방정식의 일부일뿐입니다. 어렵거나 더 어려운 다른 문제가 있습니다.
작업 세트의 크기 (즉, 메모리에로드되고 적극적으로 작업해야하는 데이터의 양). 데이터를 삽입하고 아무것도하지 않으면 실제로 해결하기 쉬운 문제입니다.
어떤 수준의 동시성이 필요합니까? 삽입 / 읽는 사용자가 한 명뿐입니까? 아니면 한 번에 수천 개의 클라이언트가 작동합니까?
어떤 수준의 약속 / 내구성 및 성능 일관성이 필요합니까? 우리가 각 커밋을 존중할 수 있는지 확인해야합니까? 평균 트랜잭션이 빠르면 괜찮습니까, 아니면 모든 트랜잭션이 안정적으로 빠른지 확인하고 싶습니까 ( http://www.mysqlperformanceblog.com/2010/06/07/performance-optimization- and-six-sigma / ).
테이블 스키마 ALTER와 같은 운영 문제를 수행해야합니까? InnoDB에서는 가능하지만 포 그라운드에서 임시 테이블을 만들어야하는 경우가 많기 때문에 (모든 연결을 차단) 놀라 울 정도로 느립니다.
그래서 저는 두 가지 제한적인 문제를 다음과 같이 말할 것입니다.
백만 행을 의미하는 경우 인덱싱이 수행되는 방법과 하드웨어 구성에 따라 다릅니다. 백만 개의 행은 엔터프라이즈 데이터베이스 또는 괜찮은 장비의 개발 데이터베이스에 큰 양이 아닙니다.
백만 개의 열을 의미하는 경우 (MySQL에서도 가능하지 않음) 예, 이것은 약간 큰 것으로 보이며 아마도 문제를 일으킬 것입니다.
레지스터? 기록을 의미합니까?
요즘 데이터베이스에서 백만 개의 레코드는 큰 문제가 아닙니다. 문제가 발생하는 경우 데이터베이스 시스템 자체가 아니라 실행중인 하드웨어 일 가능성이 높습니다. 하드웨어가 부족해지기 전에 DB에 문제가 발생하지 않을 것입니다.
이제 분명히 일부 쿼리는 다른 쿼리보다 느리지 만 매우 유사한 쿼리 두 개가 매우 다른 시간에 실행되는 경우 데이터베이스의 실행 계획이 무엇인지 파악하고이를 최적화해야합니다. 즉, 올바른 인덱스, 적절한 정규화 등을 사용해야합니다.
덧붙여서 테이블에 "마지막"레코드와 같은 것은 없으며 논리적 관점에서 볼 때 고유 한 순서가 없습니다.
SELECT LAST_INSERT_ID()해당 쿼리 대신 필요할 수 있습니다.
"등록"으로 "레코드"를 의미한다고 가정하면, 너무 많지는 않습니다. MySQL은 정말 잘 확장되고 하드 디스크에 필요한만큼의 레코드를 보유 할 수 있습니다.
분명히 검색 쿼리가 느려질 것입니다. 필드가 적절하게 인덱싱되었는지 확인하는 것 외에는 그 문제를 해결할 방법이 없습니다.