MySql - 데이터 전송 속도가 느림

MySql - 데이터 전송 속도가 느림

MySQL 5.0.45에 대한 쿼리 중 하나가 "데이터 전송" 단계에서 느리게 실행되고 있습니다.쿼리는 단순 선택이며, 결과 집합으로 약 300개의 정수 ID 필드를 반환합니다.

mysql> SELECT source_id FROM WHERE 방향 (destination_id = 10);+-----------+source_id |+-----------+|         2 ||         8 |...
|      2563 |+-----------+341줄의 세트(2.13초)

저는 "데이터 전송" 단계가 왜 이렇게 느리는지, 그리고 이를 빠르게 하기 위해 무엇을 할 수 있는지 잘 모르겠습니다.서버 자체의 MySQL 프롬프트에서 이 쿼리를 실행하므로 "데이터 전송"에 많은 시간이 소요될 것으로 예상하지 않습니다.단서는?

도움이 된다면, 이 표에 텍스트 필드가 3개 있는데, 선택이 안 되고 있기 때문에 이 속도 저하의 원인이 아닐 것으로 예상됩니다.

이 쿼리는 하루에 수천 번 실행되며 매번 2초를 할애할 여유가 없습니다.

프로파일링 결과:

mysql> 쿼리 4에 대한 프로필 표시;+--------------------------------+----------+상태 | 기간 |+--------------------------------+----------+(초기화) | 0.000003 |쿼리 캐시에서 쿼리 확인 | 0.000051 |권한 확인 | 0.000007 |테이블 열기 | 0.000011 |시스템 잠금 | 0.000005 |테이블 잠금 | 0.000023 |안에| 0.00002  |최적화 | 0.00001 |통계 | 0.00006 |준비 | 0.000014 |실행 | 0.000005 |데이터 전송 | 2.127019 |종료 | 0.000015 |query end | 0.000004 |쿼리 캐시에 결과 저장 | 0.000039 |항목 해제 | 0.000011 |마감 테이블 | 0.000007 |로깅 느린 쿼리 | 0.000047 |+--------------------------------+----------+세트에 18개 행(0.00초)

업데이트: 다음 URL을 발견했습니다.

각 시간은 이전 이벤트와 새 이벤트 사이에 경과한 시간을 의미합니다.자, 다음과 같은 대사가 있습니다.
데이터 전송 | 0.00016800 |
는 "실행"과 "데이터 전송" 사이에 0.00016800초가 경과했음을 의미합니다.즉, 쿼리를 실행하는 데 0.00016800초가 걸립니다.

http://forums.mysql.com/read.php?24,241461,242012#msg-242012

누가 확인해 줄 수 있나요?

일반적으로 느린 쿼리가 있을 때마다 설명 계획을 시작하는 것이 가장 좋습니다.하나를 얻으려면, 실행

DESCRIBE SELECT source_id FROM directions WHERE (destination_id = 10);

쿼리를 실행하는 데 필요한 단계를 나열하는 표가 표시됩니다.'rows' 열에 큰 값이 표시되고 'key' 열에 NULL이 표시되면 쿼리가 반환할 행을 결정하기 위해 많은 행을 검색해야 함을 나타냅니다.

이 경우 destination_id에 인덱스를 추가하면 삽입 및 삭제 속도가 다소 빨라집니다(인덱스도 업데이트해야 하므로).

저도 같은 문제가 있었습니다.데이터 전송 속도가 매우 느렸지만 인덱스가 정확했습니다.

한참을 뒤적인 끝에, 나는 나의 것을 발견했습니다.join인덱스된 두 필드(하나는 latin1_swedish_ci이고 다른 하나는 uft8_general_ci)를 비교하고 있었습니다.

두 가지를 모두 utf8로 전송하면 쿼리 속도가 상당히 빨라집니다(2.7초에서 0.002초로).

아마도 mysql 서버의 하드웨어 부분을 볼 수 있을 것입니다.Mysql 문서에 따르면:

데이터 전송

스레드는 SELECT 문에 대한 행을 읽고 처리하며 클라이언트에 데이터를 전송합니다.이 상태에서 발생하는 작업은 많은 양의 디스크 액세스(읽기)를 수행하는 경향이 있기 때문에 해당 쿼리의 수명 동안 가장 오래 실행되는 상태인 경우가 많습니다.

따라서 대용량 db/table 파일 또는 비활성화된 tableperfile InnoDB 옵션/fragment화/잘못 구성된 RAID/디스크 충돌 프로세스 시작(곧 디스크 삭제 대기)/기타 디스크 I/O 속도 저하의 이유로 인해 서버의 디스크 I/O 속도가 느려진 경우, 이 단계에서 모든 요청을 수집하는 서버의 "데이터 전송" 단계가 크게 증가한 것이 원인일 수 있습니다.d 데이터를 디스크에서 클라이언트로 보냅니다.

물론 인덱스를 먼저 사용하도록 선택을 최적화하고 대부분의 경우 이 단계 시간에 영향을 미치므로 프로그래밍 문제가 아닌지 확인해야 합니다.

프로파일링은, 제 생각에, 쓸모가 없습니다."데이터 전송"과 같은 잘못된 범주가 있지만 도움이 되지 않습니다.

SELECT source_id FROM directions
    WHERE (destination_id = 10);

의 혜택을 받을 것입니다

INDEX(destination_id, source_id)

(그 순서대로).한편, 드롭INDEX(destination_id)이 인덱스는 이러한 요구를 처리하기 때문입니다.이 인덱스는 "포함 인덱스"입니다.

MySQL 5.5.x에서 5.7.x로 이동한 후에 경험했습니다. MySQL 5.5에서는 join을 사용한 쿼리가 빨랐고 MySQL 5.7에서는 정말 느렸습니다.

문제는 MySQL 5.7이 MySQL 5.5보다 다른 인덱스 집합을 선택했다는 것입니다.

USE INDEX를 추가하여 문제를 해결했습니다.

두 개의 색인이 있었습니다.date_index그리고.id) ,

가지고 있었습니다WHERE date_index>NOW() - INTERVAL 24 HOURS 리고그.ORDER BY id은 MySql을 선호했습니다.idtables.하지 않아 .

저는 5년 후에 테이블이 성장한 레거시 시스템에서 그것을 발견했습니다.

느린 "데이터 전송"에도 같은 문제가 있었습니다.제 경우에는 조인된 테이블에 쿼리에 사용되지도 않은 외부 키가 누락되었습니다.외부 키를 추가한 것이 저를 위해 고쳐주었습니다.

쿼리는 쿼리를 실행하는 데 2.127019를 사용합니다.이는 데이터 양이 많고 destination_id 열에 인덱스가 없기 때문일 수 있습니다.시도:

CREATE INDEX index_destination_id ON 방향(destination_id);

그러면 요청이 원활하게 실행될 것입니다.

언급URL : https://stackoverflow.com/questions/863447/mysql-slow-sending-data-phase