最近一段时间和MYSQL的 performance_schema 较劲，之前总结的比较散，没有一个整体的观，仅仅是细枝末叶的东西。本次的对performance_schema 从总体来看，看看未来（MYSQL 8），以后观察MYSQL的性能问题需要什么改变。招招毙命其实是对老的监控方法来用“吸引体”来 attractiveness。
从MYSQL5.6 开始performance_schema 越来越受到重视，但之前以一直有一种观念就是，尽量不要开 performance_schema, 主要由以下原因，系统资源的消耗，和莫名的故障。导致 performance_schema 一直不是一个能被拿上桌面的系统性能观察的通用方法。
如果是因为初期的BUG 的问题，不开启performance_schema 我是同意的，而因为performance_schema 消耗系统资源，而不开，这点其实我不敢苟同，一个系统的性能的监控就是要一直进行，并且既然是监控一定是对系统有损耗的，为了不损耗，而不监控，我不知道是哪门子的道理，如果系统的资源消耗是可控的，并且在初期的系统建设我们就将这部分资源算进系统的消耗，不就可以了
到了MYSQL 5.7 performance_schema的监控的方式和数据越来越重要，并且他变得设置更灵活。大致MYSQL的5.7的performance_schema 的控制要更方便。当然也要有规划。下面粗略的划分了一下，其实还可以细分。下面就先对这些模块的大致功能来说说。
1 Event 系列无疑是要占一大块的份额，event 也足以可以进行一个分类
event 的划分分为两个维度， 1 统计信息的类别 2 统计信息的以时间为一个存放类别
从统计信息的类别看，stages , statements , transactions ,waits 这四类，而存储的方式也有当前，历史，较远的历史信息这三类，当然还有各种通过统计分析后，针对账号，主机，线程，用户，等等的信息summary.
这里举一个列子，因为东西太多，如果每个都举例子就变成说明书了。
events_transactions_current 我们以这个为例，通过下面的语句，你当前的事务的运行时间，你大概应该有一个数了，thread_id 你也有了，如果你在能统计到你运行时间对应的 statement ,那现在的慢查询方式是不是可以准备抛弃了（有一篇曾经写过关于传统慢查询的方式抛弃的文字）
select thread_id,event_name,state,trx_id,timeR_wait/1000000000000 as wait_second from events_transactions_current;
我们在加以利用，我们是不是可以追踪到，一个列表，关于事务等待的时间的曲线图（尤其对新上线的系统，通过曲线图出现问题的第一时间就可以开始进行故障的排查，而不必等呀等，而且二次开发一个慢查询的系统我想也不是一件难事）
稍加改造，看看一点也不会比ORACLE 或者 SQL SERVER 某些功能差到哪里去。 （有所感悟，MYSQL（包括PG）的变化快，并且目前还处于一个急速上升期，和 ORACLE SQL SERVER 不同，不紧跟是步步跟不上）
2 setup
提到被诟病的 performance_schema 侵占MYSQL 性能的问题，虽然个人观点，这并不是一个问题（除了BUG，我没说BUG 不是问题）。 正常的性能侵占是应该被容忍的，但我们也不能想怎样就怎样，我们也应该有度的使用 performance_schema。
下面就说说怎来
从用户的角度来进行过滤，有些信息是可以不进行记录的，例如你认为系统已经稳定，我就只需要对一些新的业务进行监控，那怎么办？？
第一招，通过过滤应用账号来进行过滤，通过setup_actors 表来控制
如果我们将默认的全表同意收集，改为，通过账号来进行过滤，自然相对的信息收集会有一个。
第二式，对某些事件的过滤， 有人爱吃甜，有人爱吃酸，你既可以对进入的数据源进行控制，也可以对进入的信息进行一个挑选。
参见上图信息我们可以对目前setup_consumers 中列出的 events 的信息进行过滤，直接UPDATE 就可以。
第三招，我们采用更细的粒度，对instruments 进行信息的过滤。他有两个过滤的粒度， 1 对于过滤类似 events_waits_summary_by_account_by_event_name 这样的数据，我们对于他的控制可以从两个方面来， ONE event_name 我们可以将一些我们不需要的event 进行过滤不在收集他的信息，另一种是对timer 进行控制，将某些关于时间有关的信息收集（减小收集的频度），进行控制。
例如我们可以对 wait/synch/mutex/sql/Event_scheduler::LOCK_scheduler_state这个事件的监控停止，（因为MYSQL 我们根本不用 event_scheduler ）
第四招，对数据库的OBJECTS 进行控制，通过 setup_objects我们可以对某些数据库的项目进行隔绝，例如，如果你数据库中根本就没有存储过程，没有函数，没有trigger （一般都没有） 自然我们就将这些性能的捕捉关停。
通过上面四招，我们可以大大化解performance_schema 对系统的资源消耗，同时也能通过performance_schema 进行系统的监控，何乐不为。当然是写语句，还是在CNF 中设置，那就要看这样的需求稳定不稳定了。
另外还有一个MYSQL 早期版本不具备的功能，对于索引的一个使用usage rate占用 IO 的统计。
select * from table_io_waits_summary_by_index_usage
通过这个统计是可以对数据库中的表使用索引的，以及没有使用索引的I/O的分布情况有一个明确的数字作为指导，通过这个表可以详细了解当前的数据库是不是可能存在缺少索引的情况。
今天就先到这里，其实关于performance_schema 里面的东西还有很多，如果感兴趣可以继续挖掘，对以后系统的性能判断和问题的查找都有好处， 另外最近看到很多，12小时学懂MYSQL ， 21天成为MYSQL高手这样的书籍和网课，其实倒不是对这些课程有什么意见，只是怕误导一些人认为MYSQL 很好学，几天的功夫就OK 了，个人经验包括 SQL SERVER ORACLE ，PG ，MONGODB ，这些数据库，都没有那么容易，里面的“坑”， 都是通过成年累月的经验和各种挨骂，提心吊胆过来的，短短的某个课程，可以让不懂的人，知道某些知识，任何知识的积累都是通过不懈的努力和各种委屈组成的。
顺便说一句，performance_schema 开启使用查查 mysql bugs ，有些版本的MYSQL 开启了后，会有OOM的情况。
