공부 목록
여기는 규칙은 알거나 정했는데, 왜 그런지를 남에게 설명하지 못하는 것을 모아두는 곳이다. 말을 바꾸면 — 그 규칙을 근거로 판단은 했는데, 근거 자체는 설명할 수 없는 상태다.
아직 정하지 않은 것과 헷갈리기 쉬운데, 비어 있는 자리가 다르다.
- 열린 항목 — 아직 고르지 않았다. 안을 비교해서 정하면 닫힌다
- 공부 목록 — 골랐는데 왜 그런지 설명하지 못한다. 파고들어 이해해야 닫힌다
대응이 다르므로 섞어두면 안 된다. 새 표준을 쓰기 직전에 필요한 건 “정할 것”이고, 공부는 그 시점에 하는 일이 아니다. 장부를 열린/닫힌으로 가른 이유와 같다.
적을 때는 어디서 나왔는지를 반드시 남긴다. 그게 없으면 6개월 뒤에 “이걸 왜 공부해야 하지”가 복원되지 않고, 그러면 목록이 그냥 흥미 목록이 된다.
닫을 때는 지우지 않는다. 파고든 결과가 글이 되고, 그 글의 링크를 항목에 단다. 무엇을 몰라서 그 글을 썼는지가 글의 도입부가 되기 때문이다.
인덱스가 어떤 구조라서 정렬 순서가 인덱스를 가르는가
아래 셋은 페이징 방식 표준을 정하다가 같은 자리에서 나왔다. 다중 정렬을 허용할지 판단하는 근거가 전부 인덱스의 물리 구조였는데, 그 구조를 근거로 쓰면서도 구조 자체는 설명하지 못했다.
| # | 질문 | 어디서 나왔나 | 어디까지 알고, 무엇을 설명하지 못하는가 |
|---|---|---|---|
| 1 | 복합 인덱스는 왜 선행 컬럼이 빠지면 못 타는가 | 다중 정렬을 지금 허용할지 판단하는 자리. (a, b)와 (b, a)가 서로 다른 인덱스라는 사실이 "허용 조합마다 인덱스 하나"라는 결론의 근거였다 |
"인덱스는 선행 컬럼부터 정렬된 자료다"까지만 말할 수 있다. B-tree가 그 정렬을 어떻게 저장하길래 두 번째 컬럼만으로는 못 찾는지를 설명하지 못한다. 그리고 옵티마이저가 인덱스 스캔 대신 filesort를 고르는 판단이 어느 단계에서 이뤄지는지도 모른다 — "못 탄다"고 말했지만 실제로는 "안 타기로 옵티마이저가 정한다"에 가까울 수 있다 |
| 2 | ASC와 DESC가 섞이면 왜 인덱스를 못 타는가 | 같은 자리. 이 사실 하나가 정렬 키 3개의 조합 수를 15에서 78로 늘렸고, 그래서 "다중 정렬 허용"이 실제로는 "허용 조합 열거"일 수밖에 없다는 결론이 나왔다 |
방향이 전부 같으면 인덱스를 뒤에서부터 읽어 해결된다는 것까지는 말했는데, 섞였을 때 왜 그 수단이 안 통하는지를 설명하지 못한다. 내림차순 인덱스가 저장 구조에서 무엇을 바꾸는지도 모른다. MariaDB가 어느 버전부터 지원하는지는 확인하지 못한 채 대화를 끝냈다 |
| 3 | WHERE의 등치 조건은 왜 선행 컬럼을 대신 채워주는가 |
같은 자리. 2번과 반대 방향의 사실이라 같이 이해하지 않으면 "순서가 전부다"로 잘못 굳는다고 판단해 꺼냈다 |
WHERE status = 'PAID' ORDER BY created_at이 (status, created_at)을 탄다는 것은 아는데, 등치가 아닌 범위 조건이면 왜 안 되는지를 설명하지 못한다. 열린 항목 13번의 "조건 5개의 32가지 중 인덱스 하나가 덮는 건 5가지뿐"도 이 원리에서 나오는 숫자인데, 그 계산을 스스로 다시 해낼 수 없다 |
페이징이 깊어질 때 정확히 어디서 비용이 발생하는가
| # | 질문 | 어디서 나왔나 | 어디까지 알고, 무엇을 설명하지 못하는가 |
|---|---|---|---|
| 4 | 깊은 OFFSET은 어느 단계에서 행을 읽고 버리는가 |
페이징 방식 표준에서 안 A(무한 스크롤도 offset으로)를 버린 이유가 이것이었다. "깊이 들어가는 게 정상 사용인데 OFFSET이 계속 커진다"가 근거였다 |
버린다는 사실만 알고 어디서 버리는지를 설명하지 못한다 — 스토리지 엔진이 행을 전부 만들어 올린 뒤 서버 레이어가 세어서 버리는지, 인덱스만 훑고 넘기는지. 커버링 인덱스로 완화된다는 말은 들었지만 왜 완화되는지 설명하지 못한다. 이걸 모르면 "느리다"의 정도를 못 재고, 그건 열린 항목 15번(슬로우 쿼리 기준)의 입력이다 |