2023.03.07 문제 목록 (ch8/253~281p)

[zookong]

📌 문제목록

번호	출제자	문제
1.	ZooKong	유니크 인덱스가 체인지 버퍼를 사용할 수 없는 이유가 무엇인가요?
2.	ZooKong	프라이머리 키를 설계할 때 어떤 점을 고려하실 건가요?
3.	ramirami	실제 서비스에서 테이블에 관계를 맺을 때 외래키를 사용하시나요? 그렇지 않다면 이유는 무엇인가요?
4.	sedin2	클러스터링 인덱스에 대해 설명 해 주세요.

[zookong]

• 유니크 인덱스가 체인지 버퍼를 사용할 수 없는 이유가 무엇인가요?

  InnoDB 스토리지 엔진에는 인덱스 키의 저장을 버퍼 링하기 위해 체인지 버퍼(Change Buffer)가 사용 유니크 인덱스는 반드시 중복 체크를 해야 하므로 작업 자체를 버퍼링하지 못함 유니크 인덱스는 일반 세컨더리 인덱스보다 변경 작업이 더 느리게 작동

• 프라이머리 키를 설계할 때 어떤 점을 고려하실 건가요?

  클러스터링 인덱스 키 크기

  사이즈가 클 경우 세컨더리 인덱스는 클러스터링 키의 값을 갖고 있기 때문에 같이 커짐

프라이머리 키는 AUTO-INCREMENT보다는 업무적인 칼럼으로 생성(가능한 경우)

프라이머리 키는 클러스터링 키로 사옹 프라이머리 키는 세컨더리 인덱스와 다르게 최초 한번 읽고 다음으로 클러스터링 인덱스를 사용하여 레코드 위치를 찾지 않고 바로 클러스터링 인덱스를 통해 레코드에 접근, 속도적으로 엄청나게 빠름

프라이머리 키는 반드시 명시할 것

InnoDB에서 프라이머리 키를 정의하지 않으면 내부적으로 일련번호 칼럼을 추가 추가한 일련번호 칼럼은 사용자가 활용할 수 없음, 게다가 프라이머리 키로 칼럼을 정의하는 것과 동일한 효과

• 실제 서비스에서 테이블에 관계를 맺을 때 외래키를 사용하시나요? 그렇지 않다면 이유는 무엇인가요?

  개발 편의성 감소 부모와 자식의 장금 경합으로 인해 잠금이 다른 테이블로 확장될 염려가 있음, 쿼리의 동시 처리에 영향

• 클러스터링 인덱스에 대해 설명 해 주세요.

  MySQL에서 클러스터링 인덱스는 InnoDB만 지원 클러스터링의 의미에 맞게 해당 키를 기준으로 비슷한 값들끼리 묶어서 실제 레코드의 저장 위치가 결정 프라이머리 키 범위 검색하는 경우 매우 빠름

[sedin2]

• 유니크 인덱스가 체인지 버퍼를 사용할 수 없는 이유가 무엇인가요?

  인덱스 쓰기 작업 시 유니크 인덱스는 중복된 값이 있는지 없는지 체크하는 과정이 한 단계 더 필요함. 그래서 유니크하지 않은 세컨더리 인덱스의 쓰기보다 느리다. 또 MySQL에서 유니크 인덱스에서 중복된 값을 체크할 때 읽기 잠금을 사용하고, 쓰기를 할 때는 쓰기 잠금을 사용하는데 이 과정에서 데드락이 빈번하게 발생. 중복값 체크 때문에 작업 자체를 버퍼링 할 수 없어서 체인지 버퍼를 사용할 수 없다.

• 프라이머리 키를 설계할 때 어떤 점을 고려하실 건가요?

  칼럼의 크기가 크면 인덱스의 크기가 커지므로 이는 곳 메모리도 더 필요하다는 뜻이다. 하지만 PK는 검색에 상당히 빈번하게 사용되는 것이 일반적이므로, AUTO-INCREMENT보다는 업무적인 칼럼으로 생성하는 것이 좋다.

• 실제 서비스에서 테이블에 관계를 맺을 때 외래키를 사용하시나요? 그렇지 않다면 이유는 무엇인가요?

  외래 키 설계할 때엔 잠금 경합까지 고려해서 설계해야한다. 부모 테이블이 쓰기 잠금이 걸려있으면 자식 테이블이 기다리듯이 잠금 경합이 발생하기 때문이다. 하지만 소프트웨어 특성상 요구사항이 자주 바뀌고 이는 곳 DB에도 많은 수정사항이 생길 수 있고, 데이터 정합성을 유지하기 위해 설계 해놓은 외래키가 이후에는 더 큰 수정을 불러올 수 있으므로 실무에서는 잘 사용하지 않는것 같습니다.

• 클러스터링 인덱스에 대해 설명 해 주세요.

  클러스터링 인덱스는 MySQL에선 InnoDB 스토리지 엔진에서만 지원하며, 테이블의 레코드를 비슷한 것(프라이머리 키 기준)들 끼리 묶어서 저장하는 형태이다. 장점으로는 빠른 검색, 커버링 인덱스 비율이 높음 단점으로는 클러스터링 키 값이 커지면 전체적으로 인덱스의 크기가 커지고, 세컨더리 인덱스로 검색 시 클러스터링 인덱스로 다시 검색 해야하므로 느림

[gzgzg2]

• 유니크 인덱스가 체인지 버퍼를 사용할 수 없는 이유가 무엇인가요?

  유니크 인덱스는 쓰기 작업을 할 때 항상 중복체크를 해야하기 때문에 체인지 버퍼를 이용할 수 없음
  때문에 유니크하지 않은 인덱스를 처리할 때보다 느린 성능을 보임

• 프라이머리 키를 설계할 때 어떤 점을 고려하실 건가요?

  프라이머리 키 값의 크기
  프라이머리 키 값이 커지면 데이터 수 * 프라이머리 키의 크기 의 용량을 차지하기 때문에
  정렬을 활용하여 효과적으로 탐색할 수 있는 값을 프라이머리 키로 설정할 것 같음

• 실제 서비스에서 테이블에 관계를 맺을 때 외래키를 사용하시나요? 그렇지 않다면 이유는 무엇인가요?

  부모 자식간의 잠금 경합으로 인해 데드락이 발생할 위험이 높아짐

• 클러스터링 인덱스에 대해 설명 해 주세요.

  클러스터링 인덱스 값으로 데이터 파일이 정렬 됨
  클러스터링 인덱스를 이용하면 빠른 검색이 가능하고 커버링 인덱스를 사용할 확률이 높아짐
  세컨더리 인덱스의 리프 노드엔 클러스터링 인덱스가 저장되어 있음. 이는 로우를 검색할 때 한 단계가 더 추가되지만, 프라이머리 키의 값이 변경될 때의 오버헤드는 더 적은 편