MYSQL 监控 performance_schema 拿得起 不放下（1））

行业解决方案、产品招募中！想赚钱就来传！>>>

随着MYSQL的脚步越来越快，（更新的速度），觉得原来的监控的方式是不是也需要进行进一步的探索，当然现在的监控市场云龙混杂，成型的模式例如 percona pmm, 还有国产的蓝鲸，但这些监控在好，方式在炫酷，但也不能阻挡对数据库底层的监控的知识掌握，否则就只能看图说话，让人心里不踏实。另外很多公司的监控指标还需要灵活对待，不知道底层的监控参数输出，有怎么能开发出自己的监控系统。

其实performance_schema 这个功能是在MYSQL 5.6 开始，并且在MYSQL 5.7 走向成熟的。mysql 的某些监控是越来越依赖 performance_schema   中的数据。

mysql 8  mysql 5.7 部分版本默认是打开的，验证相关的 MYSQL 到底打没有打开performance_schema, 执行下面的语句即可

 SHOW VARIABLES LIKE 'performance_schema';

具体 performance_schema 有那些功能模块我们可以捋一捋

1 与事件有关的信息统计是一个大板块，并且从中每个项目对主机， 账号，线程，用户，整体都有相关维度的数据统计。

2  与内存有关的模块，也是针对主机，账号，线程用户，以及整体有相关的数据统计

3  与复制有关的信息，这也是performance_schema 中的一个大块

4  设置performance_schema 信息收集的开关选择项

5  与具体性能参数有关的部分 VIEWS

6  杂项

曾经听到不少从业人士对于 performance_schema 的bug 和 曾经的系统性能的消耗，嗤之以鼻，实际上随着 ORACLE 整体的规划，performance_schema 是获取系统性能及相关信息的必选项，所以开和不开这个问题，就不用在讨论了。

以下使用MYSQL 8.109的performance_schema 的内容作为基准，看看到底performance_shcema 能给我们解决什么问题。

首先要说明的，即使performance_schema本身是ON 的状态，但各项指标数据的收集并不是全部打开的。

其中 setup_instruments 是对各种的指标的收集参数是否打开，实际上有些参数可能在某些情况下不应该被收集，例如如果你没有使用GR,则下面的例如x_com_cache 是不需要进行数据的收集的。

说了这么多，没有实际的案例，估计是形成不了对performance_schema整体的认知。

下面就是一个通过打开 performance_schema 中的 

通过上面的脚本是可以格式化慢查询的输出，（需要打开 performance_schema.events_statements_history），

或者继续通过 events_statements_history  表来将查询中没有使用索引的语句抓出来。

另外通过 performance_schema 还可以达到早先分析SQL 中使用profiling 的功能，例如你想知道某个在语句查询中那个环节最耗费时间，也可以用下面的语句来解决。

基本上每个语句在整体查询阶段中，最耗时的点都会告诉你。图中大部分都是在sending data中耗时最多，基本上在0.03 秒左右。稍加修改，对数据库中的语句某些敏感点的注意就可以进行观察，例如执行计划的生成时间比较长，就可以作为一个点，来进行观察。

其实本身对于metadata lock 的监控也有关系统的性能的状态，例如对表进行DDL 操作，则此时可以对metadata lock 进行监控，查看当前的系统的metadata lock的状态和赋予的锁类型。

实际上今天的部分预计仅仅是与performance_schema 获得系统的信息的一小部分，通过performance_schema 在MYSQL 8.0 更是可以获得类似 clone中的processing 的信息，当然还有更有意思的sys库。

以下是一些上面的SQL 语句

——————————————————————————————

SELECT

CONCAT_WS(

'','# Time: ', date_format(CURDATE(),'%y%m%d'),' ',TIME_FORMAT(NOW(6),'%H:%i:%s.%f'),'\n'

,'# User@Host: ',t.PROCESSLIST_USER,'[',t.PROCESSLIST_USER,'] @ ',PROCESSLIST_HOST,' []  Id: ',t.PROCESSLIST_ID,'\n'

,'# Schema: ',CURRENT_SCHEMA,'  Last_errno: ',MYSQL_ERRNO,'  ','\n'

,'# Query_time: ',ROUND(s.TIMER_WAIT / 1000000000000, 6),' Lock_time: ',ROUND(s.LOCK_TIME / 1000000000000, 6),'  Rows_sent: ',ROWS_SENT,'  Rows_examined: ',ROWS_EXAMINED,'  Rows_affected: ',ROWS_AFFECTED,'\n'

,'# Tmp_tables: ',CREATED_TMP_TABLES,'  Tmp_disk_tables: ',CREATED_TMP_DISK_TABLES,'  ','\n'

,'# Full_scan: ',IF(SELECT_SCAN=0,'No','Yes'),'  Full_join: ',IF(SELECT_FULL_JOIN=0,'No','Yes'),'  Tmp_table: ',IF(CREATED_TMP_TABLES=0,'No','Yes'),'  Tmp_table_on_disk: ',IF(CREATED_TMP_DISK_TABLES=0,'No','Yes'),'\n'

, t.PROCESSLIST_INFO,';')

FROM performance_schema.events_statements_history s

JOIN performance_schema.threads t using(thread_id)

WHERE

t.TYPE = 'FOREGROUND'

AND t.PROCESSLIST_INFO IS NOT NULL

AND t.PROCESSLIST_ID != connection_id()

ORDER BY t.PROCESSLIST_TIME desc;

———————————————————————————————

SELECT THREAD_ID TID, SUBSTR(SQL_TEXT, 1, 50) SQL_TEXT, ROWS_SENT RS,ROWS_EXAMINED RE,CREATED_TMP_TABLES,NO_INDEX_USED,NO_GOOD_INDEX_USED FROM performance_schema.events_statements_history WHERE NO_INDEX_USED=1 OR NO_GOOD_INDEX_USED=1\G

———————————————————————————————

SELECT eshl.event_name, sql_text, eshl.timer_wait/1000000000000 w_s FROM performance_schema.events_stages_history_long eshl JOIN performance_schema.events_statements_history_long esthl ON (eshl.nesting_event_id = esthl.event_id) WHERE eshl.timer_wait > 1*10000000000\G

———————————————————————————————

select t.processlist_id, m.object_type, m.lock_type, m.lock_status, m.source,pr.info  

from performance_schema.metadata_locks as m

join performance_schema.threads as t on (m.owner_thread_id=t.thread_id)  

join information_schema.processlist as pr on pr.id = t.processlist_id;

本文分享自微信公众号 - AustinDatabases（AustinDatabases）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。