2016-07-22 8 views
0

사용자가 정기적으로 실행하는 클라이언트 목록의 출력을 담당하는 쿼리가 있습니다.PHPMyAdmin에서 mysql-slow-log의 MySQL 쿼리가 느려지지 않는 이유는 무엇입니까?

쿼리는 : 그것은 정기적으로 유사 MySQL의 느린 쿼리 로그에 기록됩니다

SELECT SQL_CALC_FOUND_ROWS p.lname, p.fname, p.patronymic, p.job, 
     p.post, p.zip, p.city, p.address, p.id, p.additional, 
     p.people_type_id, p.gender, p.permissions, p.user_id, 
     p.user_id, p.grading, p.progress, p.full_name, p.b1a, 
     p.b1b, p.b1c, p.b2a, p.b2b, p.b2c, p.b3a, p.b3b, p.b3c, 
     p.b4a, p.b4b, p.b4c, p.b5a, p.b5b, p.b5c, p.b6a, p.b6b, 
     p.b6c, p.b7a, p.b7b, p.b7c, p.b8a, p.b8b, p.b8c, p.b9a, 
     p.b9b, p.b9c, p.b10a, p.b10b, p.b10c, p.b11a, p.b11b, 
     p.b11c, p.b12a, p.b12b, p.b12c, p.b13a, p.b13b, p.b13c, 
     p.b14a, p.b14b, p.b14c, p.b15a, p.b15b, p.b15c, p.b16a, 
     p.b16b, p.b16c, p.b17a, p.b17b, p.count, p.finish_count, 
     p.partyId, t.description, a.description, p.contact_through, 
     DATE_FORMAT(p.next_call, '%d-%m-%Y') as next_call, p.recruiter, 
     p.b17c, p.l1a, p.l1b, p.l1c, p.l2a, p.l2b, p.l2c, p.l3a, 
     p.l3b, p.l3c, p.l4a, p.l4b, p.l4c, p.l5a, p.l5b, p.l5c, 
     p.l6a, p.l6b, p.l6c, p.l7a, p.l7b, p.l7c, p.l8a, p.l8b, 
     p.l8c, p.l9a, p.l9b, p.l9c, p.l10a, p.l10b, p.l10c, p.l11a, 
     p.l11b, p.l11c, p.l12a, p.l12b, p.l12c, p.l13a, p.l13b, 
     p.l13c, p.l14a, p.l14b, p.l14c, p.c1a, p.c1b, p.c1c, p.c2a, 
     p.c2b, p.c2c, p.c3a, p.c3b, p.c3c, p.c4a, p.c4b, p.c4c, 
     p.c5a, p.c5b, p.c5c, p.c6a, p.c6b, p.c6c, p.c7a, p.c7b, 
     p.c7c, p.c8a, p.c8b, p.c8c, p.c9a, p.c9b, p.c9c, p.c10a, 
     p.c10b, p.c10c, p.c11a, p.c11b, p.c11c, p.c12a, p.c12b, 
     p.c12c, p.c13a, p.c13b, p.c13c, p.c14a, p.c14b, p.c14c, 
     p.c15a, p.c15b, p.c15c, p.c16a, p.c16b, p.c16c, p.c17a, 
     p.c17b, p.c17c, p.c18a, p.c18b, p.c18c, p.c19a, p.c19b, 
     p.c19c, p.c20a, p.c20b, p.c20c, p.c21a, p.c21b, p.c21c 
    FROM people p 
    JOIN people_progress_id a ON p.progress = a.proc_level_id 
    JOIN people_grading_id t ON p.grading = t.grading_level_id 
    WHERE p.category=3 
     and p.status = 1 
    ORDER BY p.city desc 
    LIMIT 0, 50; 

:

# Time: 160718 17:18:32 
# [email protected]: server[server] @ localhost [] 
# Query_time: 4.098162 Lock_time: 0.000255 Rows_sent: 50 Rows_examined: 1508127 
SET timestamp=1468851512; 
SELECT SQL_CALC_FOUND_ROWS p.lname... 

을하지만 phpMyAdmin을이를 실행할 때 실행 시간 미만 초. 이것이 일어나는 이유가 있습니까? 그리고 어떻게하면 속도를 높일 수 있습니까?

+1

캐시됩니다. 캐시에서 결과를 얻는다면 많은 작업이 필요 없으며 매우 빨리 실행됩니다. 이 현상은 PHPMyAdmin과 관련이 없습니다. 쿼리를 실행 한 다음 PHPMyAdmin을 사용하여 같은 쿼리를 실행했습니다. 그러나 두 번째로 실행되면 캐시에서 결과가 추출되므로 PHPMyAdmin을 통해 실행하면 결과가 빠르다고 결론 내릴 수 있습니다. 거짓 긍정은 b *** h입니다. – Mjh

+1

이 쿼리는 전체 테이블 스캔을 수행하는 것으로 보입니다. 일부 행이 잠긴 경우 어떻게됩니까? 전체 행이 잠겨 있으면 어떻게 될까요? 이것이이 쿼리가 가끔은 빠르게 실행되는 것처럼 보이지만 다른 때에는 그렇지 않습니다. – e4c5

+0

'SELECT SQL_NO_CACHE .... (나머지 쿼리) '를 실행하면 쿼리 속도에 영향을 미치는 캐시인지 여부를 확인할 수 있습니다. 여전히 * 빠른 * 결과를 얻으면 @ e4c5가 정확합니다. 두 시나리오 모두 가능합니다. – Mjh

답변

1
  • (즉 MySQL은 5 초 이상 걸리는 쿼리를 기록 의미) 그 많은 것들?

  • "calc found rows"를 얻는 방법을 다시 한 번 확인하십시오. UI에서 제거하거나 값을 캐싱 및/또는 근사하는 방법을 살펴보십시오.

  • t.description, a.description - JOINs은 (는) 성능이 저하되고 있습니다.

은 (그리고 이미 언급 한 바와 같이, 쿼리 캐시가 타이밍을 혼동 될 수있다. 간단히에서 발로에서 QC를 방지 할 수 LIMIT 0,50LIMIT 0,51에 변화는. 물론, SQL_NO_CACHE 더 낫다.) 쿼리 때문에

+0

t.description, 일부 스포팅을 찍은 a.description! +1 – e4c5

+0

그들은 나를 아무렇지도 않게 부르지 않습니다. –

+0

좋아, 이제는 SQL_NO_CACHE를 사용하여 실행하며 3.4 초가됩니다. 내가 JOIN을 꺼내면 1 초를 줄이지 만 여전히 2.4 초가 걸립니다. INDEX (카테고리, 상태, 도시) 만들기가 1 초 더 줄였습니다. 그러나 CALC_FOUND_ROWS를 사용하면 가장 큰 효과를 얻었으며 0.003 초로 완벽 해졌습니다. JOIN을 피하기 위해 다른 테이블의 데이터를 복제 할 수는 있지만 JQuery 데이터 테이블 플러그인에서 사용하는 CALS_FOUND_ROWS에 대한 정보를 찾아야합니다. 고맙습니다. – user164863

-2

느린 쿼리를 캡처하려면 my.ini 파일을 변경해야합니다. 당신이

  • log_slow_queries = 5에 있어야 slow_query_log 최대

    1. 설정해야 다음 매개 변수가 있습니다; 사용자가 정말 필요합니까 - 많은 데이터 아웃 것을 덤핑 INDEX(category, status, city)

    2. 다시 생각을 추가

    감사합니다, 케쉬

  • +0

    을 읽을 수 없습니다. OP에 이미 설정이되어 있는데 왜 가끔씩 느린 지 묻습니다. – e4c5

    +1

    Downvote 이유 - 질문을 읽지 않아서 완전히 다른 답변을 제공했습니다. . 나는 이것을 삭제하는 것이 좋습니다. – Mjh