MySQL 시리즈 -InnoDB 인덱스 소개 및 관리
운영 및 유지 보수 YouthO & M Youth
일련의 기사 설명
MySQL 시리즈 기사에는 소프트웨어 설치, 특정 사용, 백업 및 복구 등이 포함되며 주로 개인 학습 노트를 기록하는 데 사용됩니다. 사용되는 주요 MySQL 버전은 5.7.28이고 서버 시스템 버전은 CentOS 7.5입니다. 이 장은 InnoDB 인덱스 관리에 관한 것입니다.
인덱스
인덱스 정의
인덱스는 데이터베이스에서 데이터를 빠르게 검색하는 데 도움이되는 데이터 구조입니다. 평신도의 용어로 색인은 책의 목차와 같으며 목차를 통해 필요한 것을 빠르게 찾을 수 있습니다.
인덱싱의 장단점
인덱싱의 장점 :
1. 데이터 검색 속도를 높일 수 있습니다
2. 인덱싱을 통해 사용 과정에서 최적화 된 Hider를 사용하여 시스템 성능을 향상시킬 수 있습니다.
인덱싱의 단점 :
1. 테이블의 데이터를 추가, 삭제, 수정하는 경우 인덱스를 동적으로 유지해야하므로 추가 / 변경 / 삭제의 실행 효율성이 떨어집니다
2. 인덱스가 물리적 공간을 차지해야합니다 .
인덱스 인덱스 분류
MySQL InnoDB에서 인덱스는 클러스터형 인덱스와 보조 인덱스 (비 클러스터형 인덱스)로 나눌 수 있습니다.
클러스터형 인덱스
인덱스 B + Tree의 리프 노드는 데이터의 전체 행을 저장하는 클러스터형 인덱스라고도하는 기본 키 인덱스입니다. 클러스터형 인덱스는 디스크의 실제 데이터를 재구성하여 하나 이상의 지정된 열 값을 기준으로 정렬하는 알고리즘입니다. 특징은 저장된 데이터의 순서가 인덱스 순서와 일치한다는 것입니다. 일반적으로 기본 키는 기본적으로 클러스터형 인덱스를 생성하며 데이터가 저장되면 순서가 하나만있을 수 있기 때문에 테이블에는 클러스터형 인덱스가 하나만 허용됩니다. 인덱스를 찾으면 필요한 데이터를 찾은 다음 인덱스는 클러스터형 인덱스이므로 기본 키는 클러스터형 인덱스입니다. 클러스터형 인덱스를 수정하면 실제로 기본 키가 수정됩니다.
일반적으로 테이블에는 클러스터형 인덱스가 있어야합니다. 정의되어 있지 않더라도 InnoDB는 인덱스를 생성 할 열을 자동으로 선택합니다.
1) 기본 키가있는 경우 기본 키를 기반으로 클러스터형 인덱스를 생성합니다.
2) 언제 기본 키가 없으면 고유하지 않고 고유 한 인덱스를 사용합니다. 빈 인덱스 컬럼이 기본 키로 사용되어이 테이블의 클러스터형 인덱스가됩니다
.3) 위의 두 가지가 충족되지 않으면 innodb는 그 자체
다음 표가있는 경우 :
CREATE TABLE world.student(
`id` INT AUTO_INCREMENT NOT NULL COMMENT 'id',
`name` VARCHAR(10) NOT NULL COMMENT '姓名',
`age` INT NOT NULL COMMENT '年龄',
PRIMARY KEY(id),
INDEX idx_name(NAME)
)ENGINE=INNODB DEFAULT CHARSET='utf8mb4';
INSERT INTO world.`student`(NAME,age) VALUES('张三',24),('李四',20),('王五',21),('运维少年',18);
클러스터형 인덱스 구조는 다음과 같습니다. 
클러스터형 인덱스 검색 프로세스 :
보조 색인
인덱스 B + Tree의 리프 노드는 기본 키의 값만 저장하고 인덱스 열은 비 클러스터형 인덱스라고도하는 비 기본 키 인덱스입니다. 테이블에는 클러스터되지 않은 여러 인덱스가있을 수 있습니다. 비 클러스터형 인덱스의 저장소는 데이터 저장소와 분리되어 있습니다. 즉, 인덱스를 찾을 수 있지만 데이터가없는 경우 인덱스의 값 (기본 키)을 기반으로 테이블을 다시 쿼리해야합니다. 비 클러스터형 인덱스는 보조 인덱스라고도합니다.
학생 테이블에있는 보조 그룹 인덱스의 데이터 구조 : 
보조 그룹 인덱스 조회 데이터 프로세스 (테이블로 돌아 가지 않음) :
보조 그룹 인덱스 검색 데이터 프로세스 (테이블로 돌아 가기) :
보조 인덱스 단일 열 인덱스
단일 컬럼 인덱스 즉, 하나의 컬럼을 보조 인덱스 컬럼으로 사용하지만 쿼리 조건이 보조 인덱스 컬럼을 사용하는 경우 인덱스가 사용됩니다.
보조 색인 다중 열 색인 (공동 색인)
공동 인덱스, 즉 다중 열 인덱스는 인덱스를 만들 때 다음과 같이 여러 열을 인덱스 열로 사용합니다.
alter table student add index idx_na(name,age);보조 색인 다중 열 색인 (공동 색인)
접두사 인덱스가 목표이고, 우리가 선택한 인덱스 열 값의 길이가 너무 길어 인덱스 높이가 증가하여 인덱스가 적용될 때 더 많은 인덱스 데이터 페이지를 읽을 수 있습니다. 인덱스 트리의 높이는 3-4 개의 레이어입니다. 따라서 인덱스 생성 조건으로 큰 필드의 첫 번째 부분을 선택할 수 있습니다.
책의 제목과 비슷하게 제목이 너무 길어질 수 없으며, 제목이 너무 길면 목차 생성시 목차 공간을 많이 차지하고 목차 페이지가 늘어납니다. 접두사 색인은 일반적으로 퍼지 쿼리에 사용됩니다.
다음 테이블이 있다면 sno 컬럼을 인덱스 컬럼으로 사용해야합니다. 비교를 통해 처음 6 자만 고유 값을 결정할 수 있음을 알 수 있습니다. 따라서 인덱스 생성시 프리픽스 길이를 다음과 같이 설정할 수 있습니다. 6 인덱스 트리의 높이를 줄입니다.
alter table xxx add index index_name(sno(2));인덱스 관리
색인보기 :
show index from world.student;
색인 삭제 :
drop index idx_name on world.student;
색인 생성 :
일반적인 방법 1 : 테이블 생성시 생성
CREATE TABLE world.student(
`id` INT AUTO_INCREMENT NOT NULL COMMENT 'id',
`name` VARCHAR(10) NOT NULL COMMENT '姓名',
`age` INT NOT NULL COMMENT '年龄',
PRIMARY KEY(id), # 聚簇索引
INDEX idx_name(name) # 辅助索引
)ENGINE=INNODB DEFAULT CHARSET='utf8mb4';일반적인 방법 2 : alter 문 사용
alter table world.student add index idx_name(name);
인덱스는 언제 생성됩니까?
1) 모든 열이 인덱싱되지 비즈니스 문의 필요에 따라 적절한 인덱스를 생성
더 많은 인덱스를 더하지 않는 것이, 모든 열이 인덱싱되지 않음) 2
3) 인덱스가 프로세스에 내장되어 순서에 따라 경우 그룹을 할 조건부 열에 대한 조인
무질서한 색인 생성의 결과?
1) 중복 인덱스가 너무 많으면 테이블 데이터가 변경되면 인덱스가 자주 업데이트 될 가능성이 높습니다. 많은 정상적인 비즈니스 요청을 차단합니다.
2) 인덱스가 너무 많으면 옵티마이 저가 편차를 선택하게됩니다.
인덱스 애플리케이션 사양 :
1. 테이블을 구축 할 때 기본 키가 있어야합니다. 기본 키는 숫자 열인 것이 좋습니다. 그렇지 않은 경우 관련없는 열을 사용자 정의하고 자체 성장으로 정의 할 수 있습니다.
2. 고유
인덱스를 선택할 때 값 고유 인덱스의 고유 인덱스는 고유하며 변경할 수 있습니다. 인덱스를 빠르게 사용
하여 학생 테이블 중학교 번호와 같은 레코드의 고유 필드 를 결정합니다 .이 필드에 대한 고유 인덱스를 설정하면 특정 학생의 정보를 빠르게 결정할 수 있습니다. . 이름이 변경 될 경우 같은 이름의 현상이 발생할 수 있으며, 질의 속도가 저하됩니다.
3. where, order by, group by, join on 등과 같은 작업이 자주 필요한 필드의 경우 정렬에 많은 시간이 낭비됩니다. 인덱스를 설정하여 쿼리를 최적화 할 수 있습니다. 열이 조건으로 자주 사용되는 경우 너무 많은 중복 값은, 공동 지수는 설정할 수 있습니다.
4. 접두사 인덱스를 가능한 한 많이. 인덱스 필드의 값이 매우 긴 경우,이 인덱스 값의 접두사를 사용하는 것이 가장 좋습니다.
5. 제한
인덱스 의 수는 가능한 한 많지 않습니다. 발생할 수있는 문제
1) 각 인덱스가 필요합니다. 디스크 공간을 차지할수록 인덱스가 많을수록 디스크 공간이 더 많이 필요합니다
.2) 테이블을 수정할 때 인덱스를 재구성하고 업데이트하는
것이
번거 롭습니다 . 인덱스가 많을수록 테이블 업데이트는 시간 낭비가됩니다. 3) 옵티 마이저 부담이 무거워 옵티 마이저 선택에 영향을 미칠 수 있습니다. percona-toolkit에는 다음과 같은 도구가 있습니다 . 특히 인덱스가 유용한 지 여부를 분석하고
, 더 이상 사용되지 않거나 거의 사용되지 않는 인덱스
7을 삭제 하고, 큰 테이블에 인덱스를 추가 합니다 . 바쁜 기간 동안 작업
8. 업데이트 된 값 열에 가능한 한 적게 빌드하십시오.
색인 보충
보충 준비 양식
CREATE TABLE world.student(
`id` INT AUTO_INCREMENT NOT NULL COMMENT 'id',
`name` VARCHAR(10) NOT NULL COMMENT '姓名',
`age` CHAR(3) NOT NULL COMMENT '年龄',
`address` VARCHAR(20) NOT NULL COMMENT '地址',
`phone` VARCHAR(11) NOT NULL COMMENT '手机号码',
PRIMARY KEY(id),
INDEX idx_info(age,NAME,address)
)ENGINE=INNODB DEFAULT CHARSET='utf8mb4';
INSERT INTO world.`student`(NAME,age,address,phone) VALUES('张三',24,'北京市','10086'),('李四',20,'上海市','10000'),('王五',21,'重庆市','10010'),('运维少年',18,'天津市','13800138000');
SQL이 인덱싱되었는지 여부를 확인하는 방법은 무엇입니까?
방법 1 : 설명
explain 执行的语句
explain select * from student where id=1;방법 2 : desc
desc 执行的语句
desc select * from student where name='张三'
보조 인덱스 스캔 유형
1) 인덱스 전체 인덱스 스캔-전체 인덱스 트리를 스캔해야 함
인덱스 전체 인덱스 스캔은 일반적으로 쿼리 열이 인덱스 열일 때 발생합니다.
select id from student;
2) 범위-범위 스캔
쿼리 조건이>, <, in, like 인 경우 유형은 범위가됩니다.
3) 참조 보조 인덱스 등가 쿼리
보조 인덱스 등가 쿼리는 일반적으로 등가 쿼리에 보조 인덱스 열을 사용할 때 발생합니다.
4) Const 기본 키 해당 쿼리
클러스터형 인덱스 동등한 쿼리는 일반적으로 클러스터형 인덱스 열을 사용하여 동등한 쿼리를 수행 할 때 발생합니다.
어떤 상황에서 색인이 추가되지 않습니까?
1) 쿼리 조건 없음
2) 결과 집합을 질의 할 때 원본 테이블에있는 대부분의 데이터는 15 % -30 %가되어야하며, 초과 할 경우 옵티마이 저는 인덱싱 할 필요가 없다고 느끼며 리미 페이징을 사용할 수 있습니다. 
3) 질의 조건 색인 열의 함수에 속합니다. 또는 색인 열에 대한 작업을 수행하면 작업에 (+- /! 등)이
포함됩니다 . 잘못된 예 : 학생 ID-1 = 2
에서 선택 , 올바른 예 : 학생 ID = 3에서 * 선택 ; 
4) 암시 적 변환으로 인해 인덱스가 실패합니다.이 점은 심각하게 받아 들여야하며이 실수는 종종 발생합니다. char가 정의 된 경우 쿼리 할 때 숫자 유형이 사용됩니다. 
5) not in은 보조 인덱스를 사용하지 않습니다. 또는 또는 in은 공용체 
6 으로 변경 될 수 있습니다. 예를 들어 "% _"는 백분율 기호 앞에 가지 않습니다.
보충 다중 열 색인 (공동 색인)
여러 열을 사용하여 인덱스 idx (age, name, address) 결합
유효한 색인 : 나이 나이, 이름 나이, 이름, 주소 (연령으로 시작하고 연속적으로 만)
유효하지 않은 색인 : 이름 주소 이름, 주소
인덱스는 동일 할 수만 있고 범위 값은 갈 수 없습니다.
1、age= and name= and address= #索引能到address
2、age= and name> and address= # 索引能到name
3、age< and name = and address= # 索引能到a
