MYSQL performance_schema 中的 statement 系列表获得慢查询信息

开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群（共700人左右 1 + 2）。

最近开始设计公司的MYSQL 慢查询系统，因为数据库都在云上，并且还有POLARDB 所以根本不会考虑什么慢查询日志的问题，并且整体的mysql大部分都在mysql 8 ，所以基本上这个系统中的设计就全部抛弃了慢查询日志。

在设计中，今天一个同事提出我写的其中一个表events_statements_history是瞬时记录，很快就会被生产系统的更多的数据覆盖，为了确认这个问题，我需要重新温习这个部分的知识，并调理的梳理这个知识体系。

event_statements 表系列之间的关系

在event_statements 开头语语句执行和记录有关的表有三个分别是

1  events_statements_current

2  events_statements_history

3  events_statements_history_long

这三个表之间的关系，与功能分别为

每个MYSQL的工作的线程中，都在时时刻刻的运行SQL语句，而当前这个线程正在运行的语句就都记录在 events_statements_current中，在这个表中，为每个线程正在运行的SQL都建立了一行进行记录。

而与此派生出来的表  events_statements_history 是每个线程存储的当前的执行的语句，而每个线程执行的语句默认在这个events_statements_history中是存储10条的，超过10条后的语句，就会覆盖之前的语句。

所以每个线程最大可以存储10条最近运行的语句，这两个参数必须在系统启动前调整，是不能进行动态调整的。

+--------------------------------------------------------+-------+
| Variable_name                                          | Value |
+--------------------------------------------------------+-------+
| performance_schema_events_statements_history_long_size | 10000 |
| performance_schema_events_statements_history_size      | 100   |
+--------------------------------------------------------+-------+

所以如果想从events_statements_history表中获取信息，可以调整 size 变得更大一点，但这会影响到系统的性能，所以系统已经负荷很重的情况下，就需要跳过这个部分，可以直接跳到下一个系统表，events_statements_history_long， events_statements_history_long 表是记录当前数据库中全局的语句执行的情况，与 events_statements_history是记录每个线程的的负载情况，而events_statements_history_long 是记录MYSQL服务器中所有的语句执行的负载的情况。

所以查询慢查询语句最好的选择，并不是events_statements_history ,而应该从events_statements_history_long 中去寻找。本身这个表也有调整存储数据的行数的变量performance_schema_events_statements_history_long_size

默认存储是1万条执行的语句，通过不断的遍历表来获得执行语句的信息，并从中不断找到超过你制定标准的语句。

如下的字段对于分析语句的运行都有相关的指向性，需要注意的是timer_wait使用的是单位是皮秒 需要进行处理

  `TIMER_WAIT` bigint unsigned DEFAULT NULL,
  `LOCK_TIME` bigint unsigned NOT NULL,
  `SQL_TEXT` longtext,
  `DIGEST` varchar(64) DEFAULT NULL,
  `DIGEST_TEXT` longtext,
  `CURRENT_SCHEMA` varchar(64) DEFAULT NULL,
  `OBJECT_SCHEMA` varchar(64) DEFAULT NULL,
  `ROWS_SENT` bigint unsigned NOT NULL,
  `ROWS_EXAMINED` bigint unsigned NOT NULL,
  `CREATED_TMP_DISK_TABLES` bigint unsigned NOT NULL,
  `SELECT_SCAN` bigint unsigned NOT NULL,
  `SORT_RANGE` bigint unsigned NOT NULL,
  `SORT_ROWS` bigint unsigned NOT NULL,
  `SORT_SCAN` bigint unsigned NOT NULL,
  `NO_INDEX_USED` bigint unsigned NOT NULL,
  `NO_GOOD_INDEX_USED` bigint unsigned NOT NULL,

最后的一张表是events_statements_summary_by_digest 这张表是一个语句的汇总表，称为汇总表的主要的原因是这张表是一个基于之前讲到的表的信息的汇总和总结，通过schema 和 digest 两个方面来进行信息的汇总，他会将同一个schema  （database 逻辑库） 下的同类型的结构的语句进行一个汇总，将语句的平均执行时间和最大，最小的执行的时间进行一个展示，同时与上面的表相同的部分是 通过 perfromance_schema_digests_size 来对数据表中的数据进行存储的设置，默认是10000条数据存储，超过这个数值，将对之前的数据进行覆盖。

最终三个表在慢查询和系统分析系统中的定位如下
 events_statements_history_long | CREATE TABLE `events_statements_history_long` (
  `THREAD_ID` bigint unsigned NOT NULL,
  `EVENT_ID` bigint unsigned NOT NULL,
  `END_EVENT_ID` bigint unsigned DEFAULT NULL,
  `EVENT_NAME` varchar(128) NOT NULL,
  `SOURCE` varchar(64) DEFAULT NULL,
  `TIMER_START` bigint unsigned DEFAULT NULL,
  `TIMER_END` bigint unsigned DEFAULT NULL,
  `TIMER_WAIT` bigint unsigned DEFAULT NULL,
  `LOCK_TIME` bigint unsigned NOT NULL,
  `SQL_TEXT` longtext,
  `DIGEST` varchar(64) DEFAULT NULL,
  `DIGEST_TEXT` longtext,
  `CURRENT_SCHEMA` varchar(64) DEFAULT NULL,
  `OBJECT_TYPE` varchar(64) DEFAULT NULL,
  `OBJECT_SCHEMA` varchar(64) DEFAULT NULL,
  `OBJECT_NAME` varchar(64) DEFAULT NULL,
  `OBJECT_INSTANCE_BEGIN` bigint unsigned DEFAULT NULL,
  `MYSQL_ERRNO` int DEFAULT NULL,
  `RETURNED_SQLSTATE` varchar(5) DEFAULT NULL,
  `MESSAGE_TEXT` varchar(128) DEFAULT NULL,
  `ERRORS` bigint unsigned NOT NULL,
  `WARNINGS` bigint unsigned NOT NULL,
  `ROWS_AFFECTED` bigint unsigned NOT NULL,
  `ROWS_SENT` bigint unsigned NOT NULL,
  `ROWS_EXAMINED` bigint unsigned NOT NULL,
  `CREATED_TMP_DISK_TABLES` bigint unsigned NOT NULL,
  `CREATED_TMP_TABLES` bigint unsigned NOT NULL,
  `SELECT_FULL_JOIN` bigint unsigned NOT NULL,
  `SELECT_FULL_RANGE_JOIN` bigint unsigned NOT NULL,
  `SELECT_RANGE` bigint unsigned NOT NULL,
  `SELECT_RANGE_CHECK` bigint unsigned NOT NULL,
  `SELECT_SCAN` bigint unsigned NOT NULL,
  `SORT_MERGE_PASSES` bigint unsigned NOT NULL,
  `SORT_RANGE` bigint unsigned NOT NULL,
  `SORT_ROWS` bigint unsigned NOT NULL,
  `SORT_SCAN` bigint unsigned NOT NULL,
  `NO_INDEX_USED` bigint unsigned NOT NULL,
  `NO_GOOD_INDEX_USED` bigint unsigned NOT NULL,
  `NESTING_EVENT_ID` bigint unsigned DEFAULT NULL,
  `NESTING_EVENT_TYPE` enum('TRANSACTION','STATEMENT','STAGE','WAIT') DEFAULT NULL,
  `NESTING_EVENT_LEVEL` int DEFAULT NULL,
  `STATEMENT_ID` bigint unsigned DEFAULT NULL
) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci |

1  events_statements_history    （快速瞬时的收集信息，在发生系统性能问题的时候）

2  events_statements_history_long  （高频在业务高峰期，进行数据的获取和收集，方便分析可预见的问题）

3  events_statements_summary_by_digest  （中频，或低频的进行数据的获取） 对比 events_statements_history_long 或 events_statements_history 来发现问题是长期性的还是短期性质的。

最后整体的慢查询系统，明天还的修改设计，但这三张表的在慢查询系统中的功能用处，通过学习已经清晰了。

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

最近看行业中人，写了自己的爱好，个人有同感，人都有多面性，所以后面每个数据库的文章后面可能不定期的有我的一些小爱好的短小的文字。

想想大部分阅读文章的同学都有汽车，而不少人对汽车的感觉就是一个交通工具，但在有的人心里，他不是一个单纯的交通工具。今天我们来简短的说说，你回家的路上可能会遇上的，低调的钢炮，你买得起的钢炮。

先解释一下什么是钢炮，比如你在正常开车，而你后面突然串出一辆“车”，你觉得是素车，但是瞬间消失在你眼前，你连尾灯都看不到的车，这就是钢炮感受定义。

那么来说我们常见的钢炮，先从全球闻名的高尔夫说起，路上的高尔夫是不好惹的，因为高尔夫的多变和低调，在同一个外壳下，你不知道他是 131匹，还是150匹 ，或者220匹，在或者 245，  320 ，400 匹，每一个从在路上飞过的高尔夫，看上去可能是素车， 但也可能是 连 兰博基尼都跑不过的 大怪兽。如何识别从你身边 窜过去的 高尔夫是什么货色，实际上很难，因为低调，但你注意，后排气有没有2个 或 4个 粗大的管子，同时在车前面有GTI,或 R 的角标，当然还有轰隆隆作响的尾气声。目前高尔夫作为市面上，最容易被刷程序和改装的车，也是价格变动波动最大的车型之一，一辆高尔夫可能是 10几万，也可能是 20多万（GTI），还有可能是40多万（高尔夫R 进口四驱）（出厂的售价，不是改装的售价）另一面高尔夫贵，贵在改装，稍微改改就改出10多万是常见的事情，换个轻量化的轮毂，换四条竞赛轮胎，几万块就报废了，刷个 1阶 ，2 阶 ，3阶， 换一个头端，换更大的涡轮，一台EA888 干翻 宝马和奔驰， 所以千万路上别惹高尔夫，惹错了，就必然挨蹦。目前在售的国内可以买的 最快的国产 高尔夫 GTI 8 价格在 25万左右，带有欧洲同步的转向机2.1圈就打满，同时电子可调15段的避震，带有静止弹射起步，稍微刷个一阶程序，就能让你进入6秒俱乐部，3阶上了 路上除了特斯拉的毛豆3P （性能版model 3p ,不是家用版的特斯拉）还可以较量一下，其他的都是弟弟（一般的电车也没戏），都会被他蹦。如果你想，享受一下速度与激情，那么可以考虑一辆 GTI扮猪吃老虎 ，作为你肾上腺素快速分泌和同性交友的好方法。