실제 데이터 저장 되는 장소 : 보조기억자치
이노DB는 이런 데이터를 저장 및 관리하는 역할.
DBMS도 하나의 소프트웨어라 할 수 있다.
하드디스크를 많이 사용한다.
분산데이터베이스 시스템에서 pluggable storage engines 많이 쓴다.
클러스터기반 DB관리?
분점 데이터 등을 관리 시 사용하는 엔진.
MySQL InnoDB 엔진 데이터베이스의 파일
데이터 파일
(ibdata)
사용자 데이터와 개체를 저장
테이블과 인덱스로 구성
확장자는 *.ibd
폼파일
(frm File)
테이블에 대한 각종 정보와 테이블을 구성하는 필드, 데이터 타입에 대한
정보 저장(schema)
데이터베이스 구조 등의 변경사항이 있을 때 자동으로 업데이트됨
인덱스(index, 색인) : 도서의 색인이나 사전과 같이 데이터를 쉽고 빠르게 찾을 수 있도록 만든 데이터 구조
B(alanced) - tree
2개 이상의 차일드
균형있게 쌓여있다. 한쪽으로 쏠려있지 않음.
인덱스의 특징
인덱스는 테이블에서 한 개 이상의 속성을 이용하여 생성함
빠른 검색과 함께 효율적인 레코드 접근이 가능함
순서대로 정렬된 속성과 데이터의 위치만 보유하므로 테이블보다 작은 공간을 차지함
저장된 값들은 테이블의 부분집합이 됨
일반적으로 B-tree 형태의 구조를 가짐
데이터의 수정, 삭제 등의 변경이 발생하면 인덱스의 재구성이 필요함
B+tree : 리프노드끼리 연결된 형태
클러스터 인덱스(= primary index)
기본적인 인덱스로 테이블 생성 시 기본키를 지정하면 기본키에 대하여 클러스터 인덱스를 생성한다.
기본키를 지정하지 않으면 먼저 나오는 UNIQUE 속성에 대하여 클러스터 인덱스를 생성한다.
기본키나 UNIQUE 속성이 없는 테이블은 MySQL 이 자체 생성한 행번호(Row ID)를 이용하여 클러스터 인덱스를 생성한다.
보조 인덱스
클러스터 인덱스가 아닌 모든 인덱스는 보조 인덱스이며 보조 인덱스의 각 레코드는 보조 인덱스 속성과 기본키 속성 값을 갖고 있다.
보조 인덱스를 검색하여 기본키 속성 값을 찾은 다음 클러스터 인덱스로 가서 해당 레코드를 찾는다.
HDD에서 페이지는 하나의 클러스터라고 보면 된다?
블록보다 더 큰 개념.
세컨더리(보조) 인덱스는 클러스터 인덱스 기준으로 SORTING되서 동시에 SORTING할 수 없다?
세컨더리는 반드시 클러스터를 이용해 접근한다. 클러스터 인덱스 기준 소팅되었기 때문에 조회를 연계해서 한다는 것 같다.
정처기에서는 차이점만 나온다고 한다.
데이터는 클러스터 인덱스(=primary index) 기준으로 정렬된다.
전부 인덱스 만들어놓으면 빠르지만 용량이 부족해진다.
따라서 자주사용되는 컬럼, 비교시간이 오래걸리는 문자열등에 많이 사용함.
primary index는 반드시 만들어야함.
인덱스 생성 시 고려사항
인덱스는 WHERE 절에 자주 사용되는 속성이어야 함
인덱스는 조인에 자주 사용되는 속성이어야 함
단일 테이블에 인덱스가 많으면 속도가 느려질 수 있음(테이블당 4~5개 정도 권장)
=> 데이터 삽입 시 인덱스 업데이트 할 게 많아진다.
속성이 가공되는 경우 사용하지 않음
=> 반납일은 주문일의 7일 까지. 따라서 반납일은 따로 만들지 않음. 이런 drive(유도)되는 속성은 중복해서 만들 필요없다?
속성의 선택도가 낮을 때 유리함(속성의 모든 값이 다른 경우)
=> 속성의 모든 값이 비슷하면 쓸 이유가 없다. ex) 성별.
CREATE [UNIQUE] INDEX 테이블이름
ON 테이블이름 (컬럼 [ASC | DESC]{, 컬럼 [ASC | DESC]}…])[ ; ]
ALTER TABLE 테이블이름
ADD INDEX [인덱스이름] (컬럼 [ASC | DESC]{, 컬럼 [ASC | DESC]}…])[ ; ]
SHOW INDEX FROM 테이블이름;
Non_unique: 유니크하지 않은가? 0과 1만 있음.
cardinality: 유니크한 속성값의 갯수?
