2023.02.14 문제 목록 (ch8/214~253p)

[zookong]

📌 문제목록

번호	출제자	문제
1.	ramirami	SELECT 쿼리를 이용했을 때, 조회할 필드를 직접 명시하는 것이 조회 성능 향상에 영향을 줄 수 있을까요?
2.	ramirami	복합 인덱스는 내부적으로 어떤 기준으로 정렬되나요?
3.	ZooKong	B-Tree의 구조를 설명해주세요.
4.	ZooKong	인덱스(B-Tree) 검색 성능을 올리기 위해 설계시에 고려해야할 부분을 설명해주세요.
5.	sedin2	B-Tree는 상대적으로 쓰기 작업에 비용이 많이 드는것으로 알려져있는데 왜 그럴까요?

[zookong]

1. SELECT 쿼리를 이용했을 때, 조회할 필드를 직접 명시하는 것이 조회 성능 향상에 영향을 줄 수 있을까요?

   MySQL 내부에서 옵티마이저에 의해 실행계획이 달라질 수 있습니다. 실행 계획에 따라 쿼리의 실행 속도가 크게 영향을 받습니다. 해당 실행 계획은 EXPLAIN 명령어를 통해 상세 계획을 볼 수 있습니다. 필요한 항목만 기술하는 경우 최적의 실행계획을 세울 확률이 높아지기 때문에 "*"와 같이 전체 칼럼을 항상 조회하는 쿼리는 지양해야 합니다. 추가적으로 인덱스에 포함된 칼럼 이외의 나머지 칼럼으로 인해 인덱스 스킵 스캔을 활용하지 못하고 풀 테이블 스캔으로 실행 계획이 수립될 수 있습니다.

2. 복합 인덱스는 내부적으로 어떤 기준으로 정렬되나요?

   v5.7 버전까지는 첫 칼럼의 인덱스 정렬을 적용하였습니다. v8.0부터는 칼럼의 순서대로 정렬 기준이 적용됩니다. 인덱스를 칼럼1, 칼럼2 순서로 적용하였다면 칼럼1을 요청한 조건으로 정렬하고 동일한 칼럼1 내에서 칼럼2의 정렬을 적용합니다

3. B-Tree의 구조를 설명해주세요.

   루트 노드, 브렌츠 노드, 리프 노드 : 최상위 노드 : 루트, 리프 노드가 아닌 중간의 노드 : 가장 하위 노드, 실제 데이터 레코드를 찾기 위한 주솟값이 존재

---

4. 인덱스(B-Tree) 검색 성능을 올리기 위해 설계시에 고려해야할 부분을 설명해주세요.

   ---

5. B-Tree는 상대적으로 쓰기 작업에 비용이 많이 드는것으로 알려져있는데 왜 그럴까요?

인덱스 추가 추가할 위치를 검색하고 위치가 결정되면 리프 노드에 저장, 리프 노드가 꽉 차는 경우에는 리프 노드를 분리하고 이는 상위 브렌치까지 영향을 준다.

인덱스 삭제 리프 노드를 찾아서 삭제 마킹, 마킹 작업 또한 디스크 쓰기가 필요하므로 디스크 IO 발생, 삭제는 내부적으로 인덱스키 삭제

인덱스 변경 인덱스 삭제와 인덱스 추가가 둘다 일어나기 때문에 많은 비용이 발생, 내부적으로는 체인지 버퍼를 활용

[sedin2]

1. SELECT 쿼리를 이용했을 때, 조회할 필드를 직접 명시하는 것이 조회 성능 향상에 영향을 줄 수 있을까요?

   조회할 필드가 인덱스에 존재하는 컬럼으로 처리가 가능하면(커버링 인덱스) 랜덤 I/O가 거의 발생하지 않으므로 성능 향상을 기대 해 볼 수있을것 같다.

---

2. 복합 인덱스는 내부적으로 어떤 기준으로 정렬되나요?

   복합 인덱스는 만약 N개의 컬럼으로 이루어진 복합인덱스라면 N번째 키 값은 N-1번째 키 값에 대해서 다시 정렬된다. 작업 범위 결정 조건의 컬럼이 많으면 복합 인덱스를 사용하는 쿼리의 성능 향상을 기대 할 수 있다.

---

3. B-Tree의 구조를 설명해주세요.

   루트노드, 브랜치 노드, 리프노드로 이루어져 있다. 루트 노드와 브랜치 노드는 자식 노드의 주소를 가지고 있고, 리프 노드는 실제 데이터가 저장된 주소값을 가지고 있다. B-Tree는 나온지 오래되서 여러 변형된 알고리즘이 있는데 대표적으로 B+Tree, B*Tree 등이 있다. B*Tree는 B-Tree의 키 값을 추가 할 때 리프 노드가 가득차면 리프 노드가 분리되어 저장되는 부분을 보완한 구조이다. 분리 대신 이웃한 형제 노드로 재 배치 하고 더 이상 재 배치 할 수 없는 시점에 분리 함. B+Tree는 리프노드에서 리프노드끼리 링크드 리스트로 서로 연결된 구조이다. 이는 리프 노드에서 인덱스 레인지 스캔을 할 때 B-Tree구조 보다 유리하게 스캔 할 수 있다.

---

4. 인덱스(B-Tree) 검색 성능을 올리기 위해 설계시에 고려해야할 부분을 설명해주세요.

   검색에 비해 데이터 추가, 수정, 삭제가 너무 빈번하게 일어나는 테이블인지 ? 저장된 데이터를 조회할 때 조건절에 EQUAL 비교나 문자열 패턴 검색 시 앞 부분 일치로 검색 할 수 있게끔 인덱스를 구성한다. 복합 인덱스 구성시 컬럼의 순서가 중요하므로 이를 잘 고려해서 설계한다.

---

5. B-Tree는 상대적으로 쓰기 작업에 비용이 많이 드는것으로 알려져있는데 왜 그럴까요?

   B-Tree에 새로운 키 값을 저장 할 때, 먼저 저장될 위치를 검색한다. 저장될 위치가 결정되면 리프노드에 키 값과 대상 레코드의 실제 주소값을 저장한다. 이때 리프노드가 꽉 차있다면 리프 노드를 분리해서 저장 해야하는데 이는 부모 노드까지 영향을 준다. 분리되면서 리프노드의 주소값이 변경되면 부모가 가지고있는 자식 노드의 주소를 갱신 해줘야 한다. 이러한 작업탓에 비용이 많이 드는것으로 알려져있다.

[gzgzg2]

1. SELECT 쿼리를 이용했을 때, 조회할 필드를 직접 명시하는 것이 조회 성능 향상에 영향을 줄 수 있을까요?

• 데이터가 버퍼풀에 적재되어있지 않다고 가정했을 때, 커버링 인덱스로 처리할 수 있는 경우 디스크 조회를 하지 않아도 되기 때문에 성능이 향상될 수 있다.

  2. 복합 인덱스는 내부적으로 어떤 기준으로 정렬되나요?

• column_1, column_2, column_3이 복합 인덱스로 등록되었다고 가정했을 때, 뒷 컬럼은 앞 컬럼 값을 기준으로 정렬된다.

  3. B-Tree의 구조를 설명해주세요.

• 루트 노드, 브랜치 노드, 리프 노드로 구성되어 있다. 리프 노드에는 데이터 주소가 저장되어 있거나, 해당 로우의 PK가 저장되어 있다.

  4. 인덱스(B-Tree) 검색 성능을 올리기 위해 설계시에 고려해야할 부분을 설명해주세요.

• B-Tree가 불필요하게 깊어지는 것을 방지하기 위해 적절한 인덱스 키 사이즈를 고려해야 함
• 인덱스의 기수성 고려 (인덱스로 지정된 칼럼의 유니크한 값의 수로 결정 됨)
• 적절한 인덱스의 수

  5. B-Tree는 상대적으로 쓰기 작업에 비용이 많이 드는것으로 알려져있는데 왜 그럴까요?

• 인덱스 파일은 키를 기준으로 정렬되어 있기 때문에 인덱스가 추가될 적절한 위치를 탐색하는 것과 공간을 확보하는 작업으로 오버헤드가 발생할 수 있다.
• 인덱스 파일에 공간이 없을 경우 스플릿을 수행하는데, 이는 상위 노드까지 처리 범위가 넓어질 수 있다.
• 수정 시 키 값에 따라 저장될 위치가 달라지기 때문에 단순히 인덱스 파일의 키 값만 수정하는 작업으로는 처리할 수 없다.