아리 면접 진제: 느린 SQL 최적화 사고방식

사실 이것은 흔히 볼 수 있는 면접 문제다.
1. 지식 포인트1: 실행 계획: 구체적인 매개 변수는 다음과 같다.https://segmentfault.com/a/1190000008131735
열의 의미는 다음과 같습니다.

id: SELECT 질의의 식별자입니다.각 SELECT에는 고유한 식별자가 자동으로 지정됩니다.

select_type: SELECT 질의의 유형입니다.

table: 조회한 표는 어느 표입니까?

partitions: 일치하는 파티션

type:join 유형

possible_keys: 이번 검색에서 사용할 수 있는 인덱스

key: 이번 검색에서 정확하게 사용된 인덱스.

ref: 키와 함께 사용할 필드나 상수

rows: 이 검색어가 모두 몇 줄을 스캔했는지 보여 줍니다.이것은 추정치이다.

Filtered: 이 쿼리 조건에 의해 필터된 데이터의 백분율

extra: 추가 정보

중점을 두는 몇 개의 필드:
type type 필드는 비교적 중요하고 조회가 효율적인지 판단하는 중요한 근거를 제공한다.type 필드를 통해 이번 조회가 인지 인지 판단합니다.
type 일반 유형
type에서 일반적으로 사용되는 값은 다음과 같습니다.

system: 표에 데이터가 하나밖에 없습니다.이 유형은 특수한 const 유형입니다.

const: 메인 키나 유일한 인덱스에 대한 등치 조회 스캔으로 최대 한 줄의 데이터만 되돌려줍니다.const 조회 속도가 매우 빠릅니다. 왜냐하면 그것은 단지 한 번만 읽으면 되기 때문입니다.예를 들어 아래의 이 조회는 메인 키 인덱스를 사용했기 때문에 type은 const 유형이다.

eq_ref: 이 유형은 보통 여러 표의join 조회에 나타나는데 앞표의 모든 결과에 대해 뒷표의 한 줄의 결과만 일치할 수 있음을 나타낸다.또한 조회의 비교 조작은 보통 =으로 조회 효율이 비교적 높다.예:

ref: 이 유형은 보통 다중 테이블에 나타나는join 조회입니다. 유일하거나 비키 인덱스나 규칙 인덱스를 사용한 조회입니다.

range: 색인 범위 조회를 사용하고 색인 필드 범위를 통해 표의 일부 데이터 기록을 얻습니다.이 유형은 보통 =, <, >, > =, BETWEEN, IN () 작업에 나타납니다.type이 range일 때 EXPLAIN이 출력한 ref 필드는 NULL이고 key_len 필드는 이번 검색에서 사용된 인덱스의 가장 긴 필드이다.

index: 전체 인덱스 스캔(full index scan)을 나타낸다. ALL 형식과 유사하지만 ALL 형식은 전체 테이블 스캔이고 index 형식은 모든 인덱스만 스캔하고 데이터는 스캔하지 않는다.index 유형은 보통 다음과 같다. 검색할 데이터는 색인 트리에서 직접 얻을 수 있고 스캔할 필요가 없다.이 경우 Extra 필드에는 Using index이 표시됩니다.

All: 전체 테이블 스캔을 나타냅니다. 이 유형의 검색은 성능이 가장 나쁜 검색 중 하나입니다.일반적으로 우리의 조회는 ALL 유형의 조회가 나타나서는 안 된다. 왜냐하면 이런 조회는 데이터량이 많은 상황에서 데이터베이스의 성능에 커다란 재난이기 때문이다.만약 하나의 조회가 ALL 형식의 조회라면 일반적으로 상응하는 필드에 색인을 추가하여 피할 수 있다.

일반적으로 서로 다른 type 유형의 성능 관계는 다음과 같다.

ALL < index < range ~ index_merge < ref < eq_ref < const < system ALL 유형은 전체 테이블 스캔이기 때문에 같은 검색 조건에서 속도가 가장 느리다.index 유형의 검색은 전체 테이블 검색은 아니지만 모든 인덱스를 검색하기 때문에 ALL 형식보다 조금 빠르다.뒤의 몇 가지 유형은 모두 색인을 이용하여 데이터를 조회하기 때문에 부분이나 대부분의 데이터를 여과할 수 있기 때문에 조회 효율이 비교적 높다.

possible_keys possible_keys은 MySQL이 검색할 때 사용할 수 있는 인덱스를 나타낸다.비록 일부 인덱스가 possible_keys에 나타나더라도, 이 인덱스가 MySQL에 실제로 사용된다는 것은 아니다.MySQL이 검색할 때 어떤 인덱스를 사용했는지 key 필드에 의해 결정됩니다.
key
이 필드는 현재 질의에서 MySQL이 실제로 사용하는 인덱스입니다.
key_len
검색 최적화기가 색인을 사용한 바이트 수를 표시합니다.이 필드는 조합 인덱스가 완전히 사용되었는지, 아니면 맨 왼쪽 필드만 사용되었는지 평가할 수 있습니다.key_len의 계산 규칙은 다음과 같습니다.

문자열

char(n): n 바이트 길이

varchar(n):utf8 인코딩이면 3n+2 바이트;utf8mb4 인코딩이면 4 n + 2 바이트입니다.

수치 유형:

TINT: 1바이트

SMALLINT: 2바이트

MEDIUMINT: 3바이트

INT: 4바이트

BIGINT: 8바이트

시간 유형

DATE: 3바이트

TIMESTAMP: 4바이트

DATETIME: 8바이트

필드 속성: NULL 속성은 1바이트를 차지합니다.필드가 NOT NULL이면 이 속성이 없습니다.

rows
rows도 중요한 필드입니다.MySQL 조회 최적화기는 통계 정보에 근거하여 SQL이 결과 집합을 찾으려면 스캔해서 읽어야 할 데이터 줄 수를 추산한다.이 값은 SQL의 효율의 좋고 나쁨을 매우 직관적으로 나타낸다. 원칙적으로rows는 적을수록 좋다.
Extra
EXplain의 많은 추가 정보는 Extra 필드에 표시되며 일반적으로 다음과 같은 항목이 있습니다.

Using filesort Extra에 Using filesort이 있을 경우 MySQL은 추가 정렬 작업이 필요하며 색인 순서를 통해 정렬 효과에 도달할 수 없습니다.일반적으로 Using filesort이 있는데 모두 최적화를 권장하는데 이런 조회 CPU 자원의 소모가 크기 때문이다.

Using index "인덱스 검색 덮어쓰기"는 인덱스 트리에서 필요한 데이터를 검색할 수 있음을 의미하며, 테이블 데이터 파일을 검색하지 않아도 성능이 좋다는

Using temporary 조회는 임시 테이블을 사용하는데 주로 정렬, 그룹 구성과 다중 테이블join의 경우 조회 효율이 높지 않기 때문에 최적화를 권장합니다.

중점: 만약 sql 문장 최적화가 느린 SQL을 해결할 수 없다면 어떻게 해야 합니까?