其实说到监控，无非两个目的，报警与解决问题。英文表达 metrics and alerts ，所以监控的指标那就的分两种，1 触发到某个设定值就要报警，因为要出事了，2 记录每一时刻的值，发现问题好对其进行分析，发现问题解决问题。
OK 弄清楚这两点后，一般来说MYSQL 监控的方向分为三点 1 应用需要的资源 2 资源的使用率与限制 3 被执行的查询
下面就来一轮问和答
问题1 MYSQL 中的参数 queries 和 quesions 到底我监控那个才能得知当前系统的执行的SQL 数？
从定义上看着Queries 是包含存储过程，并且不包含 com_ping 和 com_statistics ，而Questions 则是包含大量Com 操作的。那到底使用那个作为展示的参数？ 一般会使用 quersions 的值作为一个监控值，例如pmm 中并没有 queries 而选择显示的是 questions 作为一个数据库执行语句的监控值。
另外还有一些监控选择了，Com_insert + Com_update + Com_delete 方式来记录 MYSQL 中 的 dml 操作，Com_select 记录查询的操作，将具体的操作分开监控也是一个好的方法。
问题 2 怎么检查MYSQL 的连接数及周边
问：我通过Connections 的增减量来判断当前的连接数可以吗？
通过Connections 当然是可以查看一定时间尝试连接MYSQL的连接数量，但实际上大多来监控MYSQL 的连接数的方式
通过 Thread cache 来进行查看
实际通过 threads 来监控，通过threads 监控可以查看几个指标，
1 通过 threads_connected 可以看到你当前数据库系统中的连接数
2 treads_cached 当前线程池中的缓存有多少空闲的线程
通过上面两个参数你可以解决
1 当前有多少连接
2 你的 thread_cache_size 到底设置的够不够，如果你的 threads cached 已经剩下的不多，就要考虑添加你的 thread_cache_size了
3 问：我需要观察创建临时表的问题吗？
我想应该的监控，尤其create temp disk tables 变得很多的情况下
想想如果你的大量的表都是在磁盘上建立的tmp 那结果一定是不怎么样，
所以保证大部分的临时表都能在内存中建立是一个性能不错的标志。
如果很糟糕的话，就要考虑 例如 MAX_TMP_TABLES 以及tmp_table_size 两个参数的设置，以及好好看看你的执行那些SQL 语句里面有没有“”怪胎”
4 问: 我如果在不关注慢查询的情况下，我怎么能快速得知当前系统中有多少不大好的语句。
一般在系统中如果有全表扫描，或者JOIN 的无索引扫描表，是最令人痛恨的，那统计一段时间这样的语句的数量，这个系统怎么样，大致就有点斤两了。
那么统计 select_scan select_fulll_join 以及 select_full_range_join 等这些语句的执行数据量是可以作为一个系统中，这几个值中尤其要关注 select_full_join 基本上一个优秀的系统，这个值应该是0
另外还有sort scan 通过扫描整张表来获得的排序，这个也是要好好看看这些语句都是怎么写的。
当然最后也是可以通过 slow_queries 来进行当前慢查询语句数据的检测。
所以通过上面的这些监控项目大致就可以全方位的了解当下系统的与语句有关的情况。
5 问 总有开发问我当前系统的锁多不多，我怎么回答？
锁分为正常的SQL 语句执行时需要的锁以，可以通过以下的参数来监控以下，并回答部分问题
1 table_lock_waited 如果这个值比较高的话，就说明等待表锁的情况比较多，就需要关注了。
2 查看当前INNODB 的行级锁的情况
innodb_row_lock_time_avg 平均每次锁等待的时间单位毫秒
innodb_row_lock_waits 查询语句等待行锁的时间 单位毫秒
3 同时还有另外一个锁，就是死锁，死锁时怎么监控，当然你可以使用工具，但在监控上怎么显示你当前的死锁，这里面每个版本的MYSQL 就不大一样的，有的是可以打上count deadlock patch 来记录死锁，或者使用 metrics表来记录
基本上通过上面的状态就可以覆盖大部分范围了。
6 系统运行慢的时候，经常有人问，内存的状态怎么样， 我一般怎么回答？
关于内存的状态，其实还是蛮有讨论的余地，
首先观察的第一个敏感的位置是 Innodb_buffer_pool_bytes_data， 对比你现在的innodb_buffer_pool_size 的大小，你当前的内存使用在一个什么位置要有一个对比，另外有可能你使用的 innodb_buffer_pool 超过当初的设置的值10% 也是有可能的，innodb_buffer_pool_size 不是一个强行值可能会有超过设置值的情况，这时候你就要考虑内存到底设置够不够用的问题了。
就需要考虑另一个buffer hit 的量了， 1- 一般可以通过去磁盘提取数据的量比对程序运行中需要读取的数据量 * 100 。
（1 - innodb_buffer_pool_read/innodb_buffer_pool_read_requests） * 100 一般如果低于95，就需要考虑内存的性能问题了
除此之外，adptive hash index size 也会使用大量大的内存，这点也要进行监控。
今天先说道这里
待 .......
