MySQL Sending data 조회 가 느 린 문 제 를 깊이 분석 하 다.

하나의 인 스 턴 스 를 통 해 MySQL Sending data 표 조회 느 린 문제 해결 방법 을 공유 하 였 습 니 다.
최근 코드 최적화 에서 sql 문구 가 매우 느 린 것 을 발견 하여 여러 가지 방법 으로 검 사 를 한 끝 에 원인 을 찾 았 다.
사고 현장

SELECT og.goods_barcode, og.color_id, og.size_id, SUM(og.goods_number) AS sold_number FROM order o 
LEFT JOIN order_goods og ON o.order_id = og.order_id WHERE o.is_send = 0 AND o.shipping_status = 0 
AND o.create_time > '2017-10-10 00:00:00' AND o.ck_id = 1 AND og.goods_id = 13421 AND o.is_separate = 1 AND o.order_status IN (0, 1) AND og.is_separate = 1 
GROUP BY og.color_id, og.size_id

위의 이 문 구 는 연결 표 그룹 조회 문 이다.
실행 결과:

우 리 는 이 문 구 는1.300초 를 썼 고Sending data는1.28초 를 써 서 99%에 가 까 운 시간 을 차 지 했 기 때문에 우 리 는 이것 을 최적화 시 켰 다.
어떻게 최적화 할 까요?
2.SQL 구문 분석 스 리 스트로크 도끼
1.explain 분석
위의 문장 에 대해explain분석:

explain SELECT og.goods_barcode, og.color_id, og.size_id, SUM(og.goods_number) AS sold_number FROM order o 
LEFT JOIN order_goods og ON o.order_id = og.order_id WHERE o.is_send = 0 AND o.shipping_status = 0 
AND o.create_time > '2017-10-10 00:00:00' AND o.ck_id = 1 AND og.goods_id = 13421 AND o.is_separate = 1 AND o.order_status IN (0, 1) AND og.is_separate = 1 
GROUP BY og.color_id, og.size_id

실행 결과:
explain을 통 해 우 리 는 위의 문 구 를 볼 수 있 고 색인key에 유용 하 다.
2、show processlist
explain 은 문제 가 보이 지 않 습 니 다.그것 은 도대체 어디 에 느 린 것 입 니까?
그래서 사용show processlist으로 sql 문장의 실행 상 태 를 볼 생각 이 났 습 니 다.조회 결 과 는 다음 과 같 습 니 다.

오랫동안 조 회 는'Sending data'상태 에 있 었 다.
'Sending data'상태의 의 미 를 조회 해 보 세 요.원래 이 상태의 이름 은 오도 성 이 있 습 니 다.이른바'Sending data'는 단순히 데 이 터 를 보 내 는 것 이 아니 라'수집+데이터 보 내기'를 포함 합 니 다.
여기 서 관건 은 왜 데 이 터 를 수집 하 느 냐 하 는 것 입 니 다.이 유 는 my sql 에서'색인'을 사용 하여 조회 가 끝 난 후에 my sql 은 한 무더기 의 줄 id 를 얻 었 습 니 다.만약 에 어떤 열 이 색인 에 있 지 않 으 면 my sql 은'데이터 줄'로 다시 읽 어서 클 라 이언 트 를 되 돌려 야 합 니 다.
3、show profile
조회 의 시간 분 포 를 더욱 검증 하기 위해show profile명령 을 사용 하여 상세 한 시간 분 포 를 보 았 다.
먼저 설정 열기:set profiling=on;
조 회 를 실행 한 후 show profiles 를 사용 하여 query id 를 봅 니 다.
show profile for query query 사용id 자세 한 정보 보기;
3.조사 최적화
1.조사 대비
상기 절 차 를 통 해 조회 가 느 린 것 은 Sending data 상태 에 많은 시간 이 걸 렸 기 때 문 이 라 고 확 정 했 습 니 다.Sending data 의 정 의 를 결합 하여 목 표를 조회 문장의 반환 열 에 초점 을 맞 추 었 습 니 다.
일일이 조사 한 결과 마지막 으로 description 의 열 로 정 해 졌 습 니 다.이 열 은descriptionvarchar(8000)DEFAULT NULL COMMENT'게임 설명'으로 디자인 되 었 습 니 다.
그래서'description 의 결 과 를 되 돌려 주지 않 는 다'는 비교 방법 을 채택 했다.show profile 의 결 과 는 다음 과 같 습 니 다.
[해결 방법]
문제 의 근본 원인 을 찾 으 면 해결 방법 도 어렵 지 않다.몇 가지 방법 이 있 습 니 다.
1)조회 시 description 의 조 회 를 삭제 하지만 이 는 업무 의 실현 에 국한 되 어 업무 의 비교적 큰 조정 이 필요 할 수 있다.
2)표 구조 가 최적화 되 어 descripion 을 다른 표 로 나 누 었 다.이 변경 은 비교적 크 고 기 존의 업무 협조 수정 이 필요 하 며 업무 가 이 description 의 정 보 를 계속 조회 하려 면 최적화 후의 성능 도 크게 향상 되 지 않 을 것 이다.