[정보] innodb에서 pk 는 항상 커버링 인덱스에 포함된다.

[익명(59.6)]

클러스링 인덱스 구조로 인해 세컨더리 인덱스의 리프노드가 pk 값을 갖기 때문이다

[30세전에특급DBA(118.235)]

커버링 인덱스는 비즈니스 로직을 토대로 쿼리 구문을 작성했을때 조건,조인절의 모든 속성이 인덱스 컬럼에 핏하게 맞아 떨어지는것을 말한다 - dc App

[30세전에특급DBA(118.235)]

그리고 세컨더리(논클러스터드) 인덱스는 pk값을 가지는게아니라 클러스터드 인덱스의 데이터 페이지를 가르키는 포인터 값을 가지는거임 - dc App

[30세전에특급DBA(118.235)]

추가적으로 이러한 룩업 연산을 막기 위해서 mssql에서 세컨더리(논클러스터드) 인덱스include라는 기능을 지원함 mysql도 있으려나 - dc App

[김대기(waitkim)]

mysql은 포인터가 아니라 실제 pk값을 가짐

[30세전에특급DBA(118.235)]

내가 틀렸군 와캬파 이렇게 mssql과 mysql의 다른점을 하나 알아간다 그러면 mysql에선 include라는 기능이 지원할 필요도 없겠구나 - dc App

[30세전에특급DBA(118.235)]

아 그건또 아니군 include는 비단 pk값외에도 주로 select되는 속성들을 지정해 줄 수 있기때문에.. mysql에도 비슷한 기능이있나 - dc App

[김대기(waitkim)]

잘 모르지만 없을 것 같군

[김대기(waitkim)]

mssql과 mysql은 왜 다를까? 리프노드가 pk 실제값인거랑 주소값인거랑 뭐가 이득이고 뭐가 손해길래? 바빠서 무책임한 궁금만 남기고 튐

[30세전에특급DBA(118.235)]

포인터로하면 복합인덱스일때 실제값을 가지는것보다 용량을 절약할 수 있을것 같다는것 외에는 모르겠다 그래서 include기능으로 선택지를 준것일지도 - dc App

[30세전에특급DBA(118.235)]

그리고 성능상에서도 pk값이 바뀌면 세컨더리 인덱스의 pk값도 바뀌어야되서 그런거아님? - dc App

[30세전에특급DBA(118.235)]

근데 보통 서비스가 read비율이 높아서 그렇게 했을때 이점이 mssql보다 많은것 같은데 - dc App

[30세전에특급DBA(118.235)]

아 mssql도 테이블이 클러스터드 인덱스가 있으면 포인터가아니라 실제 값을 가진다네 힙테이블만 포인터를 가지는듯 내말이 반만 맞았네 - dc App

[김대기(waitkim)]

그렇다면 리프노드에 pk를 지니는게 더 이점이 있다는거군

[30세전에특급DBA(118.235)]

185.135 케이스간 설명을 반대로 한거같은데 - dc App

[30세전에특급DBA(118.235)]

위에 내가 설명한거랑 똑같은이유 인것 같은데 그 책에 흥미가 생기네 공유 ㄱㅅ - dc App

[30세전에특급DBA(118.235)]

목차봤는데 재밌네 벤더에 국한되지 않고 기존에 있던 기본서들에 비해 데이터베이스 자체에 좀더 딥하게 들어가는느낌 - dc App

[백갤러 2(223.38)]

책 제목 뭐엿음

[30세전에특급DBA(118.235)]

데이터베이스 인터널스 - dc App