데이터베이스 관리 중 19 개 MySQL 최적화 방법

MySQL 데이터 베 이 스 를 최적화 한 후에 데이터 뱅 크 의 번 거 로 움 을 줄 일 수 있 을 뿐만 아니 라 데이터 뱅 크 의 운행 속 도 를 모두 바 꿀 수 있 습 니 다.다음은 우리 가 정리 한 19 개의 아주 좋 은 MySQL 데이터 베이스 최적화 방법 을 참고 하 겠 습 니 다.
설명:아래 의 최적화 방안 은 모두"Mysql-색인-BTree 형식"을 바탕 으로 합 니 다.
1.EXPLAIN
MySQL 최 적 화 를 하려 면 EXPLAIN 으로 SQL 실행 계획 을 잘 살 펴 야 합 니 다.
다음은 간단 한 예 를 들 어(1,2,3,4,5)우리 가 중점적으로 주목 해 야 할 데 이 터 를 표시 합 니 다.

type 열,연결 형식.좋 은 sql 문 구 는 적어도 range 단계 에 도달 해 야 합 니 다.all 단계 key 열 이 나타 나 는 것 을 차단 합 니 다.사용 하 는 색인 이름 입 니 다.색인 을 선택 하지 않 으 면 값 은 NULL 입 니 다.강제 색인 방식 keylen 열,색인 길이 rows 열,스캐닝 줄 수.이 값 은 예비 평가 extra 열 로 상세 하 게 설명 합 니 다.흔히 볼 수 있 는 그다지 우호 적 이지 않 은 값 은 다음 과 같 습 니 다:Using filesort,Using temporary 2,SQL 구문 에 IN 이 포함 하 는 값 이 너무 많 으 면 안 됩 니 다.
MySQL 은 IN 에 대해 해당 하 는 최 적 화 를 했 습 니 다.곧 IN 의 상수 가 한 배열 에 저 장 될 것 입 니 다.그리고 이 배열 은 순서 가 있 습 니 다.하지만 수치 가 많 으 면 소모 도 크다.예 를 들 어 selectid from t where num in(1,2,3)은 연속 적 인 수치 에 대해 between 을 사용 할 수 있 으 면 in 을 사용 하지 마 십시오.연결 로 바 꾸 거나.
3.SELECT 문 구 는 필드 이름 을 반드시 밝 혀 야 합 니 다.
SELECT*불필요 한 소모(cpu,io,메모리,네트워크 대역 폭)를 많이 증가 합 니 다.덮어 쓰기 인덱스 사용 가능성 증가;표 구조 가 바 뀌 었 을 때 전단 도 업데이트 가 필요 합 니 다.그래서 select 뒤에 필드 이름 을 직접 연결 해 달라 고 했 습 니 다.
4.하나의 데이터 만 필요 할 때 limit 1 을 사용 합 니 다.
이것 은 EXPLAIN 에서 type 열 을 const 형식 으로 만 들 기 위해 서 입 니 다.
5.정렬 필드 에 색인 을 사용 하지 않 으 면 정렬 을 최소 화 합 니 다.
6.제한 조건 중 다른 필드 에 색인 이 없 으 면 or 를 적 게 사용 합 니 다.
or 양쪽 필드 에 색인 필드 가 아 닌 다른 조건 이 색인 필드 가 아 닌 경우 이 검색 이 색인 으로 가지 않 는 경우 가 있 습 니 다."or"대신 유 니 온 all 또는 유 니 온(필요 할 때)방식 을 사용 하 는 경우 가 많다.
7.가능 한 한 유 니 온 all 로 유 니 온 을 대체 합 니 다.
유 니 온 과 유 니 온 all 의 차 이 는 주로 전자 가 결과 집합 을 합 친 후에 유일한 여과 작업 을 해 야 한 다 는 것 이다.이것 은 정렬 과 관련 되 고 대량의 CPU 연산 을 증가 하 며 자원 소모 와 지연 을 증가 할 것 이다.물론 유 니 온 all 의 전제조건 은 두 결과 집합 에 중복 데이터 가 없다 는 것 이다.
8.ORDER BY RAND()를 사용 하지 않 음

select id from `dynamic` order by rand() limit 1000;

 
위의 sql 문 구 는 최적화 할 수 있 습 니 다.

select id from `dynamic` t1 join (select rand() * (select max(id) from `dynamic`) as nid) t2 on t1.id > t2.nid limit 1000;

 
9.in 과 exists 를 구분 하고 not in 과 not exists

select * from  A where id in (select id from  B)

 
위의 sql 문 구 는

select * from  A where exists(select * from  B where  B.id= A.id)

 
in 과 exists 를 구분 하 는 것 은 주로 구동 순 서 를 바 꾸 는 것 입 니 다.(이것 은 성능 변화의 관건 입 니 다)exists 라면 외층 표를 구동 표 로 하고 먼저 방문 합 니 다.IN 이 라면 하위 조 회 를 먼저 실행 합 니 다.그래서 IN 은 외모 가 크 고 내 표 가 작은 경우 에 적합 하 다.EXISTS 는 겉 은 작고 속 은 큰 경우 에 적합 하 다.
not in 과 not exists 에 대해 서 는 not exists 를 추천 합 니 다.효율 적 인 문제 뿐만 아니 라 not in 에 논리 적 인 문제 가 있 을 수 있 습 니 다.어떻게 하면 not exists 를 대체 하 는 sql 문 구 를 효율적으로 쓸 수 있 습 니까?
원 sql 문

select colname … from A  where a.id not in (select b.id from B )

 
효율 적 인 sql 문장

select colname … from A  Left join B  on where a.id = b.id where b.id is null

 
추출 한 결과 집합 은 아래 그림 과 같이 A 표 가 B 표 에 없 는 데 이 터 를 나타 낸다.

10.합 리 적 인 페이지 방식 을 사용 하여 페이지 의 효율 을 높 인 다.

select id,name from product limit 866613, 20

 
상기 sql 문 구 를 사용 하여 페이지 를 나 눌 때 표 데이터 의 양 이 증가 함 에 따라 limit 페이지 를 직접 사용 하여 조회 하 는 것 이 점점 느 려 지 는 것 을 발견 할 수 있 습 니 다.
최적화 방법 은 다음 과 같다.이전 페이지 의 최대 줄 수 id 를 가 져 온 다음 에 이 최대 id 에 따라 다음 페이지 의 시작 점 을 제한 할 수 있다.이 열 보다 이전 페이지 의 가장 큰 id 는 866612 입 니 다.sql 은 다음 과 같은 문법 을 사용 할 수 있 습 니 다.

select id,name from product where id> 866612 limit 20

11.세그먼트 조회
일부 사용자 가 페이지 를 선택 할 때 일부 사용자 가 선택 한 시간 범위 가 너무 커서 조회 가 느 릴 수 있 습 니 다.주요 원인 은 스캐닝 줄 수가 너무 많 기 때문이다.이 럴 때 는 프로그램,세그먼트 별로 조회 하고 순환 적 으로 옮 겨 다 니 며 결 과 를 합 쳐 보 여줄 수 있다.
아래 그림 에서 이 sql 문 구 를 보면 스 캔 한 줄 이 백만 급 이상 일 때 세그먼트 조 회 를 사용 할 수 있 습 니 다.

12.where 자구 에서 필드 에 대해 null 값 판단 을 하지 않도록 합 니 다.
null 에 대한 판단 은 엔진 이 색인 사용 을 포기 하고 전체 표 스 캔 을 할 수 있 습 니 다.
13.%접두사 모호 조 회 를 사용 하 는 것 을 권장 하지 않 습 니 다.
예 를 들 어 LIKE'%name'이나 LIKE'%name%'와 같은 검색 은 색인 이 효력 을 상실 하여 전체 표 스 캔 을 할 수 있 습 니 다.다만 LIKE'name%'를 사용 할 수 있다.
그럼%name%를 어떻게 조회 합 니까?
아래 그림 에서 보 듯 이 시 크 릿 필드 에 색인 을 추 가 했 지만 explain 결과 에 서 는 사용 되 지 않 았 습 니 다.

그렇다면 이 문 제 를 어떻게 해결 할 것 인가?
저희 조회 에 서 는 selection id,fnum,fdst from dynamic 를 자주 사용 합 니 다.201606 where user_name like '%zhangsan%'; 。이러한 문 구 는 일반 색인 으로 는 조회 수 요 를 만족 시 킬 수 없다.다행히도 MySQL 에 전문 색인 이 있어 서 우 리 를 도 왔 다.
전체 텍스트 인덱스 를 만 드 는 sql 문법 은:

ALTER TABLE `dynamic_201606` ADD FULLTEXT INDEX `idx_user_name` (`user_name`);

 
전체 텍스트 색인 을 사용 하 는 sql 문 구 는:

select id,fnum,fdst from dynamic_201606 where match(user_name) against('zhangsan' in boolean mode);

 
메모:전체 텍스트 인덱스 를 만 들 기 전에 DBA 에 연락 하여 만 들 수 있 는 지 확인 하 십시오.동시에 주의해 야 할 것 은 검색 어의 쓰기 와 일반 색인 의 차이 이다.
14.where 자구 에서 필드 를 표현 식 으로 조작 하 는 것 을 피한다.
예 를 들 면

select user_id,user_project from user_base where age*2=36;

 
필드 에 대하 여 산술 연산 을 하면 엔진 이 색인 사용 을 포기 하고 바 꾸 는 것 을 권장 합 니 다.

select user_id,user_project from user_base where age=36/2;

 
15.암시 적 유형 전환 을 피한다.
where 자구 에 column 필드 의 유형 과 들 어 오 는 매개 변수 유형 이 일치 하지 않 을 때 발생 하 는 유형 변환 은 where 의 매개 변수 유형 을 먼저 확인 하 는 것 을 권장 합 니 다.

 
16.연합 색인 에 있어 서 가장 왼쪽 접두사 법칙 을 지 켜 야 한다.
예 를 들 어 색인 은 필드 id,name,school 을 포함 하고 있 습 니 다.id 필드 를 직접 사용 할 수도 있 고 id,name 같은 순서 도 있 지만 name;school 에서 이 색인 을 사용 할 수 없습니다.따라서 연합 색인 을 만 들 때 색인 필드 순 서 를 주의해 야 합 니 다.자주 사용 하 는 검색 필드 는 맨 앞 에 두 어야 합 니 다.
17.필요 할 때 force index 를 사용 하여 특정한 색인 을 강제로 조회 할 수 있 습 니 다.
어떤 때 는 MySQL 최적화 기 가 적합 하 다 고 생각 하 는 색인 을 사용 하여 sql 문 구 를 검색 하지만,아마도 그것 이 사용 하 는 색인 은 우리 가 원 하 는 것 이 아 닐 것 입 니 다.이 때 는 force index 를 사용 하여 우리 가 만 든 색인 을 강제로 사용 할 수 있 습 니 다.
18.주의 범위 조회 문구
연합 색인 에 있어 서 범위 조회,예 를 들 어 between,>,<등 조건 이 존재 하면 뒤의 색인 필드 가 효력 을 잃 을 수 있 습 니 다.
19.JOIN 최적화

LEFT JOIN A 표 는 드라이버 이 고 INNER JOIN MySQL 은 데이터 가 적은 표 의 역할 구동 표를 자동 으로 찾 아 냅 니 다.Right JOIN B 표 는 드라이버 입 니 다.
메모:MySQL 에 full join 이 없 으 면 다음 과 같이 해결 할 수 있 습 니 다.

select * from A left join B on B.name = A.name 
where B.name is null
 union all
select * from B;

가능 한 한 inner join 을 사용 하여 left join 을 피하 십시오.
공동 조회 에 참여 하 는 표 는 최소 2 장의 표 로 크기 의 구분 이 있다.만약 에 연결 방식 이 inner join 이 라면 다른 여과 조건 이 없 는 상황 에서 MySQL 은 자동 으로 작은 시 계 를 구동 표 로 선택 하지만 left join 은 구동 표 의 선택 에 있어 왼쪽 구동 오른쪽 원칙,즉 left join 왼쪽 표 이름 을 구동 표 로 따른다.
색인 을 합 리 적 으로 이용 하 다.
드라이버 의 색인 필드 를 on 의 제한 필드 로 합 니 다.
작은 시 계 를 이용 하여 큰 시 계 를 구동 하 다.

원리 도 에서 볼 수 있 듯 이 구동 표를 줄 일 수 있다 면 포 함 된 순환 횟수 를 줄 여 줄 일 수 있다. IO 총량 및 CPU 연산 횟수.
교묘 하 게 STRAIGHTJOIN
inner join 은 my sql 에서 드라이버 를 선택 하지만 일부 특수 한 상황 에 서 는 다른 시 계 를 드라이버 로 선택해 야 합 니 다.예 를 들 어 group by,orderby 등'Using filesort','Using temporary'가 있 을 때.STRAIGHT_조인 이 연결 순 서 를 강제 합 니 다.STRAIGHTJOIN 의 왼쪽 시계 이름 은 드라이버 이 고 오른쪽 은 피 드라이버 입 니 다.STRAIGHT 사용 중조인 은 이 조회 가 내부 연결,즉 inner join 이라는 전제조건 이 있다.다른 링크 는 STRAIGHT 를 추천 하지 않 습 니 다.JOIN,그렇지 않 으 면 조회 결과 가 정확 하지 않 을 수 있 습 니 다.

이 방식 은 때때로 세 배의 시간 을 줄 일 수 있다.
여기 에는 상술 한 최적화 방안 만 열거 되 어 있 습 니 다.물론 다른 최적화 방식 도 있 습 니 다.여러분 은 시도 해 보 세 요.관심 가 져 주 셔 서 감사합니다.