[일반] mysql의 세컨더리 인덱스는 레코드 포인터 주소가 아니라 PK값을

[딘퐁(gunwoo7193)]

mysql의 세컨더리 인덱스는 레코드 주소가 아니라 PK 값을 저장하는 것의

장점을 설명해보세요.

단점으로는 세컨더리 인덱스 스캔 후이 PK인덱스로 스캔을 한 번 더 해야함

리프노드에 프라머리키 값을 저장 vs 레코드 주소를 저장

일단 내가 생각한 답은 1개임

[딘퐁(gunwoo7193)]

이건 인기가 없군 - dc App

[익명(211.235)]

님은 어쩌다 db와 사랑에빠지게됨?

[딘퐁(gunwoo7193)]

백엔드가 만질만하기 쉬운게 DB이고 DB가 제일 부하 많이 걸리니깐 - dc App

[익명(211.235)]

학교나 말하는거 보면 참 똘똘하신거 같은데 그냥 개발자를 안해도 됐을거같아서 그럼

[딘퐁(gunwoo7193)]

개발자로 안갔는데..? - dc App

[딘퐁(gunwoo7193)]

대학원가긴 싫음 CS를 학문적으로 공부하는건 어려움.. - dc App

[익명(211.235)]

음 그냥 개발직군을 개발자라고 했네 ㅈㅅ 그냥 아예 다른분야 해도 잘됐을거 같음

[딘퐁(gunwoo7193)]

칭찬 고맙다 한가지 흥미있는거만 파는 성격임 - dc App

[백갤러 1(106.101)]

레코드 주소가 아닌 pk를 사용한다면 pk 변경 시 모든 세컨더리 인덱스 수정 안 해도 될 듯.

[백갤러 1(106.101)]

커버링 인덱스가 장점인가..?

[딘퐁(gunwoo7193)]

PK값 말하는거면 PK 값을 바꿀 일이 거의없지 - dc App

[딘퐁(gunwoo7193)]

커버링인덱스도 장점이긴함 - dc App

[백갤러 2(211.234)]

커버링 인덱스

[딘퐁(gunwoo7193)]

그거도 맞긴해 - dc App

[백갤러 2(211.234)]

그리고 생각한건 I/O 쪽에서 rowid보다 pk보다 더 순차적인? 접근이 가능해서 성능 향상에 이점이 있다였는데 불명확해서 찾아보는 중

[백갤러 2(211.234)]

다른 건 또 찾아보니 rowid는 실제 주소라서 레코드 위치가 변경되면 세컨더리 인덱스도 모두 업데이트 / pk는 값 변경 없으니 문제 X / 밑에 나온거랑 같은겅가?

[딘퐁(gunwoo7193)]

ㅇㅇ같은말임 - dc App

[딘퐁(gunwoo7193)]

근데 rowid 값이 어떻게 만들어지는지는 잘모르겟다 오라클쪽은 안봐봐서 - dc App

[백갤러 2(211.234)]

디스크를 읽을 때 버퍼 풀로 한번에 모아서 순차 I/O를 유도할 수 있어서 성능상 유리할수 있다고는 하는거 같은데 다른 장점에 비하면 애매하네

[익명(1.228)]

세컨드 인덱스 쓸 때 커버링 인덱스가 되기 쉽고, pk값이 바뀌었을때 레코드의 물리적 위치를 바꿀 필요가 없어짐.

[딘퐁(gunwoo7193)]

모든 인덱스 레코드 포인터 물리적 위치 변경 << 내 의도 정답 - dc App

[딘퐁(gunwoo7193)]

[백갤러 3(175.114)]

실제 데이터 위치는 계속 변할수있우니깐 논리적 주소를 사용하는거지 - dc App

[익명(115.40)]

주소를 저장한다면, 데이터의 위치가 바뀔 때 레고드 주소도 수정을 해야함 하지만 pk를 저장한다면 pk는 변하지 않으니 수정할 필요가 없음 맞나..? - dc App

[백갤러 4(211.36)]

? 이게 커버링인덱스랑 뭔 상관임? 데이터의 물리적 위치 변동에 대한 이점은 인정인데 세컨더리 인덱스 쓸때 커버링 인덱스가 되기 쉽다 << 이게 뭔 개 좆같은소리임..?

[백갤러 5(211.234)]

ㅋㅋ책에도 이점이 된다고 적혀있긴함.. - dc App

[백갤러 5(211.234)]

보통 인덱스 값이랑 pk만 조회를 하는 경우도 많으니 - dc App

[백갤러 6(220.76)]

그냥 노드 자체에 pk가 있으니 딱 인덱스키, pk select 할때 이득인거 아님?

[딘퐁(gunwoo7193)]

ㅇㅇ맞음 - dc App

[백갤러 7(1.249)]

무슨책인가요 행님? - dc App