• InnoDB Adaptive Hash Index
• InnoDB Buffer Pool Activity
• InnoDB Buffer Pool
• InnoDB Checkpoint Age
• InnoDB Current Lock Waits
• InnoDB I/O
• InnoDB I/O Pending
• InnoDB Insert Buffer
• InnoDB Insert Buffer Usage
• InnoDB Internal Hash Memory Usage
• InnoDB Lock Structures
• InnoDB Log
• InnoDB Memory Allocation
• InnoDB Row Lock Time
• InnoDB Row Lock Waits
• InnoDB Row Operations
• InnoDB Semaphores Wait Time
• InnoDB Semaphores Waits
• InnoDB Semaphores
• InnoDB Tables In Use
• InnoDB Transactions Active/Locked
• InnoDB Transactions
• MyISAM Indexs
• MyISAM Key Cache
• MySQL Binary/Relay Logs
• MySQL Command Counts
• MySQL Connections
• MySQL Files and Tables
• MySQL Handler
• MySQL Network Traffic
• MySQL Processlist
• MySQL Query Cache
• MySQL Query Cache Memory
• MySQL Query Response Time (Microseconds)
• MySQL Query Time Histogram(Count)
• MySQL Replication
• MySQL Select Types
• MySQL Sorts
• MySQL Table Locks
• MySQL Temporary Objects
• MySQL Threads
• MySQL Transaction Handler

显示了“自适应哈希索引”的使用情况,哈希索引只能用来搜索等值的查询.
# Hash table size 17700827, node heap has 35112 buffer(s)
# 3577.42 hash searches/s, 507.49 non-hash searches/s

1. Hash Index Cells Total
   自适应哈希表的槽数=innodb_buffer_pool_size/256
2. Hash Index Cells Used
   用到自适应哈希表的查询个数

显示Innodb缓冲池的内部活动,页的创建,读取,写入.如果有突然的增加或者减少,需要检查应用

1. Pages Created
2. Pages Read
3. Pages Written

1. Pool Size
   InnoDB缓冲池的页数量,每页大小16K
2. Database Pages
   数据页大小
3. Free Pages
   空闲页大小
4. Modified Pages
   "脏"数据页.如果脏数据页太多,则需要检查磁盘IO状态.

1. Uncheckpointed Bytes
   显示了未写入磁盘的数据量.如果该值的大小接近innodb_log_file_size * n 的总大小,则需要增加innodb_log_file_size的值,但是要注意,如果发生宕机,则需要更长的回复时间.(从redolog恢复)

1. InnoDB Lock Wait Secs
   显示每秒处于锁等待的innodb事务总数.如果有一个非常大的值,应该检查LOCK WAIT transactions,请看下面的模板

1. File Reads
   显示每秒文件的读次数
2. File Writes
   显示每秒文件的写次数
3. Log Writes
   写日志的次数
4. File Fsyncs
   调用fsync()函数的次数.与innodb_flush_log_at_trx_commit值的设置有关.

显示了InnoDB挂起的同步或异步IO操作.如果挂起的操作太多,则需要更大的RAM,更大的缓冲池,更快的磁盘.

1. Pending Aio Log Ios
2. Pending Aio Sync Ios
3. Pending Buf Pool Flushes
4. Pending Chkp Writes
5. Pending Ibuf Aio Reads
6. Pending Log Flushe
7. Pending Log Writes
8. Pending Normal Aio Reads
9. Pending Normal Aio Writes

插入缓冲,并不是缓存的一部分,而是物理页,对于非聚集索引的插入或更新操作,不是每一次直接插入索引页.而是先判断插入的非聚集索引页是否在缓冲池中.如果在,则直接插入,如果不再,则先放入一个插入缓冲区中.然后再以一定的频率执行插入缓冲和非聚集索引页子节点的合并操作.
使用条件:非聚集索引,非唯一

1. Ibuf Inserts
   插入的记录数
2. Ibuf Merged
   合并的页的数量
3. Ibuf Merges
   合并的次数

如果merges/merged的值等于3/1,则代表插入缓冲对于非聚集索引页的IO请求大约降低了3倍

1. Ibuf Cell Count
   分段大小
2. Ibuf Used Cells
   插入缓冲区的大小
3. Ibuf Free Cells
   "自由列表"的长度

显示了InnoDB内部各种哈希结构(不可人工干预),占用的内存大小.

1. Adaptive Hash Memory
   自适应哈希索引占用的内存大小
2. Page Hash Memory
3. Dictionary Cache Memory
4. File System Memory
5. Lock System Memory
6. Recovery System Memory
7. Thread Hash Memory

1. InnoDB Lock Structs
   该图形显示了在innodb内部有多少锁结构(不是死锁).这大致与当前事务锁住的行数有关系.可以用来判断是否存在锁争用.
   对于数量多少算好或者算坏,没有硬性的规定.实际情况下,大量的事务在等待锁,很明显,该值越小越好.
   这个数据来源是SHOW ENGINE INNODB STATUS;

# 23 lock struct(s), heap size 3024, undo log entries 27

# LOCK WAIT 12 lock struct(s), heap size 3024, undo log entries 5

# LOCK WAIT 2 lock struct(s), heap size 368

相关变量:innodb_log_buffer_size

1. InnoDB Log Buffer Size
2. Log Bytes Written
   Log sequence number
   当前日志的位置
3. Log Bytes Flushed
   Log flushed up to
   日志已经刷新的位置
4. Unflushed Log
   是log_bytes_written与log_bytes_flushed的差值,表示日志缓存区里还有多少数据没被刷新到日志文件里.
   如果这个差值超过了innodb_log_buffer_size设置的30%,则需要考虑是否加大该参数值.

# Total memory allocated 8824815616; in additional pool allocated 0

1. Total Mem Alloc
   InnoDB申请的总内存量,单位字节
2. Additional Pool Alloc
   分配给额外内存的总量,单位字节

1. InnoDB Row Lock Time
   该模板读取的Innodb_row_lock_time状态变量,表示InnoDB引擎在每次申请数据行锁定时等待的总时间(以毫秒为单位).

1. InnoDB Row Lock Waits
   读取的Innodb_row_lock_waits状态变量,表示InnoDB经过这么长时间才获得一个行锁.(毫秒)

# Number of rows inserted 50678311, updated 66425915, deleted 20605903, read 454561562
大致能表现InnoDB内部的操作

1. Row Read
2. Row Deleted
3. Row Updated
4. Row Inserted

1. InnoDB Sem Wait Time Ms
   显示当前正在等待互斥量的InnoDB线程的等待时间的总耗时(毫秒).
   分析:
   正常情况下,InnoDB Semaphores Wait Time和 InnoDB Semaphores Waits应该是空的.除非服务器运行着高并发的工作负载,它促使InnoDB采取让操作系统等待的措施.信息位于SHOW ENGINE INNODB STATUS的SEMAPHORES片段.
   相关php脚本代码部分如下:

            elseif (strpos($line, ‘seconds the semaphore:‘) > 0) {

            # --Thread 907205 has waited at handler/ha_innodb.cc line 7156 for 1.00 seconds the semaphore:

            increment($results, ‘innodb_sem_waits‘, 1);

            increment($results, ‘innodb_sem_wait_time_ms‘, to_int($row[9]) * 1000);

            }

其中innodb_sem_waits的值是多少,表示有多少线程在等待,而innodb_sem_wait_time_ms表示所有线程等待的时间,默认单位是秒,在脚本中乘以1000,所以监控图中的单位是毫秒.

• 应对这个问题
  InnoDB采取多阶段等待策略.首先,尝试对锁进行循环等待.如果经过了一个预设的循环等待周期(innodb_sync_spin_loops = 30,当前配置文件默认为30次)之后还没有成功,就会退到更昂贵更复杂的等待阵列里,如果并发量太大的话,则导致系统负载突增.
  循环等待的成本相对比较低,但是需要不停地检查一个资源是否被锁定,消耗CPU周期,也就是说,当另外一条线程能处理事情时,循环等待也会独占处理器.
  循环等待的替换方案就是让操作系统做上下文切换(等待阵列),每秒钟几千次的切换会引发大量的系统开销.
• 解决办法
  根据具体的应用,调整参数;或者优化应用,减少并发.

1. InnoDB Sem Waits
   显示当前正在等待互斥量的InnoDB线程的数量.

显示innodb内部的信号活动状态.
包括Mutex spin waits,RW-shared spins,RW-excl spins等各种信号量的数量总和.

1. Spin Rounds
   InnoDB内部预设的互斥量信号数量
2. Spin Waits
   InnoDB内部对锁进行循环等待的数量(与innodb_sync_spin_loops参数有关)
3. Os Wait系统等待
   事务退到操作系统的等待阵列的数量
   在高并发的情况,会发现这个值有尖峰状,不稳定.图像主要显示了,不合理的设计情况下,不同的连接类型之间的行锁或互斥锁的争用.

# mysql tables in use 2, locked 2

1. InnoDB Tables In Use
   所有事务用到的表的数量
2. InnoDB Locked Tables
   所有事务锁定的表的数量

该图显示了InnoDB事务的状态数量.

1. Active Transactions
   正在执行的事务数量
2. Locked Transactions
   锁住的事务数量
3. Current Transactions
   当前的事务数量(包括not started,ACTIVE,...等各种状态)
   not started # 事务已经提交到磁盘
   ACTIVE # 正在执行的事务
4. Read Views(待更新)
   read views open inside InnoDB

显示了InnoDB事务相关的信息

1. InnoDB Transactions
   InnoDB内部的事务总数.由以下数值计算出:
   Trx id counter 89F56195 # 当前事务ID,每创建一个新事务就会累加
   Purge done for trx‘s n:o < 89F5609C undo n:o < 0 # InnoDB清除旧版本MVCC时所用的事务ID.这个ID之前的老版本数据已经清除.
   该数值就是由当前事务ID减去清除旧数据的事务ID再由十六进制转成十进制的值.(参考ss_get_mysql_stats.php脚本902行)
2. History List
   历史记录的长度.位于InnoDB数据文件的撤销空间里的未清除事务的数目.当一个事务执行了更新并提交后,这个数字就会累加,当清除进程移除一个旧版本数据时,它就会递减.

显示了在MyISAM索引上的读写情况

1. Key Reads Requests
   从键缓存读出索引块的读操作的次数
2. Key Reads
   从磁盘读出索引块的读操作次数
3. Key Write Requests
   向键缓存写一个索引块的请求的个数
4. Key Writes
   把索引块写入磁盘的写操作的次数

1. Key Buffer Size
   键缓存大小
2. Key Buf Bytes Used
   同Key_blocks_used变量
   键缓存里已经被使用的缓存块的个数
3. Key Buf Bytes Unused
   同Key_blocks_unused
   键缓存里尚未被使用过的缓存块的个数

1. Binlog Cache Use
   保存在二进制日志缓存里的事务的个数
2. Binlog Cache Disk Use
   超过binlog_cache_size设置的缓存大小,使用磁盘临时文件的事务的个数
3. Binlog Log Space
   二进制日志的大小
4. Relay Log Space
   中继日志的大小

如果Binlog Cache Disk Use/Binlog Cache Use的值较大,那么应该尝试增加binlog_cache_size的大小.但是,也不要期望改善过多,如果写临时文件的数量从每秒1个减少到每分钟一个,这已经证明优化的足够好了.没必要耗费大量的内存,来处理binlog_cache_size中的事务.

命令计数器,显示了MySQL(在过去1秒内)执行各种命令的次数

1. Questions
   记录了服务器收到的查询和命令的总数.(Com_*变量的总数不一定相等.)
2. Com Select
3. Com Delete
4. Com Insert
5. Com Update
6. Com Replace
7. Com Load
8. Com Delete Multi
9. Com Insert Select
10. Com Update Multi
11. Com Replace Select

1. Max Connections
   允许同时保持在打开状态的客户连接的最大个数
2. Max Used Connections
   此前曾同时打开处于打开状态的连接的最大个数
3. Aborted Clients
   因客户端没有正确地关闭而被丢弃的连接的个数
4. Aborted Connects
   试图连接MySQL服务器但没有成功的次数
5. Threads Connectd
   现在正处于打开状态的连接的个数
6. Connections
   试图连接MySQL服务器的尝试次数

1. Table Cache
2. Open Tables
   当前处于打开状态的数据表的个数.不包括TEMPORARY
3. Open Files
   当前处于打开状态的文件的个数,如果与open_files_limit接近,则应该加大open_files_limit的值.
4. Opened Tables
   MySQL服务器已打开的数据表总数(包括显式定义的临时表).如果这个值很高,应该慎重考虑,是否加大数据表缓存(table_open_cache).

1. Handler_writer 向数据表里插入一个数据行的请求的个数
2. Handler_update 对数据表里的一个数据行进行修改的请求的个数
3. Handler_delete 从数据表删除一个数据行的请求的个数
4. Handler_read_first 读取索引中第一个索引项的请求的个数
5. Handler_read_key 根据一个索引值而读取一个数据行的请求的个数
6. Handler_read_next 按索引顺序读取下一个数据行的请求的个数
7. Handler_read_prev 按索引逆序读取前一个数据行的请求的个数
8. Handler_read_rnd 根据某个数据行的位置而读取该数据行的请求的个数
9. Handler_read_rnd_next 读取下一个数据行的请求的个数.如果这个数字很高,就说明有很多语句需要通过全表扫描才能完成或有很多查询没有使用适当的索引

1. Bytes Send
   发送字节数
2. Bytes Received
   收到字节数

http://dev.mysql.com/doc/refman/5.5/en/general-thread-states.html

1. State Closing Tables
   The thread is flushing the changed table data to disk and closing the used tables. This should be a fast operation. If not, verify that you do not have a full disk and that the disk is not in very heavy use.
2. State Copying To Tmp Table
   The server is copying to a temporary table in memory
3. State End
   This occurs at the end but before the cleanup of ALTER TABLE, CREATE VIEW, DELETE, INSERT, SELECT, or UPDATE statements
4. State Freeing Items
   The thread has executed a command. Some freeing of items done during this state involves the query cache. This state is usually followed by cleaning up
5. State Init
   This occurs before the initialization of ALTER TABLE, DELETE, INSERT, SELECT, or UPDATE statements. Actions taken by the server in this state include flushing the binary log, the InnoDB log, and some query cache cleanup operations.
   For the end state, the following operations could be happening:
   Removing query cache entries after data in a table is changed
   Writing an event to the binary log
   Freeing memory buffers, including for blobs
6. State Locked
   The query is locked by another query.
   As of MySQL 5.5.3, this state was removed because it was equivalent to the Table lock state and no longer appears in SHOW PROCESSLIST output.
7. State Login
   login
   The initial state for a connection thread until the client has been authenticated successfully.
8. State Preparing
   This state occurs during query optimization.
9. State Reading From Net
   The server is reading a packet from the network.
10. State Sengding Data
    The thread is reading and processing rows for a SELECT statement, and sending data to the client. Because operations occurring during this this state tend to perform large amounts of disk access (reads), it is often the longest-running state over the lifetime of a given query.
11. State Sorting Result
    For a SELECT statement, this is similar to Creating sort index, but for nontemporary tables
12. State Statistics
    The server is calculating statistics to develop a query execution plan. If a thread is in this state for a long time, the server is probably disk-bound performing other work.
13. State Updating
    The thread is searching for rows to update and is updating them
14. State Writing To Net
    The server is writing a packet to the network.
15. State None
    什么都没有的,空的,注意不是NULL状态
16. State Other
    其他

Percona文档

Percona文档

默认用SHOW SLAVE STATUS命令获取各状态值

1. Slave Running
   从服务器的I/O线程和SQL线程是否在运行
2. Slave Stopped
3. Slave Lag
   复制延迟
4. Slave Open Tmp Tables
   从服务器中的SQL线程曾经打开的临时文件的个数
5. Slave Retried Transactions
   从服务器中的SQL线程重新尝试执行一个事务的次数

1. Select Full Join
   没有使用索引而完成的多表联接操作的次数.这种情况是性能杀手,最好去优化sql.
2. Select Full Range Join
   利用一个辅助性的参照表(reference table)上的区间搜索(range search)操作而完成的多数据表联接操作的次数.
   该值表示使用了范围查询联接表的次数.
3. Select Range
   利用第一个数据表上的某个区间而完成的多数据表联接操作的次数.
4. Select Range Check
   该变量记录了在联接时,对每一行数据重新检查索引的查询计划的数量,它的开销很大.
   如果该值较高或正在增加,说明一些查询没有找到好索引.
5. Select Scan
   通过对第一个数据表进行全表扫描而完成的多数据表联接操作的次数.

1. Sort Rows
   对多少行排序
2. Sort Range
   利用一个区间进行的排序操作的次数
3. Sort Merge Passes
   查询导致了文件排序的次数.可以优化sql或者适当增加sort_buffer_size变量
4. Sort Scan
   利用一次全表扫作而完成的排序操作的次数

1. Table Locks Immediate
   无需等待就能够立刻得到满足的数据表锁定请求的个数
2. Table Locks Waited
   显示了有多少表被锁住了并且导致服务器级的锁等待(存储引擎级的锁,如InnoDB行级锁,不会使该变量增加).
   如果这个值比较高或者正在增加,那么表明存在严重的并发瓶颈.
3. Slow Queries
   慢查询的次数(执行时间超过long_query_time值)

1. Created_tmp_tables
   MySQL服务器在对SQL查询语句进行处理时在内存里创建的临时数据表的个数.
   如果该值太高,唯一的解决办法是:优化查询语句.
2. Created_tmp_disk_tables
   MySQL服务器在对SQL查询语句进行处理时在磁盘上创建的临时数据表的个数,如果这个值比较高,可能的原因:
   a.查询在选择BLOB或者TEXT列的时候创建了临时表
   b.tmp_table_size和max_heap_table_size的值也许太小
3. Created_tmp_files
   MySQL服务器所创建的临时文件的个数

1. Thread Cache Size
   线程缓存所能容纳的线程的最大个数.断开的mysql连接会放到这个缓存里,新建立的连接就会重复使用它们而不创建新的线程.
   如果缓存中有自由的线程,MySQL就能很快的响应连接请求,不必为每个连接都创建新的线程.每个在缓存中的线程通常消耗256KB内存.
2. Thread Created
   为处理连接创建的线程总数

1. Handler Commit
   提交一个事务的请求的个数
2. Handler Rollback
   回滚一个事务的请求的个数
3. Handler Savepoint
   创建一个事务保存点的请求的个数
4. Handler Savepoint Rollback
   回滚到一个事务保存点的请求的个数.

参考:
http://www.percona.com/doc/percona-monitoring-plugins/cacti/mysql-templates.html
http://www.mysqlperformanceblog.com/2006/07/17/show-innodb-status-walk-through/
以Percona提供的模板为例.其中信息获取命令如下(不包括pt-heartbeat).

SHOW /*!50002 GLOBAL */ STATUS;

SHOW VARIABLES;

SHOW SLAVE STATUS;

SHOW MASTER LOGS;

SHOW PROCESSLIST;

SHOW /*!50000 ENGINE*/ INNODB STATUS;