클러스터형 인덱스
보조 인덱스
고유 인덱스
클러스터형 인덱스
기본키
기본키에 의해 자동으로 정렬됨.
영어사전과 비슷함.
자동정렬.
보조 인덱스
자동정렬 안일어남.
일단은 인덱스 기본 작동 원리부터. (클러스터)
이거 트리 형식임.
이런 식인데,
그러니까 노드? 라는 게 있음.
mySql에선 페이지라고 부름
이 페이지는 한 건의 데이터가 아니라,
이런 식으로 어떤 테이블? 처럼
저 각각이 primary key, 더 정확히는 인덱스 라고 보면 됨.
이렇게 트리구조로, 찾아감.
맨 위를 루트페이지, 최 하단 저 페이지들을 리프페이지라고 하는데,
말했다시피 트리구조임. 데이터 많아지면 또 저기서 트리구조로 펼쳐지는 거.
저러 한 페이지들이 테이블마다 다 따로 있는 거.
데이터가 넘치게 되면, 페이지를 분할 시킴
여기서 만약 CCC를 넣어서 (이거는 클러스터니 순서가 있음)
저기 사이에 아직 공간이 있으니
AAA
BBB
CCC
DDD
이렇게 됨.
근데 넘쳐나게 되면?
페이지를 하나 더 생성하면서,
나눔.
내부적으로는 자세히 모르겠지만 뭐 한 반 나눈다고 일단은 생각하셈.
또 그러면 부모 인덱스에 추가가 됨.
AAA
BBB
CCC
DDD인데,
EEE를 넣어서 넘치게 되면
대충
AAA
BBB
CCC
와
DDD
EEE로 나뉜다고 생각.
그러면 부모페이지에 또
AAA의 주소
DDD의 주소가 써짐.
자식 페이지는 부모페이지에 대한 정보를 가지고 있음.
한 페이지는 16kb임. 하나만 저장해도 16kb의 저장공간을 가지고 감.
그 다음 비클러스터형 인덱스, 그러니까 유니크 같은거
순서 없는 거.
이거는 페이지가 두종류임.
인덱스 페이지와, 데이터페이지로 나뉨.
이렇게 인덱스에 대한, 참조에 대한 정보를 저장하는 페이지와, 데이터 페이지로 나뉨.
이거는 순서를 신경쓸 필요가 없기 때문에, 저렇게 참조에 대한 정보를 저장해도 효율적임.
데이터가 늘어나면 그냥 추가가 되는거지, 순서에 맞춰 어디 사이에 끼어 넣는게 아니니까.
그냥 참조에 대한 정보만 알면 됨.
그래서 프라이머리키(클러스터형 인덱스)로 바꾸면 자동으로 정렬됨. (조회할 때. 테이블을 물리적으로 바꾸는 게 아니라. 프라이머리 키로 바꾸면 인덱스가 생성되는거임. 그에 따라 페이지도 생성되고. 조회 자체가 클러스터 인덱스가 있는지 없는지 확인한다고 함.)
인덱스 추가
create index idx_memer_addr on member (addr);
create index 인덱스명 on 테이블명(열명)
인덱스들 보기
show index from member;
show index from 테이블명
페이지 크기? 보기
show table status like 'member';
show table status like '테이블명';
근데, 인덱스를 생성했다고 저장공간까지 잡아주지는 않음. 생성한다음, 분석까지 시켜줘야 인식함.
create index idx_memer_addr on member (addr);
analyze table member;이렇게 분석까지 해 놓고,
show table status like 'member';해야 인지함.
유니크 인덱스 생성
create unique index idx_member_mem_number on member (mem_number);
create unique index 인덱스명 on 테이블명 (열명)
analyze table member;
인덱스 제거
drop index idx_memer_addr on member;
drop index 인덱스명 on 테이블명
프라이머리키는
alter table member drop primary key;
alter table 테이블명 drop primary key;이렇게 해서 프라이머리키 특성 제거. 어차피 프라이머리키는 하나밖에 없으니까 알아서 찾음.
테이블 관계? 외래키 관계 보기
select table_name, constraint_name
from information_schema.referential_constraints
where constraint_schema = 'market_db';
select table_name, constraint_name
from information_schema.referential_contraints
where constraint_schema = 'DB이름'말 그대로 테이블명이랑 제약을 조회해 오는거임.
근데 referential_constraints 참조 제약조건에서 가져옴.
market_db에서
저기에 나오는 저 제약속성(foreign)을 먼저 제거해야 primary속성도 제거할 수 있음.
alter table buy drop foreign key buy_ibfk_1;
alter table 테이블명 drop foreign key 제약명
alter table member drop primary key;
alter table 테이블명 drop primary key;