mysql performance_schema配置_performance_schema事件过滤配置

事件以"生产者/消费者" 模式进行处理，instruments代码作为"生产者"(上下文中指 instruments)，它是事件信息的来源，产生需要收集的事件信息，performance_schema库下的记录各种各样事件信息的视图(表)作为"消费者"(上下文中指 consumers)，它用于存放"生产者"收集到的事件信息：

performance_schema支持哪些instruments，可以通过查询表setup_instruments，从下面的信息中可以看到，默认情况下，只是一部分启用了，一部分没启用(注意：setup_instruments表中的开关可以提供启用或禁用instruments，so。。也就是说ENABLED字段可以控制开关，TIMED字段可以控制是否启用计时类型的事件的计时器功能，如果通过修改这些字段值来进行过滤控制，先别急，后续章节会提到)：

mysql> SELECT * FROM setup_instruments;

+------------------------------------------------------------+---------+-------+

| NAME | ENABLED | TIMED |

+------------------------------------------------------------+---------+-------+

...

| wait/io/file/archive/data | YES | YES |

| wait/io/file/archive/FRM | YES | YES |

| wait/io/file/partition/ha_partition::parfile | YES | YES |

| wait/io/table/sql/handler | YES | YES |

| wait/lock/table/sql/handler | YES | YES |

| stage/sql/After create | NO | YES |

| stage/sql/allocating local table | NO | YES |

| stage/sql/preparing for alter table | NO | YES |

| stage/sql/altering table | NO | YES |

| stage/sql/committing alter table to storage engine | NO | YES |

...

performance_schema支持哪些consumers，可以通过查询setup_consumers表，从下面的信息中可以看到，默认情况下，只是一部分启用了，一部分没启用

qogir_env@localhost : performance_schema 11:20:25> SELECT * FROM setup_consumers;

+----------------------------------+---------+

| NAME | ENABLED |

+----------------------------------+---------+

| events_stages_current | NO |

| events_stages_history | NO |

| events_stages_history_long | NO |

| events_statements_current | YES |

| events_statements_history | YES |

| events_statements_history_long | NO |

| events_transactions_current | NO |

| events_transactions_history | NO |

| events_transactions_history_long | NO |

| events_waits_current | NO |

| events_waits_history | NO |

| events_waits_history_long | NO |

| global_instrumentation | YES |

| thread_instrumentation | YES |

| statements_digest | YES |

+----------------------------------+---------+

事件过滤功能可以在不同阶段对采集数据进行筛选，分为"Pre-Filtering"和"Post-Filtering"两个阶段，如下：

"Pre-Filtering"：所谓"Pre-Filtering"，指的就是事先通过setup_instruments和setup_consumers等配置表来控制哪些事件需要开启记录，是否需要同时开启计时器，以及是否需要记录或更新到performance_schema的表(consumers消费者表)中。该配置适用于所有用户，影响全局

为什么要使用"Post-Filtering"：

减少开销，打开performance_schema的所有监视功能，将拉低性能20%以上，所以需要监视哪些事件，应该根据需要进行设置，以使得既能满足需要，又能使得开销最小，默认情况下也打开了300多个监视器和几十个表的记录功能，如果你有一些可以关闭的且不需要的，可以自行修改配置表实现，以进一步减小开销

performance_schema中的每个表的记录总行数都是有一定限制的，如果开启额外的不需要的事件，则会导致不必要的空间占用。

避免维护不必要的事件表。如果打开某事件表记录功能(consumers)，则服务器会花费一定时间维护它(如：会去检查存储空间是否满了，如果满了还需要去检查哪些记录可以被清理等等)

"Post-Filtering"：所谓"Post-Filtering"，指的就是从performance_schema表中查询信息时select语句中使用的WHERE子句，以指定要查看哪些事件的记录信息。select语句你懂的。。每个用户使用的where条件查询的结果不会相互影响，因为每个用户想看的内容或者说感兴趣的内容可能有所不同

为什么要使用"Post-Filtering"：

避免查询到不想查看的内容，因为可能内容你并不感兴趣

使用performance_schema下记录的事件信息来排查性能问题时，使用"Pre-Filtering"并不一定能把你不想看的东西过滤掉，查询出来的东西可能非常多，这个时候就需要使用"Post-Filtering"，即select 的where子句来进行过滤，where子句中的可用值可以参考setup_instruments表中的name字段值

虽然"Post-Filtering"可以过滤一部分不需要的事件记录功能，但是，需要记录的事件具体记录到表中的记录信息中也可能有一部分是你在实际查询时不想查看的，那么这个时候就可以使用适当的WHERE子句来查询，如下：

mysql> SELECT THREAD_ID, NUMBER_OF_BYTES FROM events_waits_history WHERE EVENT_NAME LIKE 'wait/io/file/%' AND NUMBER_OF_BYTES IS NOT NULL;

+-----------+-----------------+

| THREAD_ID | NUMBER_OF_BYTES |

+-----------+-----------------+

| 11 | 66 |

| 11 | 47 |

| 11 | 139 |

| 5 | 24 |

| 5 | 834 |

+-----------+-----------------+

PS：

对于"Pre-Filtering" 事件，详见2.3.3小节，对于"Post-Filtering"，其实就是使用select + 合适的where条件 + 合适的instruments名称即可，不再针对"Post-Filtering"进行熬述