퀴즈: 성긴 기본 키와 키 순서

6道题. 完成作答后会显示正确答案和解析。

1. ORDER BY (site, user_id) 표에서 `WHERE user_id = 4242` 의 EXPLAIN 에 `Search Algorithm: generic exclusion search` 가 나왔다. 왜 이진 탐색이 아닌가?

   1. user_id 가 UInt32 라서 이진 탐색을 쓸 수 없다
   2. 파트가 여러 개일 때만 이진 탐색을 쓴다
   3. 쿼리 조건 캐시가 켜져 있으면 검색 방식이 바뀐다
   4. user_id 는 사이트마다 다시 정렬돼 전체로는 정렬돼 있지 않다

2. ORDER BY (user_id, site) 표(사용자 5만 명, 그래뉼 245개)에서 `WHERE site = 'docs.example'` 이 245/245 그래뉼을 읽었다. 가장 정확한 설명은?

   1. site 가 LowCardinality 라서 인덱스에 들어가지 않는다
   2. 앞 열 user_id 가 그래뉼마다 바뀌어 뒤 열로 제외할 구간이 없다
   3. site 의 값이 다섯 가지뿐이라 거를 필요가 없다고 판단했다
   4. OPTIMIZE FINAL 을 하지 않아 인덱스가 만들어지지 않았다

3. 같은 자료·같은 정렬 키에서 index_granularity 를 8192 에서 1024 로 줄였더니 user_id 조회의 rows_read 가 73,728 에서 9,216 으로 줄었다. 그 대가로 늘어난 것은?

   1. 마크 수와 기본 키 파일 크기 — 인덱스가 쓰는 메모리
   2. 열 데이터 파일(.bin)의 압축 후 크기가 8배로
   3. INSERT 한 번이 만드는 파트 수
   4. 정렬 키에 들어갈 수 있는 열의 개수 제한

4. `CREATE TABLE t (...) ENGINE = MergeTree PRIMARY KEY (user_id) ORDER BY (site, user_id)` 를 실행하면?

   1. user_id 만 인덱스에 적히고 정렬은 (site, user_id) 로 된다
   2. PRIMARY KEY 가 우선해 정렬도 user_id 로 바뀐다
   3. 기본 키가 정렬 키의 앞부분이 아니라서 표가 만들어지지 않는다
   4. 경고만 남기고 PRIMARY KEY 를 무시한다

5. `WHERE site = 'api.example' AND ts` 하루 범위 쿼리가 ORDER BY (site, user_id) 표에서 40만 행을 읽는다. 읽는 행을 가장 크게 줄이는 새 정렬 키는?

   1. (user_id, site)
   2. (site, user_id, ts)
   3. (dur_ms, site)
   4. (site, ts)

6. 같은 SELECT 를 두 번 돌렸더니 첫 번째는 rows_read 73,728, 두 번째는 40,960 이었다. 26.8 에서 가장 먼저 의심할 것은?

   1. 그 사이 백그라운드 병합이 파트를 줄였다
   2. 쿼리 조건 캐시가 맞는 행이 없던 그래뉼을 기억해 건너뛰었다
   3. 첫 번째 실행이 결과를 쿼리 캐시에 넣어 두 번째는 캐시에서 읽었다
   4. 기본 키가 첫 실행 때 메모리로 올라와 인덱스가 정밀해졌다