H2 데이터베이스 성능 낯선 --- 또는 효율적으로`COUNT (*)`

Question

은 설치가 간단 할 수 없습니다하는 방법 두 가지가 있습니다

• H2 버전 1.3.176
• 한 테이블에 10 개 컬럼있는 조금 깁니다. 보통 길이 값은 300 및 3500입니다.
• 간단한 쿼리 : select count(*) from requestrepository where request_type = 'ADD'
• 색인은 쿼리 된 열에 있습니다.
• 쿼리 된 열은 varchar (20)입니다 (즉, 더 긴 것 중 하나가 아님)
• 쿼리 된 열은 두 가지 값만 포함합니다. 하나는 200k 번 나타나고 다른 하나는 1200 만 번 나타납니다. (0), analyze를 실행 (1)에 의해 하나 개의 행을 삭제 :
• DB는 자바 (8) 현재 SSD를, 현재 서버 하드웨어를 도망

내가 뭘 (조금 있지만 결과에 변화를 다양) (2) 방금 삭제 한 키에 대해 하나의 행을 삽입합니다. (3) 위에서 인용 한 쿼리를 실행하고 10으로 계산 한 다음 반복합니다. 내가 볼 무엇

: 위에서 언급 쿼리는 세 사이의 5 초마다와 explain analyze 소요는 말한다 :

SELECT 
    COUNT(*) 
FROM PUBLIC.REQUESTREPOSITORY 
    /* PUBLIC.IX_REQUESTS: REQUEST_TYPE = 'ADD' */ 
    /* scanCount: 12098748 */ 
WHERE REQUEST_TYPE = 'ADD' 
/* 
REQUESTREPOSITORY.IX_REQUESTS read: 126700 
*/ 

내가, VM/윈도우/다른 컴퓨터, 하드웨어/리눅스/SSD에 같은 DB를 시도 netapp이지만 경향은 항상 동일합니다. count(*)은 너무 오래 걸립니다 (?).

그리고 이것이 확실하지 않습니다. 이것이 오래 걸릴 것으로 예상됩니까? 적어도 두 번째 라운드에서는 캐시가 채워졌고 훨씬 빨라야한다고 생각했지만 explain analyze은 항상 126700 개의 읽기를 나열합니다.

개선 될 수있는 H2 매개 변수 또는 설정에 대한 힌트를 얻으실 수 있습니다.

EDIT (확실한 답이 아니라면 대답) 한편 우리는 mvstore, 1.4.x, 병렬 스레드, 다른 디스크, Linux, Windows를 사용하는 컴퓨터 등 다양한 범위의 작업을 시도했습니다. 상황은 항상 동일합니다. 처리량, 추가, 삭제, 열에 대한 색인 및 하나의 상태가 지나치게 과장된 것과 같이 세 가지 상태 값이있는 varchar 열을 가져옵니다. count(*) where colname='ADD'과 같은 것은 1 초에서 몇 초가 걸립니다. 표.

문제를 만들어이를 방지하기 위해, 우리는 마침내 group by 세 count(*), 각 상태에 대해 하나, 하나가 아닌했던 우리 자신의 코드를 수정하고 대신 수요의 5 초마다 실행되었습니다. 물론 우리가 가진 최고의 디자인은 아닙니다.

내가 가지고있는 유일한 변명은 count(*)이 그런 설정에서 오래 걸린다는 것이 여전히 놀랍다는 것입니다. 내 직감은 카운트가 업데이트 이후에 실제로 계산하여 인덱스에서 계산되어야한다는 것인데, 그 카운트가 어딘가에 데이터 구조에서 읽혀질 수 있다고 예상했기 때문입니다. (비판은 아니지만 나 자신을 위해 DB를 구현할 수는 없다.)

Answer 1

H2에 대해서는 잘 모르지만 COUNT(*) 대신 COUNT(request_type)을 시도 했습니까?

SQL 표준의 COUNT(*)은 NULL 값으로 구성된 행을 필터링하기 위해 전체 테이블 검색이 필요하기 때문에 계산하는 데 시간이 많이 걸리는 경향이 있습니다.

COUNT()을 단일 색인 열에 사용하면 처리 속도가 빨라질 수 있습니다. 인덱스가 열의 값이 NULL인지 여부를 결정하기에 충분하므로이 방법으로 테이블 행을 읽을 필요가 없습니다.