最近在和MYSQL的监控方法的事情在嫐裱，深感周遭的事情变化快，一步跟不上就的紧倒持。
今天继续 MYSQL 中的 performance_schema 熟悉的过程。
1 线程的连接，在MYSQL的某些监控中是至关重要的，如果某个开发在上线某个程序后，发现MYSQL无法登陆了，除了你要预留一个额外的端口给你上去处理这个事情，那第二个事情就是要赶紧得到你MYSQL的连接数，因为很可能是，烂SQL，造成的连接数已经耗尽。我们可以通过
select * from performance_schema.accounts;
来进行一个信息的查询,当前有多少连接，历史连接数，我们通过这个信息在zabbix做一个监控是很容易的事情，当然还有另外一个和技术无关的事情，就是账号的问题，卖个关子，再好的技术都不得不匹配一个良好的管理，什么管理？？？ 否则就算查到这个信息，你也不得而知是那个应用惹的祸。
select thread_id,event_id,end_event_id,event_name,timer_start/1000000000000 as timer_start_s,timer_end/1000000000000 as timer_end_s,(timer_wait/1000000000000) as timer_wait_s,work_estimated from events_stages_history limit 1;通过上面的查询可以查看时间的历史记录以及相关时间的等待时间，监控某些关键指标可以发现某些问题。（具体哪些问题，需要自己去找到 event_name中你关注的）
SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6) as Duration, SQL_TEXT FROM performance_schema.events_statements_current where SQL_TEXT IS NOT NULL AND SQL_TEXT <> 'BEGIN';
上面的语句可以在进行修改，可以获得更准确的信息，如果在定时去做，是可以将古老的慢查询方式替换的。
select user,host,event_name,count_alloc,count_free,sum_number_of_bytes_alloc/1000/1000 as sum_number_of_MB_alloc,sum_number_of_bytes_free/1000/1000 as sum_number_of_bytes_free_MB,current_number_of_bytes_useD/1000/1000 as current_number_of_MB_USED from memory_summary_by_account_by_event_name where count_alloc <> 0 and USER = 'app_collection' ORDER BY current_number_of_bytes_used desc limit 10;
另外还有一些DBA 可能平时需要使用的东西，例如有人问你，我们的生产数据库中是否存在一个 叫 XXX 的表，或者函数，或者存储过程等等之类的，你如何去快速响应
或者你目前系统中，数据库操作文件的等待时间
select event_name,(avg_timer_wait/1000000000000) as avg_timer_wait_s from file_summary_by_event_name where min_timer_wait <> 0 limit 20;
最后performance_schema中的表很多，越新版本的MYSQL 会在这里给我们更多的信息。
这里我们总结一下，这里的表的大致类型
Setup_table 配置表
current_events_table 记录当前线程发生了什么
history_table 发生事件的历史记录
summary_table 对各种事件的统计表
setup_intruments 为当前数据库是否开启了某项监控
setup_timers 监控的采样率
以上的内容让我想起，去年interview某个人问我的问题，问题是MYSQL 中有类似ORACLE AWR 报告之类的东西，当时告诉他的是不可以，没有，其实细想想，虽然没有现成的AWR，我们是不是可以通过某些脚本，或PYTHON程序自己搞出一个 MYSQL 的AWR ，现在想想，这并不是一个问题。
