1. 최적화의 아이디어와 원칙은 무엇입니까
1. 최적화가 필요한 쿼리를 최적화합니다
2. 최적화 개체의 성능 병목 지점을 찾습니다
3. 최적화 목표를 명확히 합니다
4. 시작합니다. 설명
5. 프로필을 더 많이 사용하세요
6. 큰 결과 세트를 구동하려면 항상 작은 결과 세트를 사용하세요
7. 인덱스 정렬을 최대한 완료하세요
8. 필요한 필드(열)만 빼세요
9. 오직 사용하세요 가장 효과적인 필터링 조건
10. 복잡한 조인을 최대한 피하세요
관련 무료 학습 권장 사항: mysql 비디오 튜토리얼
1. 최적화가 필요한 쿼리 최적화
높은 동시성 및 낮은 소비 ( 상대적으로) 쿼리는 전체 시스템에 영향을 미칩니다. 동시성이 낮고 사용량이 많은 쿼리보다 훨씬 큽니다.
2. 최적화 개체의 성능 병목 현상을 찾습니다
최적화가 필요한 쿼리를 받으면 먼저 쿼리의 병목 현상이 IO인지 CPU인지 확인해야 합니다. 더 많은 것을 소비하는 것이 데이터베이스 액세스입니까, 아니면 더 많은 것을 소비하는 데이터 작업(예: 그룹화 및 정렬)입니까?
3. 명확한 최적화 목표
데이터베이스의 현재 전반적인 상태를 이해하면 데이터베이스가 견딜 수 있는 최대 압력, 즉 가장 비관적인 상황을 알 수 있습니다.
관련 데이터베이스 개체 정보를 파악합니다. 쿼리에 대해 우리는 최상의 조건과 최악의 조건에서 얼마나 많은 리소스가 소비되는지 알 수 있습니다.
응용 시스템에서 쿼리의 상태를 알기 위해 쿼리가 점유할 수 있는 시스템 리소스의 비율을 분석할 수 있습니다. 또한 고객 경험에 대한 쿼리의 효율성이 얼마나 큰 영향을 미치는지 알 수 있습니다.
4. 시작하기
Explain은 이 쿼리가 데이터베이스에 어떤 종류의 실행 계획을 구현하는지 알려줍니다. 우선 목표를 가지고 끊임없이 조정하고 노력한 다음, 설명을 사용하여 결과가 우리의 요구 사항을 충족하는지 확인하면 예상한 결과를 얻을 수 있습니다.
5. 큰 결과 세트를 구동하려면 항상 작은 결과 세트를 사용하세요.
많은 사람들은 SQL을 최적화할 때 "작은 테이블이 큰 테이블을 구동합니다"라고 말하고 싶어합니다. where 조건에 의해 필터링된 후 대형 테이블에서 반환된 결과 집합이 반드시 소형 테이블에서 반환된 결과 집합보다 클 필요는 없으므로, 이때 소형 테이블을 구동하기 위해 대형 테이블을 사용하면 반대의 성능 효과가 발생합니다. 얻을 수 있습니다.
이 결과도 MySQL에는 Nested Loop라는 Join 메소드가 하나만 존재합니다. 즉, MySQL의 Join은 중첩 루프를 통해 구현됩니다. 구동된 결과 집합이 클수록 더 많은 루프가 필요하며 구동 테이블에 액세스할 때마다 필요한 논리적 IO가 매우 작더라도 루프 수가 자연스럽게 늘어납니다. 당연히 총량이 아주 작을 수는 없고, 각 사이클마다 CPU를 소모하게 되므로 CPU 계산량도 늘어나게 됩니다. 따라서 구동 테이블을 판단하는 기준으로 테이블의 크기만 사용한다면, 작은 테이블을 필터링한 후 남겨진 결과 집합이 큰 테이블의 결과보다 훨씬 클 경우 결과는 필수 중첩에서 더 많은 루프가 될 것입니다. 반대로, 필요한 사이클 수가 줄어들고 전체 IO 및 CPU 작업량도 줄어듭니다. 더욱이 Oracle의 Hash Join과 같은 비Nested Loop Join 알고리즘의 경우에도 여전히 큰 결과 집합을 구동하기 위한 작은 결과 집합에 대한 최적의 선택입니다.
따라서 조인 쿼리를 최적화할 때 가장 기본적인 원칙은 "작은 결과 세트가 큰 결과 세트를 구동한다"입니다. 이 원칙을 통해 중첩 루프의 루프 수를 줄이고 총 IO 양과 CPU 작업 수를 줄일 수 있습니다. . 가능한 한 많이 인덱스 정렬을 완료하세요
6. 필요한 필드(열)만 꺼내세요
모든 쿼리에 대해 반환된 데이터는 네트워크 데이터 패킷을 통해 클라이언트에 전송되어야 합니다. 꺼내면 전송해야 하는 데이터의 양이 자연스럽게 늘어나는데, 이는 네트워크 대역폭이나 네트워크 전송 버퍼 측면에서 볼 때 낭비입니다.
7. 가장 효과적인 필터링 조건만 사용하세요.
예를 들어 사용자 테이블에는 id 및 nick_name과 같은 필드가 있습니다. 다음은 두 개의 쿼리 문입니다.
#1 select * from user where id = 1 and nick_name = 'zs'; #2 selet * from user where id = 1
결과는 다음과 같습니다. 동일하지만 첫 번째 문에서 사용하는 인덱스가 두 번째 문보다 훨씬 더 많은 공간을 차지합니다. 더 많은 공간을 차지한다는 것은 더 많은 데이터를 읽어야 한다는 의미이기도 합니다. 즉, 2의 질의문이 최적의 질의이다.
8. 복잡한 조인 쿼리 방지
쿼리에 포함되는 테이블이 많을수록 잠가야 하는 리소스도 많아집니다. 즉, Join 문이 복잡할수록 잠그는 데 필요한 리소스가 늘어나고 차단하는 다른 스레드도 많아집니다. 반대로, 더 복잡한 쿼리 문을 여러 개의 간단한 쿼리 문으로 분할하고 단계별로 실행하면 매번 잠기는 리소스가 줄어들고 차단되는 다른 스레드도 줄어듭니다.
많은 사람들이 질문을 할 수 있습니다. 복잡한 Join 문을 여러 개의 간단한 쿼리 문으로 분할하면 더 많은 네트워크 상호 작용이 발생하지 않을까요? 전체 쿼리를 완료하는 데 시간이 더 오래 걸리지 않습니까? 예, 가능하지만 확실하지는 않습니다. 복잡한 쿼리문이 실행될 때 더 많은 리소스를 잠궈야 하고, 간단한 쿼리라면 잠궈야 할 리소스가 적기 때문에 다른 사람에 의해 차단될 확률이 더 높습니다. 차단될 확률도 훨씬 낮아집니다. 따라서 더 복잡한 연결 쿼리는 실행 전에 차단되어 더 많은 시간을 낭비할 수 있습니다. 더욱이, 우리 데이터베이스는 이 쿼리 요청뿐만 아니라 수많은 다른 요청도 처리합니다. 동시성이 높은 시스템에서는 전체 처리 능력을 향상시키기 위해 단일 쿼리의 짧은 응답 시간을 희생하는 것이 매우 가치가 있습니다. 최적화 자체는 균형과 절충의 기술입니다. 절충점을 알고 전체의 균형을 유지해야만 시스템이 더 좋아질 수 있습니다.
2. 설명 및 프로파일링 사용
1. 설명은
다양한 정보 표시
설명 | |
---|---|
실행 계획서에서 문의한 일련번호 | |
쿼리 유형: | DEPENDENT SUBQUERY: 외부 쿼리 결과 집합에 따라 달라지는 하위 쿼리 내부 레이어의 첫 번째 SELECT DEPENDENT UNION: 두 번째부터 시작하는 하위 쿼리의 UNION에 있는 모든 후속 SELECT SELECT SELECT는 외부 쿼리 결과 집합에 따라 달라집니다. PRIMARY: 기본 키 쿼리가 아닌 하위 쿼리의 가장 바깥쪽 쿼리입니다. SUBQUERY: 하위 쿼리의 내부 쿼리 중 첫 번째 SELECT이며 결과는 외부 쿼리에 종속되지 않습니다. UNCACHEABLE SUBQUERY: 결과 세트를 캐시할 수 없는 하위 쿼리 UNION: UNION 문의 두 번째 SELECT에서 시작하는 모든 SELECT, 첫 번째 SELECT는 PRIMARY입니다. UNION RESULT: UNION의 병합된 결과 |
액세스됨 데이터베이스의 테이블 이름 | |
액세스 방법: | ALL: 전체 테이블 스캔 const: 상수, 최대 하나의 레코드만 일치합니다. 상수이므로 실제로는 읽기만 하면 됩니다. 한 번 eq_ref: 최대 1개만 일치합니다. 결과는 일반적으로 기본 키 또는 고유 인덱스로 액세스됩니다. 인덱스: 전체 인덱스 스캔 범위: 인덱스 범위 스캔 ref: jion 문 시스템에서 구동 테이블 인덱스의 참조 쿼리 : 시스템 테이블, 테이블에 데이터 행이 하나만 있습니다 |
사용 가능한 인덱스 | |
사용된 인덱스 | |
인덱스 길이 | |
The 예상 결과 세트 레코드 수 | |
추가 정보 |
위 내용은 MySQL 쿼리 최적화에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!