[MySQL データベース] 第 3 章の解釈: サーバー パフォーマンス分析 (パート 1)

前書き:

空っぽの精神を維持し、パフォーマンス分析を使用し、サーバーの時間がどこに費やされたかを測定することに重点を置き、1. サーバーが最適なパフォーマンス状態に達したかどうかを確認する方法、2. 特定のステートメントがなぜそうなるのかを考えてください。十分な速度が得られず、診断は「一時停止、蓄積、スタック」とユーザーが表現する断続的で困難な障害です

次に、マシン全体のパフォーマンスを最適化し、実行速度を最適化するためのいくつかのツールとテクニックを紹介します。単一のステートメントを分析し、観察が難しい問題を診断して解決する方法、およびシステム スタックを分析する方法を示します。タスクを完了する、言い換えれば、パフォーマンスは応答時間です

スループット: 単位時間 クエリデータ (パフォーマンス定義の逆数)

ステップ 1:

どこに時間がかかり、どこに消費されたかを把握します

答えがそうでない場合測定によって発見された、測定方法が間違っているか、十分に完璧ではない 必要なものだけを測定する 最適化されたアクティビティ

間違ったタイミングでテストを開始または停止しないでください。測定されるのは、対象のアクティビティ自体ではなく、集約された情報です。 ; サブタスクを特定して最適化する必要がある

原則: 測定できない場合、効果的に最適化することはできません

3.1.1 パフォーマンスプロファイリングによる最適化パフォーマンスプロファイリング: どこで測定および分析するかという主な方法費やされた時間

1. タスクに費やされた時間を測定します。 2. 結果の統計と並べ替え (重要な最前列)

レポートには、パフォーマンス分析レポートに必要な結果がすべてリストされます。タスクを入力し、各行にタスクを記録します:

タスク名、実行時間、消費時間、平均実行時間、全時間に占める実行時間の割合

パフォーマンス;分析タイプ:

実行時間ベースの分析: 実行に最も時間がかかるタスクはどれですか?

待機ベースの分析: タスクが最も長時間ブロックされている場所を特定します

3.1.2 パフォーマンス分析について理解します

欠落している重要な情報パフォーマンス分析:

1. 最適化する価値のあるクエリ

総応答時間に占める割合が少ないクエリは最適化する価値がありません。最適化を中止します

2. 異常な状況はありません。たとえば、実行頻度は低いが、毎回の処理が特に遅いタスク

3. 不明 不明

損失時間: タスクの合計時間は、たとえそれが見つからなかったとしても、実際に測定された時間からのものです。 、そのような問題が発生する可能性があることに注意する必要があります

4. 非表示の詳細

すべての応答時間、詳細情報、ヒストグラム、パーセンテージ、標準偏差、偏差指数の分布を表示することはできません

5.スタックの上位レベルでの対話型分析

3.2 アプリケーションのパフォーマンス分析: トップダウン

パフォーマンスのボトルネックに影響を与える要因:

1. 外部リソース、外部 Web サービスまたは検索エンジンの呼び出し

2 、アプリケーションは次のことを行う必要があります。大量のデータを処理し、非常に大きな XML ファイルを分析する

3. ループ内で負荷の高い操作を実行する: 通常のルールの悪用

4. 非効率なアルゴリズムを使用する: ブルート フォース検索アルゴリズム

推奨事項: 新しいプロジェクトにはコードを含めることを検討する必要があります。パフォーマンス分析用

3.2.1 PHP アプリケーションの測定: 空

3.3 MySQL クエリの分析

3.3.1 サーバー負荷の分析

MySQL クエリをログ ファイルに取得:

1. 遅いクエリ ログ: 低オーバーヘッド、高精度、大きなディスク容量、長期的なアクティブ化。ログ ローテーション ツールの展開に注意してください。5.1 以降は、マイクロ秒レベルでのみアクティブ化できます。一般的なログは、クエリ リクエスト時に記録されます。サーバーに送信され、応答時間と実行計画は含まれません

クエリ ログを分析します

上から下まで、まず分析レポート (pt-query-digest) を生成し、特に懸念される部分を表示します

3.3。 2 単一のクエリを分析します

最適化する方法を考えてください

SHOW PROFILE: MySQL5.1

View: "%pro%" のような変数を表示します。デフォルトでは無効になっています。 Enable: set profiling=1; 次に、サーバー上でステートメントを実行します (set profiling =off; をオフにします)

構文:

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

特定の接続セッションに基づいてグローバル ステータスを表示しますレベル、スコープに注意してください

カウンターはアクティビティの頻度を示し、一般的に使用されます: ハンドルカウンター、一時ファイル、テーブルカウンター

は一時テーブルを作成し、ハンドル(参照、ポインター?)を介して操作します。 ) この一時テーブルにアクセスし、show status 結果の対応する数値に影響を与えますスロークエリログを使用します: [ソース] [ソース]

応答時間が

しきい値long_query_timeを超えるMySQLのステートメントをスロークエリログに記録します(ログはファイルまたはデータベーステーブルに書き込むことができます。高いパフォーマンス要件がある場合は、ファイルに書き込むことをお勧めします)、デフォルトは 10 秒で、手動でオンにする必要があります

View:

（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 中国語 Web サイトの他の関連記事を参照してください。