파 티 션 테이블 필드 에서 의 SQL 최적화

독 서 를 지도하 다
어떤 시 계 는 구역 을 나 누 어 매일 한 구역 을 나눈다.
이 표 에는 조회 가 있 습 니 다.항상 표 의 어느 날 데이터 만 조회 하지만 매번 전체 구역 의 모든 데 이 터 를 스 캔 해 야 합 니 다.최적화 할 방법 이 있 습 니까?
최 적 화 를 기다 리 는 장면
큰 시계 가 있 는데 매일 발생 하 는 데 이 터 량 이 약 100 만 위안 이 므 로 표 분 구 방안 을 사용 하고 매일 한 분 구 를 사용한다.
다음은 이 시계의 DDL 입 니 다.

CREATE TABLE `t1` (
 `id` bigint(20) NOT NULL AUTO_INCREMENT,
 `date` date NOT NULL,
 `kid` int(11) DEFAULT '0',
 `uid` int(11) NOT NULL,
 `iid` int(11) DEFAULT '0',
 `icnt` int(8) DEFAULT '0',
 `tst` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 `countp` smallint(11) DEFAULT '1',
 `isr` int(2) NOT NULL DEFAULT '0',
 `clv` int(5) NOT NULL DEFAULT '1'，
 PRIMARY KEY (`id`,`date`),
 UNIQUE KEY `date` (`date`,`uid`,`iid`),
 KEY `date_2` (`date`,`kid`)
) ENGINE=InnoDB AUTO_INCREMENT=3180686682 DEFAULT CHARSET=utf8mb4
/*!50500 PARTITION BY RANGE COLUMNS(`date`)
(PARTITION p20161201 VALUES LESS THAN ('2016-12-02') ENGINE = InnoDB,
 PARTITION p20161202 VALUES LESS THAN ('2016-12-03') ENGINE = InnoDB,
 PARTITION p20161203 VALUES LESS THAN ('2016-12-04') ENGINE = InnoDB,

이 표 에 서 는 아래 의 느 린 조회 가 자주 발생 합 니 다.

SELECT ... FROM `t1` WHERE `date` = '2017-04-01' AND `icnt` > 300 AND `id` = '801301';

SQL 최적화 의 길
SQL 최적화 사고방식
SQL 을 최적화 하려 면 일반적으로 실행 계획 을 살 펴 보고 가능 한 한 색인 을 사용 하 는 지 살 펴 보 는 동시에 스 캔 할 줄 수 와 임시 표(Using temporary)가 생 겼 는 지,정렬 이 필요 한 지(Using filesort)를 살 펴 보고 이 를 없 앨 방법 을 강구 해 야 합 니 다.
더욱 진일보 한 최적화 전략 은 프로그램 코드 논 리 를 조정 해 야 할 수도 있 고 심지어 기술 구조 나 업무 수 요 를 조정 해 야 할 수도 있다.이 동작 은 비교적 크다.보통 비 핵심 시스템 의 핵심 문 제 는 이렇게 크게 싸 우지 않 는 다.절대 다수의 상황 은 DBA 가 가능 한 한 지혜 를 발휘 하여 해결 해 야 한다.
SQL 성능 병목 포 지 셔 닝
이제 이 SQL 의 실행 계획 을 살 펴 보 겠 습 니 다.

[email protected][myDB]> EXPLAIN PARTITIONS SELECT ... FROM `t1` WHERE 
 `date` = '2017-03-02' AND `icnt` > 100 AND `iid` = '502302'\G
*************************** 1. row ***************************
   id: 1
 select_type: SIMPLE
  table: t1
 partitions: p20170302
   type: range
possible_keys: date,date_2
   key: date
  key_len: 3
   ref: const
   rows: 9384602
  Extra: Using where

이 실행 계획 은 보기 에는 괜 찮 은 것 같 습 니 다.색인 도 사용 할 수 있 고 임시 표 도 없고 filesort 도 없습니다.그러나 우 리 는 스 캔 할 줄 수가 매우 많 을 것 으로 예상 되 는 rows:9384602,그리고 zheng 전체 파 티 션 의 모든 데 이 터 를 스 캔 하려 면 효율 이 높 지 않 고 항상 SLOW QUERY 라 는 것 을 알 게 되 었 다.
사 고 를 최적화 하 다.
우 리 는 이 SQL 이 항상 어느 날 의 데 이 터 를 조회 해 야 한 다 는 것 을 알 게 되 었 습 니 다.이 시 계 는 이미 하늘 에 따라 구분 되 었 습 니 다.그러면 WHERE 자구 의 시간 조건 을 무시 할 수 있 습 니까?
그리고 데이트 조건 을 없 앴 으 니 반 관 표 DDL,나머지 조건 은 마땅 한 색인 이 없 는 것 같 죠?
그래서 우 리 는 색인 을 새로 만 들 려 고 시도 합 니 다.

[email protected][myDB]> ALTER TABLE t1 ADD INDEX iid (iid, icnt);

그리고 SQL 을 다음 과 같이 바 꾸 고 실행 계획 을 살 펴 보 세 요.

[email protected][myDB]> EXPLAIN PARTITIONS SELECT ... FROM `t1` partition(p2017030) WHERE 
 `icnt` > 100 AND `iid` = '502302'\G
*************************** 1. row ***************************
   id: 1
 select_type: SIMPLE
  table: t1
 partitions: p20170302
   type: ref
possible_keys: date,date_2,iid
   key: iid
  key_len: 10
   ref: const
   rows: 7800
  Extra: Using where
     ，   。

   ，           ，           ：

[email protected][myDB]> EXPLAIN PARTITIONS SELECT ... FROM `t1` WHERE 
 `date` = '2017-03-02' AND `icnt` > 100 AND `iid` = '502302'\G
*************************** 1. row ***************************
   id: 1
 select_type: SIMPLE
  table: t1
 partitions: p20170302
   type: ref
possible_keys: date,date_2,iid
   key: iid
  key_len: 10
   ref: NULL
   rows: 7800
  Extra: Using where

후기
절대 다수의 SQL 은 색인 을 추가 하고 SQL 코드 를 적당 하 게 조정 하 는 등 간단 한 기법 으로 이 루어 집 니 다.
몇 마디 더 하 자 면 SQL 최적화 성능 병목 문제 에 부 딪 혀 기술 군 에서 가르침 을 청 하려 면 먼저 몇 가지 필요 한 정 보 를 제공 해 야 한다.

표 DDL

표 일반적인 통계 정 보 는 SHOW TABLE STATUS LIKE't1'조회

를 실행 할 수 있 습 니 다.

표 색인 분포 정보,SHOW INDEX FROM t1 보기

실행 가능

문제 가 있 는 SQL 과 해당 하 는 실행 계획 에 이런 정보 가 없 으 면 다른 사람 을 귀 찮 게 하지 마 세 요.

이상 은 분 구 표 장면 에서 의 SQL 최적화 에 대한 상세 한 내용 입 니 다.sql 분 구 표 최적화 에 관 한 자 료 는 저희 의 다른 관련 글 을 주목 하 십시오!