mysql의 실행 계획은 무엇입니까

mysql에서 실행 계획은 SQL 문을 구문 분석, 분석 및 최적화하기 위해 데이터베이스가 사용자에게 제공하는 도구 집합입니다. 실행 계획의 기능은 다음과 같습니다. 1. 테이블 읽기 순서 표시 2. 데이터 읽기 작업 유형 표시 4. 실제로 사용되는 인덱스 표시 6. 각 테이블에서 쿼리된 행 수를 표시합니다.

이 튜토리얼의 운영 환경: windows7 시스템, mysql8 버전, Dell G3 컴퓨터.

데이터베이스를 쿼리할 때 우리는 일반적으로 필요한 데이터를 쿼리하기 위해 SQL 문을 사용합니다. 하지만 데이터베이스에서 SQL이 어떻게 실행되는지, 인덱스를 사용하는지, 어떤 인덱스를 사용하는지, 어떤 필드와 테이블을 검색하는지, 그 순서는 무엇인지, 얼마나 시간이 걸리는지 등은 알 수 없기 때문에 과연 어떤 것이 있을까? MySQL은 실행 계획이라는 도구 세트를 제공합니다.

1. 실행 계획이란 무엇입니까?

실행 계획은 SQL 문을 구문 분석하고 최적화하기 위해 데이터베이스에서 제공하는 도구 집합입니다.

• 테이블 읽기 시퀀스를 표시합니다. ;

• 데이터 읽기 작업 유형

• 사용할 수 있는 인덱스

• 테이블 간의 참조 관계; 쿼리된 행 각 테이블.

• 참고: 실행 계획은 SQL용 데이터베이스가 제공하는 최고의 최적화 참조 계획일 뿐 반드시 최적의 솔루션은 아닙니다. 즉,

  실행 계획을 너무 신뢰하지 마세요

• 2 . 실행 계획 사용법

사용 실행 계획은 매우 간단합니다. 실행할 SQL 앞에 explain 키워드만 추가하면 됩니다.

3. 실행 계획 정보

그림에서 볼 수 있듯이 SQL 실행 계획에는 주로 id, select_type, table, partitions, type, available_keys, key, key_len, ref, 행, 필터링됨, 추가.

3.1, id

쿼리 일련 번호를 선택하세요. id는 동일하고 실행 순서는 위에서 아래로 다릅니다. id 값이 클수록 우선 순위가 높을수록 빠릅니다.

3.2, select_type

select_type : 다음 값을 가질 수 있는 select 문의 종류를 나타냅니다.

SIMPLE : 연결 쿼리와 ⼦ 쿼리를 포함하지 않는 단순 쿼리를 나타냅니다. ;

PRIMARY: 기본 쿼리 또는 가장 외부 쿼리 문을 나타냅니다.

• UNION: 연결 쿼리의 두 번째 또는 후속 쿼리 문을 나타냅니다.

• DEPENDENT UNION: 두 번째 또는 후속 SELECT 문입니다. UNION에서는 외부 쿼리 쿼리에 따라 달라집니다.

• UNION RESULT: 조인 쿼리의 결과,

• SUBQUERY: ⼦쿼리의 첫 번째 SELECT 문,

• DEPENDENT SUBQUERY: ⼦첫 번째 SELECT 외부 쿼리에 따라 쿼리의 문;

• DERIVED: SELECT(FROM 절의 하위 쿼리).

3.3, table
table: 다음 상황에 있을 수 있는 쿼리의 테이블 이름을 나타냅니다.

테이블 이름을 표시합니다. 별칭이 제공되면 별칭이 표시됩니다. ;

< ;derivenN>: 쿼리 조건이 하위 쿼리임을 나타냅니다.

• : 테이블 1과 테이블 2가 공용체를 사용함을 나타냅니다.

3.4, partitions
partitions: 파티션 일치.

3.5, type

type: 이 열은 테이블 연결 유형 또는 액세스 유형을 나타냅니다. 즉, 데이터베이스는 테이블에서 행을 찾는 방법과 데이터 행 레코드의 대략적인 범위를 결정합니다. 최고부터 최악까지: system > const > range > index > all

system: const 유형인 시스템 테이블 특수 열은 일반적으로 표시되지 않으며 무시할 수 있습니다.

const: 한 데이터 행과 일치하는 인덱스를 통해 한 번 적중하므로 매우 빠르며 다음 쿼리에 자주 사용됩니다. PRIMARY KEY 또는 UNIQUE 인덱스인 경우 const가 최적화임을 이해할 수 있습니다.

• eq_ref: 고유 인덱스 스캔, 각 인덱스 키에 대해 테이블의 단 하나의 레코드만 일치하며, 일반적으로 사용되는 기본 키 또는 고유 인덱스 스캔입니다. const 외에 최고의 조인 유형일 수 있습니다.

• ref: 고유하지 않은 인덱스 스캔, =,

• 범위: 지정된 범위의 행만 검색하고, 인덱스를 사용하여 행을 선택합니다. 일반적으로 between, , in 등과 같은 쿼리에 사용됩니다. 이 범위 쿼리는 인덱스보다 낫습니다. 인덱스 한 지점을 스캔하고 다른 지점에서 끝납니다.

• index: 인덱스 트리를 순회해야 합니다.

• all: 즉, 데이터베이스가 필요한 것을 찾아야 함을 의미합니다. 시작부터 끝까지. 일반적으로 최적화를 위해 인덱스를 추가해야 합니다.

참고: SQL을 최적화할 때 최소한 범위로 최적화해야 하며 ref(바람직하게는 const)로 최적화하는 것이 좋습니다.

3.6, available_keys

possible_keys: 이 열은 쿼리 에서 찾기 위해 사용할 수 있는 인덱스 를 보여줍니다. 설명할 때 available_keys에 컬럼이 있는데 key에 NULL이 표시되는 경우가 있을 수 있는데, 이는 테이블에 데이터가 많지 않고 데이터베이스에서는 해당 인덱스가 이 쿼리에 도움이 되지 않는다고 판단하여 전체를 선택하기 때문입니다. 테이블 쿼리.
열이 NULL인 경우 관련 인덱스가 없습니다. 이 경우 where 절을 확인하여 적절한 인덱스를 생성하여 쿼리 성능을 향상시킬 수 있는지 확인한 후 explain을 사용하여 효과를 확인할 수 있습니다.

3.7, key

key: 실제로 데이터베이스에서 사용하기로 결정된 키(인덱스)를 표시합니다. 인덱스를 선택하지 않으면 키 값은 NULL입니다. 인덱스를 강제로 사용하거나 무시할 수 있습니다.

3.8, key_len

key_len: 이 열은 인덱스의 데이터베이스에서 사용되는 바이트 수를 표시합니다. 이 값을 통해 인덱스의 어떤 열이 구체적으로 사용되는지 계산할 수 있습니다.

문자열 유형
char(n): n 바이트 길이
varchar(n): 2바이트 저장 문자열 길이, utf-8인 경우 길이는 3n + 2

숫자 유형
tinyint: 1바이트
smallint: 2 바이트
int: 4바이트
bigint: 8바이트

시간 유형
날짜: 3바이트
timestamp: 4바이트
datetime: 8바이트

필드가 NULL을 허용하는 경우 NULL 여부를 기록하는 데 1바이트가 필요합니다

참고 : 최대 인덱스 길이는 768바이트입니다. 문자열이 너무 길면 데이터베이스는 왼쪽 접두사 인덱스와 유사한 프로세스를 수행하고 인덱스를 위해 문자의 첫 번째 절반을 추출합니다.

3.9, ref

ref: 이 열은 테이블이 키 열 레코드의 인덱스에서 값을 찾는 열 또는 상수 를 표시합니다. 일반적인 항목은 const(상수), func입니다. null , 필드 이름(예: film.id)

3.10,rows

rows: 이 열은 데이터베이스가 읽고 스캔할 것으로 추정하는 숫자입니다. . 따라서 값이 작을수록 좋습니다.

3.11,filtered

filtered: 결과로 반환된 행 수는 읽은 행 수의 백분율을 설명합니다

. 값이 클수록 좋습니다.

3.12, Extraextra: 이 열에는

추가 정보

, 즉 다른 열에 포함되지 않은 정보가 표시됩니다.

distinct: 데이터베이스가 발견한 정보입니다. 첫 번째 일치⾏ 이후에는 현재 행 조합에 대한 추가 행 검색을 중지합니다.
존재하지 않음: 데이터베이스는 쿼리에 대해 LEFT JOIN 최적화를 수행할 수 있으며 LEFT JOIN 표준과 일치하는 행이 발견되었습니다. 행 조합은 테이블에서 더 많은 행을 확인합니다.
각 레코드에 대해 확인된 범위(인덱스 맵: #): 데이터베이스가 사용할 수 있는 좋은 인덱스를 찾지 못했지만 이전 테이블 값이 알려져 있으며 일부 인덱스가 사용될 수 있습니다.
filesort(핵심 사항) 사용: 데이터베이스는 테이블에서 인덱스 순서로 행을 읽는 대신 외부 인덱스를 사용하여 결과를 정렬합니다. 이때 mysql은 연결 유형에 따라 적합한 모든 레코드를 찾아 정렬 키워드와 행 포인터를 저장한 다음 키워드를 정렬하고 행 정보를 순서대로 검색합니다. 이 경우 일반적으로
• 최적화를 위해

  인덱스 사용을 고려해야 합니다.

• 인덱스 사용(핵심): 실제 행을 읽기 위해 더 이상 검색하지 않고 인덱스 트리의 정보만 사용합니다. 테이블의 열 정보 검색

  select는 쿼리를 위해 테이블로 돌아갈 필요 없이 포함 인덱스를 사용

임시 사용(강조): 데이터베이스는
• 쿼리를 처리하기 위해 임시 테이블을 생성

  해야 하며, 이러한 상황은 일반적입니다. 정렬 기준 및 그룹 기준. 이런 일이 발생하면 일반적으로 최적화를 수행해야 합니다. 가장 먼저 해야 할 일은 인덱스를 사용하여

다음을 사용하는 것입니다. 스토리지 엔진이 행을 검색한 후 데이터베이스가 필터링됩니다. 즉, 전체 데이터를 먼저 읽은 후 where 조건에 따라 확인합니다. 일치하면 보관되고, 일치하지 않으면 삭제됩니다.
using index 조건: Using와 유사합니다. where, 쿼리된 열이 인덱스에 완전히 포함되지 않았고 where 조건이 선행 열의 범위입니다.
using sort_union(...), Union(...) 사용, intersect(.. .): 이 함수는 index_merge 조인 유형에 대한 인덱스 스캔을 병합하는 방법을 보여줍니다.

• group-by에 인덱스 사용: 테이블에 액세스하는 index 사용 방법과 유사하게, group-by에 인덱스를 사용한다는 것은 데이터베이스가 group by의 모든 열을 쿼리하거나 별도의 쿼리 없이 사용할 수 있는 인덱스를 찾았음을 의미합니다. 추가 실제 테이블에 액세스하기 위해 하드 디스크를 검색합니다.

• null: 쿼리된 열이 인덱스에 포함되지 않고 where 필터 조건이 인덱스의 선행 열이므로 인덱스가 사용되지만 일부 필드는 인덱스에 포함되지 않고 ""를 통해 테이블로 반환되어야 합니다. 이를 위해서는 인덱스를 순수하게 사용하지도 않고, 인덱스를 사용하더라도 테이블 반환 작업이 필요합니다. 테이블 반환 작업은 피해야 합니다.

【관련 추천: mysql 비디오 튜토리얼】

위 내용은 mysql의 실행 계획은 무엇입니까의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!