2017-09-14 26 views
0

단일 테이블을 포함하는 데이터베이스가 있습니다. 테이블의 크기는 3.5Gs입니다.MYSQL InnoDB : 버퍼 풀 크기를 늘린 후에 성능이 MEMORY 엔진에 근접하지 않은 이유는 무엇입니까?

세 가지 다른 구성을 사용하여 테이블에서 읽기 전용 쿼리를 수행합니다.
1- Innodb 기본 버퍼 풀 크기.
2 개의 Innodb 버퍼 풀 크기 = 6G.
3- 메모리 엔진.

세 가지 구성의 실행 시간 :
1- 기본 버퍼 풀 크기 ... 15,53 초.
2- 버퍼 풀 크기 = 6G ...... 13,60 초.
3 메모리 엔진 .... 3,96 초.
....

메모리 엔진과 거대한 공간이 충분한 버퍼 풀에 사이에 큰 차이가있는 이유는 버퍼 풀의 크기를 증가하는 것은 "메모리"데이터베이스 .... 같은 데이터베이스를하여야하는 경우 테이블을 포함합니다.

메모 :
1- 전담 기계에서 실험하고 있습니다.

2 - 6Gs가있는 버퍼 풀을 사용할 때 ... 스와핑이 발생하지 않으므로 테이블이 스왑없이 메모리 내에 편안하게 들어갑니다.

3 "핫 데이터"가 주 메모리에로드되었는지 확인하기 위해 쿼리를 두 번 이상 수행했습니다 ... 메모리 소비를보고있었습니다 ... 수행 후 500MB에서 4G로 이동했습니다. 쿼리 .... 버퍼 풀 6G 설정.

3- 테이블이 명령을 사용하여 만든 :

CREATE TABLE lineitem ( 
L_ORDERKEY INTEGER NOT NULL, 
L_PARTKEY  INTEGER NOT NULL, 
L_SUPPKEY  INTEGER NOT NULL, 
L_LINENUMBER INTEGER NOT NULL, 
L_QUANTITY DECIMAL(15,2) NOT NULL, 
L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL, 
L_DISCOUNT DECIMAL(15,2) NOT NULL, 
L_TAX   DECIMAL(15,2) NOT NULL, 
L_RETURNFLAG CHAR(1) NOT NULL, 
L_LINESTATUS CHAR(1) NOT NULL, 
L_SHIPDATE DATE NOT NULL, 
L_COMMITDATE DATE NOT NULL, 
L_RECEIPTDATE DATE NOT NULL, 
L_SHIPINSTRUCT CHAR(25) NOT NULL, 
L_SHIPMODE  CHAR(10) NOT NULL, 
L_COMMENT VARCHAR(44) NOT NULL); 


5 내가 실행 해요 쿼리, (즉),

select 
sum(l_extendedprice * l_discount) as revenue 
from 
    tpch2.lineitem 
where 
    l_shipdate >= date '1994-01-01' 
    and l_shipdate < date '1994-01-01' + interval '1' year 
    and l_discount between 0.06 - 0.01 and 0.06 + 0.01 
    and l_quantity < 24; 
+0

** InnoDB **로 작업 할 때'ALTER TABLE lineitem ADD INDEX shipdate_discount_quantity (l_shipdate, l_discount, l_quantity);와 같은 색인을 추가하려고 시도 했습니까? 그렇지 않으면 시험 시간 결과를 다시보고 할 수 있습니까? – codtex

+0

@codtex, 의견을 보내 주셔서 감사합니다. 나는 색인을 만들지 않았다.
기본 버퍼 풀 크기 시간 : 15,65 초
버퍼 풀 크기 = 6 세대 : 인덱스 만들기와
13,32 초 –

+0

그래서 내가 함께 또는 인덱스없이 어떤 차이를 볼 수 없습니다를 ... 그것은 아주 이상합니다. 어쩌면 당신은 select 문에서'EXPLAIN'을 사용하려고 시도 할 수 있습니다. 어쨌든 쿼리의 속도를 높이고 실제 질문에 응답하지 않는 것 같습니다. "_ 왜 메모리 엔진과 버퍼 풀 사이에 큰 차이가 있습니까? 테이블을 담을 수있는 충분한 공간이 있습니까? " 내가 줄 수있는 다른 제안은 [PARTITIONING] (https://dev.mysql.com/doc/refman/5.7/en/partitioning.html)을 사용하고 [this] (https://dev.mysql.com)을 읽는 것입니다. /doc/refman/5.7/en/partitioning-overview.html) 또한 – codtex

답변

0
  • 가있는 tpch의 쿼리 (6) 거기에 인덱스가 없습니까? 또는 테이블에 INDEX(l_shipdate)INDEX(l_discount)INDEX(l_quantity)이있어 최적화 프로그램이 선택할 수 있습니까?
  • InnoDB 및 메모리 버전 모두에 EXPLAIN SELECT ...을 제공하십시오.
  • 하나의 연결로 해당 쿼리를 반복적으로 실행하고 있습니까? 또는 많은? 아니면 자원을 최대한 활용하고있는 많은 사람들이 있습니까? 옵티마이 저는 정말 하나 이상의 "범위"를 처리 할 수 ​​있으며, WHERE의 각 부분은 "범위"때문에

INDEX(l_shipdate, l_discount, l_quantity)은 도움이되지 않습니다.

속도 비율이 3 : 1 이상인 데 나는 놀랍습니다. 메모리는 모든 행을 테스트하여 테이블 스캔을 수행해야합니다. InnoDB, 내가 제안하는 3 가지 인덱스를 사용하면 일 가능성이 높습니다. 인덱스를 사용합니다. 이것은 데이터 배포에 따라 다릅니다. 말하자면, 해당 날짜의 행 수는 얼마나됩니까? 그 할인 범위 안에? 그 수량 범위에서?

각 타이밍을 두 번 실행 했습니까? 처음에는 I/O가 있지만 캐시를 워밍업합니다. 두 번째 (아마도) I/O가 없을 것입니다.