현재 InnoDB 스토리지 엔진을 사용하고 있으며 약 1k/s가 증가하고 있습니다. 레코드가 데이터베이스에 삽입되면 보고서에서 쿼리를 가져오고 그 레코드는 문제가있는 곳입니다. 우리는 올바른 인덱스를 추가하고 테이블을 압축했지만 많은 도움이됩니다.어떻게 50GB 테이블을 개선 할 수 있습니까?
대부분 처음 30 일 동안 만 기록을 읽으면 나머지는 많이 액세스하지 않습니다. 1 살 이상인 기록은 전혀 묻히지 않습니다. 또한 사용자는 실제로 최신 데이터/레코드에만 액세스합니다.
MySQL의 파티셔닝 기능이 우리에게 이상적입니까? 애플리케이션을 통해 자체적으로 파티셔닝을 구현해야합니까?
MySQL 쿼리 캐시는 SELECT 쿼리의 성능을 상당히 향상시킬 수 있습니다. 아직 사용하고 있지 않다면 확실히 이점을 얻을 수 있으며 파티셔닝보다 쉽게 구현할 수 있습니다.
쿼리 캐시는 SELECT 쿼리의 결과를 메모리에 저장하고 테이블이 변경되기 전에 동일한 SELECT 쿼리가 서버로 다시 보내지면이를 사용하여 즉석 응답을 제공합니다. 여기
는 SELECT 쿼리를 캐쉬 서버의 2GB 메모리를 할당하는 데 필요한의 my.ini 구성 항목의 예입니다#Query Cache
query_cache_size = 209715200
query_cache_limit = 10485740
죄송 합니다만 innoDB에는 해당되지 않습니다. 또한 innodb 버퍼 풀을 알고 있지만 문제는 실제 테이블 크기에 있습니다. – user962449
MySQL에서 innoDb 테이블을 사용하고 쿼리 캐시가 훌륭하게 작동합니다. 아마 나는 오해하고있다. 미안해, 내가 도울 수 없어! – Dan
예, 시나리오, 당신은 생성 된 날짜를 기준으로 테이블을 분할한다 .. –