一、MySQL性能监控关注点
QPS（每秒Query 量）：这里的QPS 实际上是指MySQL Server 每秒执行的Query总量：
QPS = Queries / Seconds
TPS（每秒事务量）： 在MySQL Server 中并没有直接事务计数器，我们只能通过回滚和提交计数器来计算出系统的事务量。所以，我们需要通过以下方式来得到客户端应用程序所请求的TPS 值：
TPS = (Com_commit + Com_rollback) / Seconds
Key Buffer 命中率：Key Buffer 命中率代表了MyISAM 类型表的索引的Cache命中率。该命中率的大小将直接影响MyISAM 类型表的读写性能。Key Buffer 命
中率实际上包括读命中率和写命中率两种，MySQL 中并没有直接给出这两个命中率的值，但是可以通过如下方式计算出来：
key_buffer_read_hits = (1 - Key_reads / Key_read_requests) * 100%
key_buffer_write_hits= (1 - Key_writes / Key_write_requests) * 100%
Innodb Buffer 命中率：这里Innodb Buffer 所指的是innodb_buffer_pool，也就是用来缓存Innodb 类型表的数据和索引的内存空间。类似Key buffer，我们
同样可以根据MySQL Server 提供的相应状态值计算出其命中率：
innodb_buffer_read_hits=(1-Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests) * 100%
Query Cache 命中率：如果我们使用了Query Cache，那么对Query Cache 命中率进行监控也是有必要的，因为他可能告诉我们是否在正确的使用Query Cache。
Query Cache 命中率的计算方式如下：
Query_cache_hits= (Qcache_hits / (Qcache_hits + Qcache_inserts)) * 100%
Table Cache 状态量：Table Cache 的当前状态量可以帮助我们判断系统参数table_open_cache 的设置是否合理。如果状态变量Open_tables 与Opened_tables 之间的比率过低，则代表Table Cache 设置过小：
SHOW STATUS LIKE 'Open%';
Thread Cache 命中率：Thread Cache 命中率能够直接反应出我们的系统参数thread_cache_size 设置的是否合理。一个合理的thread_cache_size 参数能够
节约大量创建新连接时所需要消耗的资源。
Thread Cache 命中率计算方式如下：
Thread_cache_hits = (1 - Threads_created / Connections) * 100%
锁定状态：锁定状态包括表锁和行锁两种，我们可以通过系统状态变量获得锁定总次数，锁定造成其他线程等待的次数，以及锁定等待时间信息。
SHOW STATUS LIKE '%lock%';
通过锁相关的系统变量，我们可以得出表锁总次数，其中造成其他现线程等待的次数。同时还可以得到非常详细的行锁信息，如行锁总次数，行锁总时间，每次行锁等待时间，行锁造成最大等待时间以及当前等待行锁的线程数。通过对这些量的监控，我们可以清晰的了解到系统整体的锁定是否严重。如当Table_locks_waited 与Table_locks_immediate 的比值较大，则说明我们的表锁造成的阻塞比较严重，可能需要调整Query 语句，或者更改存储引擎，亦或者需要调整业务逻辑。当然，具体改善方式必须根据实际场景来判断。而Innodb_row_lock_waits 较大，则说明Innodb 的行锁也比较严重，且影响了其他线程的正常处理。同样需要查找出原因并解决。造成Innodb 行锁严重的原因可能是Query 语句所利用的索引不够合理（Innodb 行锁是基于索引来锁定的），造成间隙锁过大。也可能是系统本身处理能力有限，则需要从其他方面（如硬件设备）来考虑解决。
复制延时量：复制延时量将直接影响了Slave 数据库处于不一致状态的时间长短。
在Slave 节点上执行“SHOW SLAVE STATUS”命令，取Seconds_Behind_Master 项的值来了解Slave 当前的延时量（单位：秒）。
Tmp table 状况：Tmp Table 的状况主要是用于监控MySQL 使用临时表的量是否过多，是否有临时表过大而不得不从内存中换出到磁盘文件上。临时表使用状态信息可以通过如下方式获得：
SHOW STATUS LIKE 'Created_tmp%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
| Created_tmp_tables | 0 |
+-------------------------+-------+
如果Created_tmp_tables 非常大，则可能是系统中排序操作过多，或者是表连接方式不是很优化。而如果是Created_tmp_disk_tables Created_tmp_tables 的比率过高，如超过10%，则我们需要考虑是否tmp_table_size 这个系统参数所设置的足够大。
Binlog Cache 使用状况：Binlog Cache 用于存放还未写入磁盘的Binlog 信息。
相关状态变量如下：
SHOW STATUS LIKE 'Binlog_cache%'；
Binlog_cache_disk_use 值不为0，则说明Binlog Cache 大小可能不够，可以增加binlog_cache_size 系统参数大小。