책너두 6기 27일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.277 ~ p.286 내용정리 08 인덱스 8.9 유니크 인덱스 유니크는 인덱스라기보다는 제약 조건에 가깝다고 볼 수 있다. 테이블이나 인덱스에 같은 값이 2개 이상 저장될 수 없다는 의미이다. MySQL에서는 인덱스 없이 유니크 제약만 설정할 방법이 없다. NULL은 특정 값이 아니므로 2개 이상 저장될 수 있다. 8.9.1 유니크 인덱스와 일반 세컨더리 인덱스의 비교 유니크 인덱스와 유니크하지 않은 일반 세컨더리 인덱스는 사실 인덱스의 구조상 아무 차이가 없다 ...
책너두 6기 26일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.267 ~ p.276 내용정리 08 인덱스 8.6.2 함수를 이용한 인덱스 다음과 같이 테이블의 구조를 변경하지 않고, 함수를 직접 사용하는 인덱스를 생성할 수 있다. 1 2 3 4 5 6 7 create table user( user_id BIGINT, first_name VARCHAR(10), last_name VARCHAR(10), PRIMARY KEY (user_id), INDEX ix_fullname ((concat(first_name,' ',last_name))) ); 함수를 직접 사용하는 인덱스는 테이블의 구조는 변경하지 않고, 검색을 빠르게 만들어준다. 제대로 활용하려면 반드시 조건절에 함수 기반 인덱스에 명시된 표현식이 그대로 사용돼야 한다. ...
책너두 6기 25일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.258 ~ p.266 내용정리 08 인덱스 8.5 전문 검색 인덱스 현재까지 공부한 인덱스 알고리즘은 크지 않은 데이터나 이미 키워드화한 작은 값에 대한 인덱싱 알고리즘이다. 문서 전체에 대한 분석과 검색을 위한 이러한 인덱싱 알고리즘을 전문 검색(Full Text search) 인덱스 라고 한다. 이는 일반화된 기능의 명칭이다. 8.5.1 인덱스 알고리즘 전문 검색에서는 문서 본문의 내용에서 사용자가 검색하게 될 키워드를 분석해 내고, 빠른 검색용으로 사용할 수 있게 이러한 키워드로 인덱스를 구축한다. ...
책너두 6기 24일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.247 ~ p.257 내용정리 08 인덱스 8.3.7 B-Tree 인덱스의 가용성과 효율성 쿼리의 where 조건이나 group by, 또는 order by 절이 어떤 경우에 인덱슬르 사용할 수 있고 어떤 방식으로 사용할 수 있는지 식별할 수 있어야 한다. 8.3.7.1 비교 조건의 종류와 효율성 다중 칼럼 인덱스에서 각 칼럼의 순서와 그 칼럼에 사용된 조건이 동등 비교("=")인지 아니면 크다(">") 또는 작다("<") 같은 범위 조건인지에 따라 각 인덱스의 칼럼의 활용 형태가 달라지며, 그 효율 또한 달라진다. ...
책너두 6기 23일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.237 ~ p.246 내용정리 08 인덱스 8.3.4.4 인덱스 스킵 스캔 데이터베이스 서버에서 인덱스의 핵심은 값이 정렬돼 있다는 것이며, 이로 인해 인덱스를 구성하는 칼럼의 순서가 매우 중요하다. 기존에 루스 인덱스 스캔이 비슷한 최적화를 수행했지만 새로 도입된 인덱스 스킵 스캔은 용도가 훨씬 넒어졌다. 단점 Where 조건절에 조건이 없는 인덱스의 선행 칼럼의 유니크한 값의 개수가 적어야 함 : 개수가 많으면 인덱스에서 스캔해야 할 시작 지점을 검색하는 작업이 많이 필요해져 쿼리의 처리 성능이 오히려 더 느려질 수 있다. 쿼리가 인덱스에 존재하는 칼럼만으로 처리 가능해야 함(커버링 인덱스) : 이후 버전에서 개선될 것으로 보임 8.3.5 다중 칼럼(Multi-column)인덱스 현재 까지는 1개의 칼럼만 포함된 인덱스 두 개 이상의 칼럼으로 구성된 인덱스를 다중 칼럼 인덱스(복합 칼럼 인덱스)나 “Concatenated Index"라고 함 다중 칼럼 인덱스에서는 인덱스 내에서 각 칼럼의 위치(순서)가 상당히 중요하다. 8.3.6 B-Tree 인덱스의 정렬 및 스캔 방향 인덱스의 키 값은 항상 오름차순이거나 내림차순으로만 정렬되어 저장된다. 8.3.6.1 인덱스의 정렬 인덱스를 생성하는 시점에 인덱스를 구성하는 각 칼럼의 정렬을 오름차순 / 내림차순 으로 설정 가능 정렬 순서를 혼합할 수 있음. 8.3.6.1.1 인덱스 스캔 방향 인덱스 생성 시점에 오름차순 또는 내림차순으로 정렬이 결정되지만 쿼리가 그 인덱스를 사용하는 시점에 인덱스를 읽는 방향에 따라 오름차순 또는 내림차순 정렬 효과를 얻을 수 있다. 8.3.6.1.2 내림차순 인덱스 인덱스 역순 스캔이 인덱스 정순 스캔에 비해 느리다. 인덱스를 내림차순 정렬하는 쿼리가 소량의 레코드에 드물게 실행되는 경우라면 내림차순 인덱스를 굳이 고려할 필요는 없다. 많은 레코드를 조회하면서 빈번하게 실행된다면 내림차순 인덱스가 더 효율적일 수도 있다. 많은 쿼리가 인덱스의 앞쪽만 또는 뒤쪽만 집중적으로 읽어서 인덱스의 특정 페이지 잠금에서 병목이 예상된다면 쿼리에서 자주 사용되는 정렬 순서대로 인덱스를 생성하는 것이 잠금 병목 현상을 완화하는데 도움이 된다.
책너두 6기 22일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.228 ~ p.236 내용정리 08 인덱스 8.3.3.3 선택도(기수성) 인덱스에서 선택도(Selectivity) 또는 기수성(Cardinality)은 거의 같은 의미로 사용되며, 모든 인덱스 키 값 가운데 유니크한 값의 수를 의미한다. 인덱스 키 값 가운데 중복이 많을수록 기수성과 선택도는 낮아진다. 선택도가 높을수록 검색 대상이 줄어서 빠르게 처리된다. 선택도가 좋지 않다고 하더라도 정렬이나 그루핑과 같은 작업을 위해 인덱스를 만드는 것이 훨씬 나은 경우도 많다. 인덱스에서 유니크한 값의 개수는 인덱스나 쿼리의 효율성에 큰 영향을 미친다. 8.3.3.4 읽어야 하는 레코드의 건수 인덱스를 통해 테이블의 레코드를 읽는 것은 인덱스를 안 거치는 것 보다 높은 비용이 든다. 100만 중 50만을 읽어야하는 쿼리가 있다면 무엇이 효율적일지 판단해야 한다. 테이블 모두 읽고 50만개 버리기 인덱스를 통해 필요한 50만 개 읽기 8.3.4 B-Tree 인덱스를 통한 데이터 읽기 mYSQL이 인덱스를 이용하는 대표적인 방법 세 가지 ...
책너두 6기 21일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.216 ~ p.227 내용정리 08 인덱스 8.1.2 랜덤 I/O와 순차 I/O 랜덤 I/O는 HDD의 플래터(원판)를 돌려서 읽어야 할 데이터가 저장된 위치로 디스크 헤더를 이동시킨 다음 데이터를 읽는 것을 의미 사실 순차 I/O도 이 작업 과정은 같다. 순차 I/O는 3개의 페이지(3X16KB)를 디스크에 기록하기 위해 1번 시스템 콜을 요청 => 디스크의 헤드 1번 이동 랜덤 I/O는 3개의 페이지를 디스크에 기록하기 위해 3번 시스템 콜을 요청 => 디스크의 헤드 3번 이동 ...
책너두 6기 20일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.205 ~ p.216 내용정리 07 데이터 암호화 7.3.3 테이블스페이스 이동 테이블을 다른 서버로 복사할 떄 혹은 특정 테이블의 데이터 파일만 백업 후 복구할 때 테이블 스페이스 이동 기능이 효율적이고 빠르다. 익스포트(Export) : flush tables source_table for export; 7.4 언두 로그 및 리두 로그 암호화 테이블 암호화를 적용해도 리두 로그나 언두 로그, 그리고 복제를 위한 바이너리 로그에는 평문으로 저장된다. 리두 로그나 언두 로그를 평문으로 저장하다가 암호화가 활성화되면 그떄부터 생성되는 리두 로그나 언두 로그만 암호화해서 저장한다. 해제해도 기존의 로그는 암호화된 상태로 남아있다. 7.5 바이너리 로그 암호화 테이블 암호화가 적용돼도 바이너리 로그와 릴레이 로그 파일 또한 평문을 저장한다. ...