방법: 1. 느린 쿼리가 활성화되지 않은 경우 "set global Slow_query_log='ON';"을 사용하여 느린 쿼리를 활성화합니다. 2. "set global Slow_query_log_file=path"를 사용하여 느린 쿼리 파일 저장 위치를 설정합니다. "subl path"를 사용하세요. 파일을 쿼리하면 됩니다.
이 튜토리얼의 운영 환경: centos 7 시스템, mysql8.0.22 버전, Dell G3 컴퓨터.
Mysql에서 느린 sql 문 검색 기록
느린 쿼리 로그 Slow_query_log는 느린 sql 문을 찾기 위해 쿼리 로그를 사용합니다. SQL을 최적화할 수 있습니다.
mysql 데이터베이스에 로그인하세요:
1. 현재 느린 쿼리가 켜져 있는지 확인하세요. 그렇지 않다면
켜고 느린 쿼리에 지정된 시간:
show variables like 'slow_query_log'; show variableslike 'long_query_time';
쿼리 후 결과가 OFF인 경우 관련 설정을 통해 ON으로 변경해야 합니다:
set global slow_query_log='ON';
느린 쿼리 추적 시간을 1초로 설정:
이렇게 설정한 후에는 세상이 not 즉시 1초가 되며 데이터베이스가 다시 시작된 후에 적용됩니다:
2 느린 쿼리 로그 파일이 저장되는 위치를 설정합니다:
set global slow_query_log_file='/var/lib/mysql/test_1116.log';
3 다음 구성 파일을 봅니다.
sudo subl /var/lib/mysql/test_1116.log
지식 넓히기:
SELECT * FROM `slow_log` where start_time > '2019/05/19 00:00:00';이렇게 해서 오늘의 느린 쿼리를 알아 볼 수 있습니다. 현재 쿼리 상태 확인하기시스템에서 현재 실행 중인 쿼리를 확인하려면 누구나 공통적으로 show processlist를 사용해야 합니다. 실제로 이러한 데이터는 information_schema 라이브러리의 processlist 테이블에도 저장되어 있으므로, 조건부 쿼리를 하고, 이것을 직접 쿼리하는 것이 테이블을 만드는 것이 더 편리합니다. 예를 들어 모든 현재 프로세스를 봅니다.
select * from information_schema.processlist현재 진행 중인 쿼리를 보고 실행 시간에 따라 역순으로 정렬합니다.
select * from information_schema.processlist where info is not null order by time desc쿼리가 매우 빠르게 실행되기 때문에 일반적으로 실행되는 데이터베이스와 선택에 의해 캡처된 정보 is not null 쿼리의 수는 매우 적습니다. 우리처럼 로드가 많은 도서관에서는 대개 몇 가지 항목만 찾을 수 있습니다. 비어있지 않은 정보가 포함된 쿼리가 동시에 수십 개가 발견되는 경우 시스템에 문제가 있는 것으로 간주할 수도 있습니다. 시스템 문제 및 포지셔닝시스템 속도가 느려지는 것을 확인한 후 바로 느린 쿼리를 사용하여 프로세스 목록을 확인해 보니 분당 느린 쿼리 수가 1,000개 이상으로 치솟았고, 엄청난 양의 쿼리가 발생하는 것을 발견했습니다. 실행 중에 쿼리가 누적되었습니다. 최대한 빨리 시스템의 정상적인 운영을 복원하는 것이 최우선이기 때문에, 이에 영향을 미치는 가장 직접적인 방법은 프로세스 목록의 쿼리 결과 중 몇 개가 잠금 상태이거나 실행되었는지 확인하는 것입니다. 오랜 시간 동안 kill 명령을 사용하여 이러한 프로세스를 종료하십시오. 시스템 정체를 유발할 수 있는 이러한 프로세스를 지속적으로 종료하면 시스템이 일시적으로 정상 상태로 복원될 수 있습니다. 물론 이는 임시방편일 뿐입니다. 또한 가장 중요한 것은 물론 어떤 쿼리가 시스템 정체를 유발하는지 분석하는 것입니다. 우리는 여전히 분석을 위해 느린 쿼리를 사용합니다. 느린 쿼리 테이블 쿼리 결과에는 다음과 같은 몇 가지 중요한 지표가 있습니다. start_time 시작 시간 이 매개변수는 시스템 문제가 발생한 시간을 일치시켜 어떤 쿼리가 원인인지 찾는 데 사용해야 합니다. query_time 쿼리 시간
rows_sent 및rows_examined는 전송된 결과 수와 쿼리로 검색된 행 수입니다. 이 두 값은 특히 row_examined에서 중요합니다. 기본적으로 어떤 쿼리가 주의를 기울여야 할 "큰" 쿼리인지 알려줍니다.
실제 운영에서도 많은 행_검토된 쿼리를 하나씩 분석하고, 인덱스를 추가하고, 쿼리문 작성을 수정하여 문제를 완벽하게 해결합니다.
결과 처리 및 반영
느린 쿼리를 모두 확인하고 수정한 결과, 현재 분당 MySQL 느린 쿼리 수가 1~2개 사이를 맴돌고 있으며, CPU 부하도 매우 낮습니다. 문제는 기본적으로 해결되었습니다.
문제 원인을 생각해보면 주의할 점은 다음과 같습니다.
1. 데이터베이스 문제는 온라인에 접속할 때 문제를 일으키지 않는 경우가 많지만, 잘못된 쿼리 문이 지속적으로 누적되는 과정이 있습니다. 시스템 부하가 점차 증가할 예정입니다. , 낙타의 등을 부러뜨리는 마지막 빨대는 종종 설명할 수 없는 것 같습니다
2. 마지막 빨대는 전혀 존재하지 않을 수도 있습니다. 기능의 출시나 출시가 아니라 사용자 사용량이 증가함에 따라. , 데이터의 양이 증가합니다
3. 문제의 출현은 누적되는 과정이므로 출시하기 전에 각 코드를 검토해야 합니다
4. 인덱스 추가가 매우 중요합니다
5. 느린 쿼리 모니터링도 Zabbix 모니터링 범위에 포함되어야 합니다.
추천 학습: mysql 비디오 튜토리얼
위 내용은 mysql에서 느린 SQL 문을 쿼리하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!