무슨 일이 생기면 당황하지 말고 먼저 기록하세요: 느린 쿼리 최적화의 mysql

이 기사에서는 mysql의 느린 쿼리 최적화 문제를 단계별로 분석하고 확인하고 최적화하는 데 도움이 되기를 바랍니다.

MySQL의 느린 쿼리 최적화를 기억하세요. 프로덕션 환경의 할 일 목록에 대한 실시간 데모에서 갑자기 결과를 로드하는 데 5~6초가 걸렸습니다. 다년간의 경험을 가진 개발자인 그는 젠장, 얼굴이 뺨을 때리고 있다고 생각했습니다.

하지만 무술계에서 다년간의 경험을 갖고 있기 때문에 무슨 일이 있어도 당황하지 말고 먼저 사진을 찍어 두세요.

추천 학습: "MySQL 동영상 튜토리얼"

첫 번째 단계, SQL 분석

 ***from event i 
 left join project p on i.project_id = p.project_code 
 left join dict d on i.type_id = d.id 
 left join record re on re.incident_id = i.id
 left join type it on it.id = i.type_id 
 where i.version_flag = 0 and i.flow_id in (大量条件)***复制代码

flow_id가 많은 조건에 연결되면 SQL이 이전 80ms에서 5.8초로 직접적으로 느려집니다. 그 외에도 여기에는 관련 테이블이 많이 있습니다.

두 번째 단계, 인덱스를 확인하고 explain을 실행합니다

인덱스를 확인하고 re.incident_id와 i.flow_id가 인덱싱되지 않은 것을 발견하면 매우 기쁩니다. 문제가 발견되면 인덱스를 구축합니다. 그러나 SQL을 실행하면 오류가 없음을 알 수 있습니다. 똑똑한 나로서는 직접 explain을 열어보니 레코드 종류가 all로 되어 있어 index가 없다는 것을 알 수 있었다.

왜?왜?

세 번째 단계는 관련된 두 필드의 필드 유형, 길이, 문자 유형이 일치하는지 확인하는 것입니다.

필드 유형과 필드 길이를 비교해 보면 완전히 일치하는 것으로 나타났습니다. 짧은 우울증 끝에 새로운 것을 발견했습니다.

이벤트 테이블의 id 문자 유형은

기록 테이블의 event_id 문자 유형은

입니다.

프로젝트 팀과의 단결을 유지하기 위해 단호하고 균일하게 utf8mb4를 사용합니다. 다시 설명하자면, 손으로 하면 1초도 안 걸립니다.

네 번째 단계는 인덱스 작업을 강제로 사용하는 것입니다.

mysql은 테이블의 인덱스 기반이 너무 작을 경우 기본적으로 전체 텍스트 검색을 수행합니다. 따라서 테이블의 비즈니스 볼륨이 너무 큽니다. 그러나 인덱스 필드는 기본적으로 동일합니다. 데이터 또는 null의 경우에도 sql에서 강제 인덱스를 작성해야 합니다. sql에서 강제 인덱스 솔루션을 사용하고 왼쪽 조인 후에 강제 인덱스(alarm_id)를 추가해야 합니다. 다섯 번째 단계 IN은 일반적으로 IN 뒤에 있는 데이터가 데이터 테이블에서

30%

이상 일치하는 경우에만 인덱스의

을 스캔합니다. 따라서 IN이 인덱스를 사용하는지 여부는 다음과 같습니다. 인덱스는 그 뒤에 있는 데이터의 양과 관련이 있습니다. Left Join을 이용하면 많은 양의 데이터를 처리할 수 있다.

위 내용은 무슨 일이 생기면 당황하지 말고 먼저 기록하세요: 느린 쿼리 최적화의 mysql의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!