[MySQL 데이터베이스] 3장 해석: 서버 성능 분석(1부)

머리말:

빈 컵 정신을 유지하고, 성능 분석을 사용하고, 서버의 시간이 어디에 소비되는지 측정하는 데 집중하세요. 1. 서버가 최적의 성능 상태에 도달했는지 확인하는 방법, 2. 특정 진술은 왜 충분히 빠르지 않으며 진단은 사용자가 "일시 중지, 축적 및 중단"으로 설명하는 간헐적이고 어려운 오류입니다.

다음으로 전체 시스템의 성능을 최적화하고 실행 속도를 최적화하는 몇 가지 도구와 기술을 소개하겠습니다. 단일 명령문으로 시스템을 측정하고 프로파일링 보고서를 생성하는 방법과 시스템 스택을 분석하는 방법을 보여줍니다.

3.1 소개

성능: 소요 시간을 측정합니다. 작업 완료, 즉 성능은 응답 시간입니다

처리량: 단위 시간 데이터 쿼리(성능 정의의 역수)

1단계: 시간이 어디로 갔는지, 어디에서 소비되었는지 파악

대답이 다음과 같다면 측정을 통해 찾을 수 없으면 측정 방법이 잘못되었거나 완벽하지 않습니다. 필요한 것만 측정합니다. 최적화된 활동

잘못된 시간에 테스트를 시작하거나 중지하지 마십시오. 측정되는 것은 대상 활동이 아닌 집계된 정보입니다. 하위 작업을 찾아서 최적화해야 합니다

원칙: 측정할 수 없으면 효과적으로 최적화할 수 없습니다

3.1.1 성능 프로파일링을 통한 최적화

성능 프로파일링: 측정 및 분석의 주요 방법 시간이 소요되는 위치

1. 작업에 소요된 시간 측정 2. 통계 및 결과 정렬(중요 앞줄)

성과 분석 보고서에 필요한 결과에 유사한 작업 요약이 포함될 수 있습니다. 모든 작업 및 각 줄에 작업 기록:

작업 이름, 실행 시간, 소비 시간, 평균 실행 시간, 전체 시간에 대한 비율 계산

성능 분석 유형:

실행 시간 기반 분석: 실행 시간이 가장 오래 걸리는 작업

대기 기반 분석: 작업이 가장 오랫동안 차단된 위치 확인

3.1.2 성능 분석 이해

누락되었지만 중요한 정보 성능 분석:

1. 최적화할 가치가 있는 쿼리

전체 응답 시간에서 작은 비율을 차지하는 쿼리는 최적화할 가치가 없습니다. 비용이 이익보다 크므로 최적화를 중지하세요

2. 예를 들어, 실행 횟수는 적지만 매번 유난히 느린 작업

3. 알 수 없음 알 수 없음

손실 시간: 작업의 총 시간은 실제 측정된 시간을 기준으로 하며, 찾지 못한 경우에도 마찬가지입니다. , 이러한 문제가 발생할 가능성에 주의해야 합니다

4. 숨겨진 세부 정보

모든 응답 시간, 추가 정보, 히스토그램, 백분율, 표준 편차 및 편차 지수의 분포를 표시하는 것은 불가능합니다

5. 디스플레이 스택의 상위 수준에서 대화형 분석

3.2 애플리케이션의 성능 분석: 하향식

성능 병목 현상에 영향을 미치는 요소:

1. 외부 리소스, 외부 웹 서비스 또는 검색 엔진 호출

2 애플리케이션에는 다음이 필요합니다. 많은 양의 데이터를 처리하고 매우 큰 XML 파일을 분석하려면

3. 루프에서 비용이 많이 드는 작업 실행: 일반 규칙 남용

4. 비효율적인 알고리즘 사용: 무차별 검색 알고리즘

권장 사항: 새 프로젝트에는 다음을 포함하는 것이 좋습니다. 성능 분석을 위한 코드

3.2.1 PHP 애플리케이션 측정: 비어 있음

3.3 MySQL 쿼리 분석

3.3.1 서버 로드 분석

로그 파일에 대한 MySQL 쿼리 가져오기:

1. 느린 쿼리 로그: 낮은 오버헤드, 높은 정확도 , 대용량 디스크 공간, 장기 활성화 로그 회전 도구 배포에 주의하세요. 5.1 이후 마이크로초 수준에서 로드 샘플을 수집하는 동안에만 활성화할 수 있습니다.

2. 쿼리 요청 시 기록되는 일반 로그. 서버로 전송되며 응답 시간 및 실행 계획은 포함되지 않습니다

쿼리 로그 분석

위에서 아래로 먼저 분석 보고서(pt-query-digest)를 생성하고 특별히 관심 있는 부분을 확인합니다

3.3 .2 단일 쿼리 분석

왜 그렇게 오래 걸리는지 생각해 보세요. 최적화 방법

SHOW PROFILE 사용 후: MySQL5.1

보기: "%pro%"와 같은 변수 표시 [출처]

기본적으로 비활성화됨 , 활성화: set profiling=1; 그런 다음 서버에서 명령문을 실행합니다(set profiling 끄기 =off;)

Syntax:

SHOW PROFILE [type [, type] ... ]  
    [FOR QUERY n]  
    [LIMIT row_count [OFFSET offset]]  
  
type:  
    ALL                --显示所有的开销信息  
  | BLOCK IO           --显示块IO相关开销  
  | CONTEXT SWITCHES   --上下文切换相关开销  
  | CPU                --显示CPU相关开销信息  
  | IPC                --显示发送和接收相关开销信息  
  | MEMORY             --显示内存相关开销信息  
  | PAGE FAULTS        --显示页面错误相关开销信息  
  | SOURCE             --显示和Source_function，Source_file，Source_line相关的开销信息  
  | SWAPS              --显示交换次数相关开销的信息

实质是这些开销信息被记录到information_schema.profiling表

show profiles；查看
show profile for query 2; 获取指定查询的开销（第二条查询开销明细）
show profile cpu for query 2 ;查看特定部分的开销，如下为CPU部分的开销 
show profile block io,cpu for query 2;  同时查看不同资源开销

SHOW STATUS 사용: counter

특정 연결을 기반으로 전역 상태 표시 세션 수준, 범위에 주의하세요

카운터는 일반적으로 사용되는 활동 빈도를 보여줍니다. 핸들 카운터, 임시 파일 및 테이블 카운터

는 임시 테이블을 생성하고 핸들(참조, 포인터? ) 이 임시 테이블에 액세스하여 상태 표시 결과의 해당 번호에 영향을 미칩니다

느린 쿼리 로그 사용: [소스] [소스]

응답 시간

이 느린 쿼리 로그에 대한

임계값 long_query_time을 초과하는 MySQL의 기록 문( 로그는 파일이나 데이터베이스 테이블에 쓸 수 있습니다. 고성능 요구사항이 있는 경우 파일에 쓰는 것이 좋습니다. 기본값은 10초이며 수동으로 켜야 합니다.보기:

​​​​

（1）slow_query_log的值为ON为开启慢查询日志，OFF则为关闭慢查询日志。

（2）slow_query_log_file 的值是记录的慢查询日志到文件中（注意：默认名为主机名.log，慢查询日志是否写入指定文件中，需要指定慢查询的输出日志格式为文件，相关命令为：show variables like ‘%log_output%’；去查看输出的格式）。

（3）long_query_time 指定了慢查询的阈值，即如果执行语句的时间超过该阈值则为慢查询语句，默认值为10秒。

（4）log_queries_not_using_indexes 如果值设置为ON，则会记录所有没有利用索引的查询（注意：如果只是将log_queries_not_using_indexes设置为ON，而将slow_query_log设置为OFF，此时该设置也不会生效，即该设置生效的前提是slow_query_log的值设置为ON），一般在性能调优的时候会暂时开启，开启后使用full index scan的sql也会被记录到慢查询日志。

//上述命令只对当前生效，当MySQL重启失效，如果要永久生效，需要配置my.cnf

查看输出格式：文件？表show variables like ‘%log_output%’;

开启通用日志查询： set global general_log=on;

关闭通用日志查询： set globalgeneral_log=off;

设置通用日志输出为表方式： set globallog_output=’TABLE’;

设置通用日志输出为文件方式： set globallog_output=’FILE’;

设置通用日志输出为表和文件方式：set global log_output=’FILE,TABLE’;

查询慢查询语句的个数：show global status like ‘%slow%’;

日志部分内容简介：

哪条语句导致慢查询（sql_text），该慢查询语句的查询时间（query_time），锁表时间（Lock_time），以及扫描过的行数（rows_examined）等信息。

利用自带的慢查询日志分析工具：mysqldumpslow

perl mysqldumpslow –s c –t 10 slow-query.log

-s 表示按何种方式排序，c、t、l、r分别是按照记录次数、时间、查询时间、返回的记录数来排序，ac、at、al、ar，表示相应的倒叙；-t 表示top的意思，后面跟着的数据表示返回前面多少条；-g 后面可以写正则表达式匹配，大小写不敏感。

使用Performance Schema:【源】【源】

监视MySQL服务器，收集性能参数，且表的存储引擎PERFORMANCE_SCHEMA，低耗能

本地服务器，表是内存表，表内容在服务器启动时重新填充，关闭时丢弃，更改不会被复制或写入二进制日志

特性：

性能方案配置可被动态的执行SQL修改，立即影响到数据收集

监控服务事件：事件是服务做并被感知到的任何事，时间信息可被收集

数据库性能方案，提供对运行时数据库服务进行内部检查的方式，关注性能数据

特定于一个数据库服务，数据库表关联到数据服务，修改不会被备份也不写进二进制日志

存储引擎用“感知点”收集事件数据，且存储在performance_schema数据库，可通过select语句进行查询

补充：数据库初始安装有三个基本库

mysql

    包含权限配置，事件，存储引擎状态，主从信息，日志，时区信息，用户权限配置等

information_schema

    对数据库元数据的抽象分析，由此提供了SQL语句方式来查询数据库运行时状态，每次对information_schema的查询都产生对metadata的互斥访问，影响其他数据库的访问性能。

performance_schema

    内存型数据库，使用performance_schema 存储引擎，通过事件机制将mysql服务的运行时状态采集并存储在performace_schema数据库。注意，两个单词之间用下划线连接时，表示performance_schema是一个数据库；用空格分开时，表示一个数据库性能方案，也表示一个存储引擎。

 相关文章：

【MySQL数据库】第三章解读：服务器性能剖析 （下）

【MySQL数据库】第二章解读：MySQL基准测试

위 내용은 [MySQL 데이터베이스] 3장 해석: 서버 성능 분석(1부)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!