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条最近运行的语句，这两个参数必须在系统启动前调整，是不能进行动态调整的。