PK 클러스터링 인덱스의 리프노드가 실제로 물리적으로 연속된게 아니라 논리적으로 페이지 블록이 포인터로 연결되어 있다는 데 그럼 그걸 클러스터링이라고 할 수 있음? 클러스터링 인덱스로 리프노드 풀스캔하면 순차I/O가 아니라 랜덤 I/O가 되버리는게 아님?? - dc official App
디시 서버렉 ㅅㅂ
나는 이런 질문을 한적이 없는데?
MYSQL은 pk값으로 클러스터링해서 저장하는데 클러스터링 해서 저장한다는 말이 물리적으로 연속된 위치에 저장한다는거 아닌가
질문은 다른사람이 했던건데 걍 님에게 물어보는거임 - dc App
당연히 랜덤 I/O지
근데 MYSQL은 pk를 설정하면 pk로 클러시트링 하고 pk가 없으면 내부적으로 auto_increment값을 생성해서 그걸로 클러스터링해서 의미 없잖아
MYSQL은 그래서 순차 I/O임
보통 세컨더리인덱스 레코드가 많으면 랜덤 I/O가 많아져서 풀스캔하는데 풀스캔도 랜덤I/O아님? 걍 얼마나 다음 레코드가 인접해있는지 차이인가 - dc App
풀스캔은 순차 I/O아닌가?
클러스터링해서 저장하는데 테이블 풀스캔은 순차I/O고 세컨더리 인덱스 풀 스캔은 랜덤 I/O가 될수있지
세컨더리 인덱스를 풀 스캔하면 그건 더이상 클러스터링 된 데이터 순으로 읽는게 아니니까 랜덤 I/O가 많아져서 비효율적이지 ㅇㅇ
클러스터링 인덱스 리프노드에 페이지 블록 간의 링크드리스트로 연결된 구조인데 이것도 순차 I/O라 하는건가 완벽히 물리적으로 인접한건 아닌데 - dc App
내 말은 실제 데이터 페이지가 물리적으로 연속되게 저장된다는 거임
그게 클러스터링이니까
그래서 테이블 풀 스캔을 때리면 실제 데이터가 물리적으로 연속되게 저장되어 있으니 순차 I/O라는거
delete연산때매 물리적으로 모든 레코드가 연속될 수 없는데? - dc App
최대한 물리적으로 연속된 위치에 저장하는걸 보장해주는거지 완벽하게 순차는 아님
223.39말처럼 페이지 블록이 링크드리스트 포인터로 연결된 구조임 - dc App
페이지 블록이 링크드리스트로 저장되는게 B+Ttree니까
그니까 질문이 뭐임?
db뉴빈데 내가 물어봣ㄱ던것 같음 ㅎㅎ근데 그렇게되면 실제로는 순차io아님? 프라이머리 인덱스에 실제 레코드 달려있고 페이지마다 포인터로 연결된거 범위로 긁으면 순차 아닐까?
커버링이 불가능한 쿼리로 세컨더리 인덱스 스캔하면 그게 랜덤io 아닌가여? mysql에서는
그런듯ㅇㅇ - dc App
이건 랜덤I/O가 맞다니까 세컨더리 인덱스가 링크드 리스트로 저장하고 있어도 실제 데이터 블록을 읽는 순서랑 일치하지 않아 랜덤 I/O라고
정확히는 B+tree가 리프노들끼리 다음 위치의 포인터를 가르키는거지 ㅇㅇ
순차적인 삽입만 이루어질때디스크에서 연속된 저장공간에 저장되는데페이지 분할에 의한 조각화 정도에따라 랜덤io 비율이 높아지는거로 기억함HDD를 주요 사용하는 환경에서는조각화를 관리하면 유효한 성능 향상이있을것 같긴한데SSD에서는 굳이 인가 싶기도 함 - dc App
그리고 차피 힙도 테이블도 인덱스도 디스크내 저장된 데이터에 대한 인터페이스라고 봐야하지 않나프로그램 레벨에서 조작하는데이터 구조나 데이터들은 디스크의 물리적인동작을 제어할 수 없으니프로그램 레벨에서 군집화 되었다고 하는게아닌가 하는 뇌피셜 - dc App