「高性能のMysql、」ブックを見て最近、ここでは主に使用するように学んで、統計MySQLサーバのステータスを学ぶ方法を学ぶの要約である のSHOW STATUS、にSHOW ENGINE INNODB STATUS、 SHOW PROCESSLISTは、SHOWのPROFILE 4つのコマンドは。
コマンド：SHOWステータス
MySQLのショーstatusコマンドは、状態変数関連の統計を照会します
ショーの状態によっていくつかの変数を見たいです
これらの状態変数は、ユーザーは読み取り専用では、MySQL自体が自動的に動作中のステータス情報を更新します
両方のセッションレベルのグローバル変数を持っているそれらの多くはショーのステータス交絡グローバルとセッション変数、
セッション・レベルおよびグローバルな重複した名前は、showステータス表示のみセッションレベルならば、あなたはショーの世界的な状況によってグローバルな状態を表示することができます
結果は、ステータスクエリがinformation_schema.global_statusとinformation_schema.session_statusで見つけることができることを示します
（1）Aborted_ *変数 - 関連しました
MySQLの>「中止されまし％」のようなショーのステータス。+ ------------------ + --------- + | 変数名| バリュー| + ------------------ + --------- + | Aborted_clients | 1439 | | Aborted_connects | 5025336 | + ------------------ + --------- + 2行于数据集（0.08秒）
中止された接続は、次のようにMySQLサーバの障害、状態変数で、この急増の原因に接続するための試行回数を表します。
しかし、クライアントは、MySQLデータベースにアクセスしようとする権限がありません。
入力されたクライアントのパスワードが正しくありません。
接続パケットは、この場合、サーバは、一般的によりエラーの生存にポート3306かどうかがチェックさを監視する、（送信パケットデータが正しく接続ではない）適切な情報を含んでいません
接続時間が制限を超えて、システム変数接続時間CONNECT_TIMEOUT制御（MySQLのデフォルトの10S）
中止されたクライアントは、クライアントが正常に接続を確立するが、一般的に不安定なネットワーク環境で発生した何らかの理由で切断または終了されて、ためにすることを意味します。主な可能性があります。
クライアントプログラムはにmysql_closeを終了する前に呼び出されません（）が正常にMySQLの接続を閉じました
クライアントの睡眠時間は接続が終了するMySQLのプロセスをリードし、システム変数とWAIT_TIMEOUTのは、interactive_timeoutの値を超えて
クライアントプログラムは、突然のデータ転送処理を終了します
（2）接続は、* - 関連変数
「％コネクション％」のようなMySQLの>ショーのステータス。+ ----------------------------------- + ------- + | 変数名| バリュー| + ----------------------------------- + ------- + | Connection_errors_max_connections | 0 | | 接続| 197 | | Max_used_connections | 2 | + ----------------------------------- + ------- +
MySQL接続表現開始から今まで、接続を正常に確立された接続の数は、この値は常に蓄積されています
Max_used_connectionsは、開始日からのMySQL、同時接続の最大数と同じ時間を表しています。この値は、max_connectionsをパラメータよりも大きい場合には、システムが常に高い同時の状態では、同時接続の最大数が多い転送するために検討すべきであることを示しています
MySQLは同時MAX_CONNECTIONSシステム変数の最大数よりも大きい同時Connection_errors_max_connectionsの最大数は、このように拒否数は、この変数に記録されます。Connection_error_max_connections値が比較的大きい場合には、現在のシステムを上げるMAX_CONNECTIONSの値を考慮することが、比較的高いによって複雑になります。
ここでの方法で接続されたシステム構成変数に関する情報を見つけるために：
MySQLの>のようなショーの変数 '％は％を接続します'; + ----------------------------------------------- + - ---------------- + | 変数名| バリュー| + ----------------------------------------------- + - ---------------- + | character_set_connectionに| UTF8 | | CONNECT_TIMEOUT | 10 | | max_connect_errors | 100 | | MAX_CONNECTIONS | 151 | | MAX_USER_CONNECTIONS | 0 | + ----------------------------------------------- + - ---------------- +
MAX_CONNECTIONS：
MySQLサーバインスタンスへの同時接続の最大数を意味し、同時に受け入れることができます。MySQLは、実際の接続保証の数がなくなったときに、スーパー管理者は、まだ管理するために、接続して、サーバーを確立することができ、最大接続数プラス1つのアルゴリズムをサポートしています。
MAX_USER_CONNECTIONS：
アカウントあたりの同時接続の最大数。
max_connect_errors：
悪質なホストのエラー台湾、アフリカ、MySQLサーバに接続するには、値に達したときに設定され、MySQLはそのホストからのすべての接続を拒否します。しかし、それはフラッシュのホストを実行した後にクリアされます。
CONNECT_TIMEOUT
接続フェーズ（認証）MySQLの接続を取得、動作するように取得では、チェックのユーザー名とパスワードに一致するだけでなく、IP-> HOST-> DNS-> IPの検証、ネットワークが原因でそうな任意のステップに加えて、握手の何倍もの結果であります問題は、スレッドブロックの原因となります。不要な糸くずの検証を防ぐために、CONNECT_TIMEOUT接続要求が拒否されているよりも、10秒のデフォルト値を待ちます。
（3）Thread_ *変数 - 関連しました
mysqlの> 'スレッド％' のようなショーの状態; + ------------------------- + ------- + | VARIABLE_NAME |価値| + ------------------------- + ------- + | Threads_cached | 29 | | Threads_connected | 94 | | Threads_created | 417 | | Threads_running | 2 |データセットの+ ------------------------- + ------- + 6行（0.02秒）のコピーコード
キャッシュ内のスレッドの数Thread_cached、衝撃の大きさによってデジタルパラメータthread_cache_size
現在の接続数をThread_connected
最初から今までのスレッドの数は、作成され、その値が大きい場合、大きなthread_cache_sizeパラメータを転送することをお勧めします。Thread_created
Thred_running：アクティブなスレッドの現在の数
（4）COM_ *統計的変数が始まります
mysqlの>「コム％」のようなグローバルな状態を表示。+ ----------------------------- + ------- + | 変数名| バリュー| + ----------------------------- + ------- + | Com_change_db | 4444 | | Com_select | 5117790905 | | Com_alter_db | 0 | ..... + ----------------------------- + ------- +复制代码
COM_ *統計情報の先頭には、そのようなCom_deleteとCom_insertを削除し、挿入操作カウントするために使用して、前に開始したSQLの各タイプの数を記録するために使用されますが、クエリキャッシュヒットならば、その数は記録されません。現在のセッションの統計情報だけを表示することが「コム％」の違い、のような「コム％」とショーのステータスのようなグローバルな状態を示して注意してください。
（5）Created_tmp *一時ファイルや一時テーブルの統計情報
mysql> show global status like 'Created_tmp%'; +-------------------------+----------+ | Variable_name | Value | +-------------------------+----------+ | Created_tmp_disk_tables | 8856206 | 临时表在磁盘的创建量 | Created_tmp_files | 381 | 临时文件的创建量 | Created_tmp_tables | 26450958 | 临时表的总的创建量 +-------------------------+----------+ 3 行于数据集 (0.14 秒) 复制代码
（6）查询缓存的统计
通过变量 query_cache_type 来设置是否开启缓存，通过变量 query_cache_limit 来设置缓存结果集的上限，如果某次查询超过该上限制则不进行缓存
mysql> show global status like 'Qcache%'; +-------------------------+----------+ | Variable_name | Value | +-------------------------+----------+ | Qcache_free_blocks | 1 | 这个表示目前处于空闲状态的 query cache 中内存 block 的数目 | Qcache_free_memory | 1031832 | 缓存中空闲内存总量 | Qcache_hits | 0 | 缓存命中次数 | Qcache_inserts | 0 | 缓存失效次数 | Qcache_lowmem_prunes | 0 | 缓存出现内存不足并且必须要进行清理以便为 Qcache_inserts 动作腾出空间的次数 | Qcache_not_cached | 17841427 | 没有进行缓存的查询的数量 | Qcache_queries_in_cache | 0 | 当前在 query_cache 中‘注册’的 select 语句条数 | Qcache_total_blocks | 1 | 缓存中块的总量 +-------------------------+----------+ 8 行于数据集 (0.12 秒) 复制代码
（7）Select 查询类型统计
Select.* 统计特定类型 Select 查询的计数器，它可以帮我们了解各种查询计划
mysql> show global status like 'Select%'; +------------------------+----------+ | Variable_name | Value | +------------------------+----------+ | Select_full_join | 7224 | | Select_full_range_join | 0 | | Select_range | 72966 | | Select_range_check | 0 | | Select_scan | 22053174 | +------------------------+----------+ 5 行于数据集 (0.17 秒) 复制代码
Select_scan：表示查询时第一张表整表扫描的次数，如果你并不想要第一张表的所有行但是又没用索引，此时查询性能很差
Select_range：在第一张表上扫描索引区间的查询数目
Select_range_check：这个比 Select_full_join 要好一点，和 Select_range 差不多。区别是 MySQL 不能确定它能否使用一个范围来做关联查询。如果可以那么会使用范围，如果不行仍会使用全表扫描
Select_full_join：和 Select_scan 差不多，区别是 Select_full_join 代表的是第二张及之后的表
Select_full_range_join：和 Select_range_check 类似，不过 MySQL 可以肯定它能够使用范围查找。这时 explain 中的类型是 range
（8）Sort.* 类型统计
当 mysql 不能使用一个索引来进行预先排序的时，必须使用文件排序，这就会增加 Sort* 状态变量的值，
mysql> show global status like "Sort%"; +-------------------+---------+ | Variable_name | Value | +-------------------+---------+ | Sort_merge_passes | 256 | | Sort_range | 31603 | | Sort_rows | 9718897 | | Sort_scan | 1727948 | +-------------------+---------+ 4 行于数据集 (0.02 秒) 复制代码
Sort_range：当 Mysql 从文排序结果中读取已经排序好的行时，如果是 Select_range 增加，那么 Sort_range 也会增加
Sort_scan：当 Mysql 从文排序结果中读取已经排序好的行时，如果是 Select_scan 增加，那么 Sort_scan 也会增加
Sort_rows：被排序记录的总数
Sort_merge_passes： Mysql 在排序时首先尝试在内存中做排序，使用内存的大小由 Sort_buffer_size 决定，如果超过该大小会将排序结果放在临时文件中，最后进行统一合并，此时会增加 Sort_merge_passes 的值
（9）Table_locks.* 表锁相关统计
mysql> show global status like "Table_locks%"; +-----------------------+---------+ | Variable_name | Value | +-----------------------+---------+ | Table_locks_immediate | 4270707 | | Table_locks_waited | 0 | +-----------------------+---------+ 2 行于数据集 (0.28 秒) 复制代码
Table_locks_immediate：这个表示有多少锁当查询到来时立即被授权
Table_locks_waited：这个表示有多少锁当查询到来时需要等待，如果该值较大说明锁争用比较严重，因为 InnoDb 支持行级锁，该值一般都很小
命令二：SHOW ENGINE INNODB STATUS\G
show engine innodb status 输出了关于 InnoDB 一些平均值的统计信息，对于数据的采样计算的时间间隔也不总是相同的，里面提供了大多数你要想要的统计信息。
该命令输出是一个单独的字符串，没有行和列，分为很多小段，所以加 \G 参看更为方便，每一段都对应了 InnoDB 存储引擎不同部分的信息，
（1）头部信息
-- 表示当前输出结果是对过去某个时间范围内 InnoDB 存储引擎的状态的统计 Per second averages calculated from the last 60 seconds
（2）BACKGROUND THREAD
InnoDB 存储引擎的核心操作大部分都集中在 Mater Thread 后台线程中，该状态显示了后台线程状态信息，Master Thread 的主要工作：
主循环(loop)主要以每一秒和每十秒的频率执行刷新日志缓存，合并插入缓存，刷新脏页缓存，删除无用 undo 页等操作
如果当前没有用户活动，则进入后台循环流程(backgroud loop)，主要执行删除无用的 undo 页，合并插入缓存
如果没有什么事情可以做了，便进入了暂停循环(suspend loop)，等待事件循环唤起
----------------- BACKGROUND THREAD ----------------- # srv_active 为每秒的循环次数，srv_idle 为每 10 秒的的循环次数，srv_shutdown 为停止的循环，通常为 0 # 如果每秒循环次数少，每 10 秒次数多，证明当前负载很低；如果每秒循环次数多，每 10 秒次数少，远大于10：1，证明当前负载很高 srv_master_thread loops: 2818842 srv_active, 0 srv_shutdown, 411 srv_idle # 日志缓冲刷盘次数 srv_master_thread log flush and writes: 2819194
（3）SEMAPHORES（信号量）
主要包含了两种数据：事件计数器以及可选的当前等待线程列表。首先了解一下 InnoDB 如何两步获得锁过程：
首先线程试图获得一个锁，如果此锁被它人占用。它就会执行所谓的 spin wait，轮询查看锁是否释放
如果在循环过程中，一直未得到锁释放的信息，则其转入 os wait，即线程进入挂起(suspended)状态
直到锁被释放后，通过信号(singal)唤醒线程
spin wait 的消耗远小于 os waits，spin wait 利用 cpu 的空闲时间，检查锁的状态，os Wait 从 CPU 内核中换出当前执行线程以供其它线程使用。所以应尽量减少 os waits，可以通过 innodb_sync_spin_loops 参数来平衡 spin wait 和 os wait。
---------- SEMAPHORES ---------- OS WAIT ARRAY INFO: reservation count 293642477 # 表示 InnoDB 产生了多少次操作系统的等待 OS WAIT ARRAY INFO: signal count 117881542 # 表示进入 OS WAIT 的线程被唤醒次数 RW-shared spins 0, rounds 318628772, OS waits 205885745 # 共享锁 RW-excl spins 0, rounds 2120303681, OS waits 66818882 # 排他锁 RW-sx spins 16623848, rounds 479205501, OS waits 15180111 # 共享排他锁 Spin rounds per wait: 318628772.00 RW-shared, 2120303681.00 RW-excl, 28.83 RW-sx
（4）LATEST FOREIGN KEY ERROR
该错误一般不会出现，除非你服务器上外键错误，比如违反外键约束去更新，删除数据，或者去修改外键的类型导致类型不匹配，都会报这个错， show engine innodb status 在每次有新错误时，该信息都会被重写
（5）LATEST DETECTED DEADLOCK
记录最近一次死锁信息，只有产生过死锁才会有记录。该信息对于查看到底是什么导致死锁非常有用
通过下面的信息我们可以知道死锁的发生时间，死锁里每个事务的状态和信息
------------------------ LATEST DETECTED DEADLOCK ------------------------ 190425 18:00:13 *** (1) TRANSACTION: TRANSACTION 231E7C5DF, ACTIVE 0 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 4 lock struct(s), heap size 1248, 3 row lock(s) MySQL thread id 1346996, OS thread handle 0x7fd968454700, query id 760545285 10.10.x.x app_user updating DELETE FROM db_0.table_0 WHERE ORDER_ID IN ( 456787464 , 456787465 ) *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 5 page no 6064 n bits 824 index `orderId_index` of table `db_0`.`table_0` trx id 231E7C5DF lock_mode X waiting Record lock, heap no 180 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 0: len 8; hex 80000015eb6a1041; asc j A;; 1: len 8; hex 800000002018fce2; asc ;; *** (2) TRANSACTION: TRANSACTION 231E7C5DD, ACTIVE 0 sec starting index read, thread declared inside InnoDB 1 mysql tables in use 1, locked 1 5 lock struct(s), heap size 1248, 4 row lock(s) MySQL thread id 1348165, OS thread handle 0x7fd96669f700, query id 760545283 10.10.x.x app_user updating DELETE FROM db_0.table_0 WHERE ORDER_ID IN ( 456787464 , 456787465 ) *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 5 page no 6064 n bits 824 index `orderId_index` of table `db_0`.`table_0` trx id 231E7C5DD lock_mode X locks rec but not gap Record lock, heap no 180 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 0: len 8; hex 80000015eb6a1041; asc j A;; 1: len 8; hex 800000002018fce2; asc ;; *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 5 page no 6064 n bits 824 index `orderId_index` of table `db_0`.`table_0` trx id 231E7C5DD lock_mode X waiting Record lock, heap no 180 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 0: len 8; hex 80000015eb6a1041; asc j A;; 1: len 8; hex 800000002018fce2; asc ;; *** WE ROLL BACK TRANSACTION (1) # 这个表示那个事务被选中成为死锁的牺牲品
（6）TRANSACTIONS
包含了 InnoDB 事务(transaction)的统计信息。
------------ TRANSACTIONS ------------ # 当前的事务 ID，这是一个系统变量，每创建一个新事务会加 1 Trx id counter 319435931 # Purge done for trx's 这个表示清除旧的 MVCC 行时所用到的事务 ID，和当前事务 ID 相比较，可以知道有多少老版本数据未被清理。 # undo n:o 表示正在使用的 undo 日志编号，如果是 0 的话，表明处于空闲状态 Purge done for trx's n:o < 319435931 undo n:o < 0 state: running but idle # 这个表示 InnoDB undo 日志文件页面的个数，如果事务执行了更新并提交，这个数字会增加，当清理进程移除旧版本数据时，该值会减少 History list length 1631
（7）FILE I/O
在 InnoDB 中大量使用了 AIO（Async IO）来处理 IO 请求，IO Thread 主要是负责这些 IO 请求的回调处理，通过调用 fsync() 函数协调内存与磁盘之间的数据。
主要包括以下几种 IO 线程：
insert buffer thread： 插入合并缓存线程
log thread： 异步刷新事务日志线程
read thread： 读线程，通过参数 innodb_read_io_threads 控制个数，默认是 4
write thread： 写线程，主要用于刷新脏页缓存，通过参数 innodb_write_io_threads 控制个数，默认是 4
purge thread： 回收已经使用并分配的 undo 页，从 Master Thread 线程中分离出来，提高 CPU 的利用率。innodb 1.2 版本以后，可以通过参数 innodb_purge_threads 来设置 Purge 线程的个数
page cleaner thread： 负责脏页的刷新，innodb 1.2 版本以后从 Master Thread 线程中分离出来，提高 CPU 的利用率，减轻 Master Thread 的压力
FILE I/O 显示了辅助线程的状态以及性能计数器的状态
-------- FILE I/O -------- # 各个辅助线程的状态信息 I/O thread 0 state: waiting for completed aio requests (insert buffer thread) I/O thread 1 state: waiting for completed aio requests (log thread) I/O thread 2 state: waiting for completed aio requests (read thread) I/O thread 3 state: waiting for completed aio requests (read thread) I/O thread 4 state: waiting for completed aio requests (read thread) I/O thread 5 state: waiting for completed aio requests (read thread) I/O thread 6 state: waiting for completed aio requests (write thread) I/O thread 7 state: waiting for completed aio requests (write thread) I/O thread 8 state: waiting for completed aio requests (write thread) I/O thread 9 state: waiting for completed aio requests (write thread) # 下面三行显示的是每个辅助线程被挂起操作的数目，如果这些 I/O 大部分有挂起的操作，那么负载可能 I/O 受限 Pending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] , ibuf aio reads:, log i/o's:, sync i/o's: Pending flushes (fsync) log: 0; buffer pool: 0 # 显示的是读，写，fsync 调用执行的次数 230490715 OS file reads, 200072148 OS file writes, 154690982 OS fsyncs # 每个线程每秒的平均值 17.15 reads/s, 16384 avg bytes/read, 23.65 writes/s, 21.08 fsyncs/s
（8）INSERT BUFFER AND ADAPTIVE HASH INDEX
插入缓存：
插入缓存主要用于非聚集索引的插入和更新操作，把多次插入和更新操作放在一个 Insert Buffer 对象里，再以一定的频率进合并更新，提高性能。
自适应哈希索引
InnoDB 会监控对表上各个索引页的查询，如果观察到通过哈希索引可以带来性能提升，则自动建立哈希索引，通过参数 innodb_adaptive_hash_index 来禁用或启动
INSERT BUFFER AND ADAPTIVE HASH INDEX 显示了插入缓存和自适应哈希索引的使用情况。
------------------------------------- INSERT BUFFER AND ADAPTIVE HASH INDEX ------------------------------------- # Ibuf 表示已经合并页的数量，free list len 表示空闲列表长度，seg size 表示 Insert Buffer 的大小，merges 表示合并次数， Ibuf: size 1, free list len 80, seg size 82, 2639224 merges # 分别查看 Insert Buffer, Delete Buffer, Purge Buffer 的次数 merged operations: insert 4178472, delete mark 151972, delete 60065 # 不需要合并的次数 discarded operations: insert 0, delete mark 0, delete 0 # 自适应 hash 索引的大小 Hash table size 276671, node heap has 5 buffer(s) Hash table size 276671, node heap has 21 buffer(s) Hash table size 276671, node heap has 56 buffer(s) Hash table size 276671, node heap has 210 buffer(s) Hash table size 276671, node heap has 8 buffer(s) Hash table size 276671, node heap has 111 buffer(s) Hash table size 276671, node heap has 9 buffer(s) Hash table size 276671, node heap has 33 buffer(s) # 通过 hash 索引查询每秒个数，无法通过 hash 索引查询每秒的个数 4798.09 hash searches/s, 600.67 non-hash searches/s
（9）LOG
这部分内容显示的是关于 InnoDB 重做日志的统计，以下三种情况重做日志都会被刷新到磁盘
Master Thread 会每秒进行刷新
每个事务提交时会刷新
重做日志缓存空间小于 1/2 时会强制刷新
--- LOG --- Log sequence number 197081867058 # 当前日志 LSN 序号 Log flushed up to 197081867058 # 日志刷新到磁盘的 LSN 序号 Pages flushed up to 196985565734 # 已经刷新到磁盘页的 LSN 序号 Last checkpoint at 196985468367 # 上一次 Checkpoint 的 LSN 序号 # 统计日志的总量及每秒日志的量 0 pending log flushes, 0 pending chkp writes 142876358 log i/o's done, 18.32 log i/o's/second
（10）BUFFER POOL AND MEMORY
这部分信息显示了关于 InnoDB 缓存池及其如何使用内存的统计，为了提高数据库的性能，引入缓存池的概念，通过参数 innodb_buffer_pool_size 可以设置缓存池的大小，参数 innodb_buffer_pool_instances 可以设置缓存池的实例个数。缓存池主要用于存储以下内容：索引页，数据页，undo 页，插入缓存(insert buffer)，自适应哈希索引(adaptive hash index)，锁信息，数据字典信息等信息。
---------------------- BUFFER POOL AND MEMORY ---------------------- Total large memory allocated 2198863872 # InnoDB 分配的总内存 Dictionary memory allocated 7884277 # InnoDB 数据字典分配的内存数， Buffer pool size 131064 # innodb_buffer_pool 页的数量 Free buffers 1024 # LRU 列表中空闲页的数量 Database pages 129587 # LRU 列表中非空闲页的数量 Old database pages 47815 # LRU 列表中 old 页的数量，new 和 old 页的分界通过参数 innodb_old_blocks_pct 设置 Modified db pages 20916 # 脏页的数量 Pending reads 0 # 挂起读的数量 Pending writes: LRU 0, flush list 0, single page 0 # 挂起的写的数量 Pages made young 125019609, not young 11734595709 6.70 youngs/s, 109.36 non-youngs/s # read 是指从磁盘读到缓存池中，written 是从缓存池写入磁盘，created 是指在缓存池中分配但没有从数据文件中读取的页 Pages read 230491590, created 15808941, written 53911882 17.15 reads/s, 1.20 creates/s, 4.28 writes/s # 缓存命中率 Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 4 / 1000
（11）ROW OPERATIONS
显示了 row 操作及其他一些统计信息
-------------- ROW OPERATIONS -------------- # queries，表示 innodb 内核中有多少个线程，队列中有多少个线程 0 queries inside InnoDB, 0 queries in queue # 表示有多少个读视图被打开，一个读视图包含从事务开始数据库内容的 MVCC 快照 0 read views open inside InnoDB # 内核主线程的状态，大部分情况下处于"sleeping"，主线程主要工作有 making checkpoint, flushing log, flushing buffer poll pages 等 Process ID=51, Main thread ID=140023262725888, state: sleeping # 表示多少行被插入，更新和删除，读取及每秒读取信息，可用于监控 Number of rows inserted 637410366, updated 210696023, deleted 335066, read 311734809045 60.43 inserts/s, 9.95 updates/s, 0.00 deletes/s, 48640.59 reads/s
命令三：SHOW PROCESSLIST
显示了当前连接到 MYSQL 的连接或者线程的状态，除了 root 用户能看到所有正在运行的线程外，其他用户都只能看到自己正在运行的线程，看不到其它用户正在运行的线程。除非单独为这个用户赋予了 PROCESS 权限。show processlist 的结果其实来自于 information_schema.processlist 表，所以我们通过查询 information_schema.processlist 表可以获取对于排查性能问题有用的信息，比如哪个客户端连接信息最多，哪些线程执行时间最长等信息。
SHOW PROCESSLIST\G; *************************** 238. 行 *************************** Id : 666748 User : youdata Host : 10.255.0.2:56058 db : youdata Command : Sleep Time : 127 ACK_WAIT_TIME: 0 State : Info : *************************** 239. 行 *************************** Id : 666761 User : youdata Host : 10.255.0.2:60619 db : NULL Command : Query Time : 0 ACK_WAIT_TIME: 0 State : starting Info : starting 239 行于数据集 (0.51 秒)
下面看一下每个字段的含义：
Id： 这个是线程的唯一标志，当遇到问题时可以通过 kill 加上这个 Id 值将这个线程杀掉
User： 表示启动线程的用户
Host： 记录了发送请求的客户端的 IP 和端口
DB： 执行的数据库
Command： 正在执行的命令，比如 Query，Create DB，Quit，Sleep 等
Time：该线程处于当前状态的时间
State：线程的状态,有很多种情况，下面只列举了部分：
- Checking table: 正在检查数据表 - Closing tables：正在将表中修改的数据刷新到磁盘中，同时正在关闭已经用完的表 - Locked：被其它查询锁住了 - Sending data：正在处理 Select 查询的记录同时把数据发动到客户端 - Sorting for group：正在为 group by 操作做排序 - Updating： 正在寻找匹配的记录来修改他们 ....
Info：一般记录的是线程执行的语句。默认只显示前 100 个字符，也就是你看到的语句可能是截断了的，要看全部信息，需要使用 show full processlist
命令四：SHOW PROFILE
mysql 5.1 版本开始支持 SHOW PROFILE
SHOW PROFILE 可以高精度的记录每个查询语句在运行过程中各个操作的执行时间
开启 SET profiling = ON，默认关闭
SHOW PROFILES 可以列出最近 N 条 SQL 的执行时间，N 默认是 15，可以通过参数 profiling_history_size 进行控制
mysql> show profiles; +----------+------------+---------------+----------------+---------------------------------------------------------------------------+ | Query_ID | Duration | Logical_reads | Physical_reads | Query | +----------+------------+---------------+----------------+---------------------------------------------------------------------------+ | 1 | 0.00019325 | 0 | 0 | select @@version_comment limit 1 | | 2 | 0.00043125 | 0 | 0 | SELECT DATABASE() | | 3 | 0.00058600 | 0 | 0 | show databases | | 4 | 0.00060725 | 0 | 0 | show tables | | 5 | 0.00013125 | 0 | 0 | show global profiles | | 6 | 0.00014375 | 0 | 0 | show global profiles | | 7 | 0.00073550 | 0 | 0 | select * from bigviz_user where email like "%hzzhang%" order by nick desc | | 8 | 0.01025300 | 0 | 0 | select count(*) from new_component | +----------+------------+---------------+----------------+---------------------------------------------------------------------------+ 8 rows in set, 1 warning (0.00 sec)
SHOW PROFILE 可以列出最近一条语句的执行详细信息。如果指定 FOR QUERY n 子句时，可以列出最近 N 条中某条语句的执行详细信息, 其中 n 表示上面显示的 Query_ID
mysql> show for query 7; +----------------------+----------+ | Status | Duration | +----------------------+----------+ | starting | 0.000158 | | checking permissions | 0.000013 | | Opening tables | 0.000028 | 打开表 | init | 0.000073 | | System lock | 0.000018 | 加锁 | optimizing | 0.000015 | | statistics | 0.000026 | | preparing | 0.000017 | | Sorting result | 0.000010 | 排序 | executing | 0.000005 | | Sending data | 0.000029 | 发送数据 | Creating sort index | 0.000223 | | end | 0.000008 | | query end | 0.000011 | | closing tables | 0.000039 | 关闭表 | freeing items | 0.000039 | | cleaning up | 0.000025 | +----------------------+----------+ 17 rows in set, 1 warning (0.00 sec)
SHOW PROFILE 只对当前会话生效，所以我们一般是在命令行工具里开启然后执行自己想要分析的SQL，再通过 show profile 查看性能。