MySQL Performance Schema知识点
程序插桩（instrument）。程序插桩在MySQL代码中插入探测代码，以获取我们想了解的信息。
消费者表（consumer），指的是存储关于程序插桩代码信息的表。如果我们为查询模块添加插桩，相应的消费者表将记录诸如执行总数、未使用索引的次数、花费的时间等信息。
当应用程序用户连接到MySQL并执行被测量的插桩指令时，performance_schema将每个检查的调用封装到两个宏中，然后将结果记录在相应的消费者表中。这里的要点是，启用插桩会调用额外的代码，这意味着插桩会消耗CPU资源。
插桩
setup_instruments表包含所有支持的插桩的列表。所有插桩的名称都由用斜杠分隔的部件组成。下面的例子展示了插桩的命名规则：
- statement/sql/select
- wait/synch/mutex/innodb/autoinc_mutex
插桩名称的最左边部分表示插桩的类型。因此，statement表示插桩类型是statement，wait表示插桩类型是wait，以此类推。
消费者表的分类
当前和历史数据
- *_current：当前服务器上进行中的事件
- *_history每个线程最近完成的10个事件
- *_history_long从全局来看，每个线程最近完成的10000个事件。
汇总表和摘要
汇总表保存有关该表所建议的内容的聚合信息。例如，memory_summary_by_thread_by_event_name表保存了用户连接或任何后台线程的每个MySQL线程的聚合内存使用情况。
摘要是一种通过删除查询中的变量来聚合查询的方法,变量可以展示为"?"。
实例表(Instance)
实例是指对象实例，用于MySQL安装程序。例如，file_instances表包含文件名和访问这些文件的线程数。
设置表(Setup)
设置表用于performance_schema的运行时设置。
其他表
还有一些表的名称没有遵循严格的模式。例如，metadata_locks表保存关于元数据锁的数据。
资源消耗
Performance Schema收集的数据保存在内存中。然而，一旦分配了内存，即使禁用了特定的插桩并截断了表，也不会再释放该内存。
局限性
- 它必须得到MySQL组件的支持。
- 它只在特定的插桩和用户启用后才收集数据。例如检查内存使用情况必须在启动前启用插桩。
- 它很难释放内存
Sys Schema
sys schema，它全部基于performance_schema上的视图和存储例程组成。它的设计目的是让performance_schema体验更加流畅，它本身并不存储任何数据。
线程
MySQL服务端是多线程软件。它的每个组件都使用线程。可以是后台线程，例如，由主线程或存储引擎创建的，也可以是为用户连接创建的前台线程。每个线程至少有两个唯一标识符：一个是操作系统线程ID，另一个是MySQL内部线程ID(THREAD_ID)。每个前台线程都有一个指定的PROCESSLIST_ID：连接标识符。
THREAD_ID不等于PROCESSLIST_ID。
配置
Performance Schema的部分设置只能在服务器启动时更改：比如启用或禁用Performance Schema本身以及与内存使用和数据收集的限制相关的变量。Performance Schema插桩和消费者表则可以被动态启用或禁用。
启用或禁用插桩
三种方式：
- 在setup_instruments表使用update语句
- 调用sys schema中的ps_setup_enable_instrument存储过程
- 启动MySQL时使用performance-schema-instrument启动参数
启用或禁用消费者表
三种方式：
- 在setup_consumers表使用update语句
- 调用sys schema中的ps_setup_enable_consumer或ps_setup_disable_consuper存储过程
- 启动MySQL时使用performance-schema-consumer启动参数
调整Performance Schema的内存大小
Performance Schema将数据存储在使用PERFORMANCE_SCHEMA引擎的表中，该引擎将数据存储在内存中。默认情况下，某些performance_schema表会自动调整大小，其他的则有固定数量的行。可以通过更改启动变量来调整这些选项。变量的名称遵循p erformance_schema_object_[size|instances|classes|length|handles]的模式，其中对象要么是消费者表，要么是设置表，要么是特定事件的插桩实例
使用Performance Schema案例
常规SQL语句
要启用语句检测，需要启用statement类型的插桩。Performance Schema将语句指标存储在events_statements_current、events_statements_history和events_statements_history_long表中。
语句剖析
events_stages_[current|history|history_long]表包含剖析信息，例如MySQL在创建临时表、更新或等待锁时花费了多少时间。要启用剖析，需要启用上述消费者表以及匹配’stage/%'模式的插桩。启用后可以找到类似“查询执行的哪个阶段花费了非常长的时间”等问题的答案。
检查元数据锁
元数据锁用于保护数据库对象定义不被修改。共享元数据锁会阻止那些更改数据库对象定义的语句，比如ALTER TABLE或CREATE INDEX，直到锁被释放为止。
事务执行期间会一直持有元数据锁。多语句事务的使用会使故障排除变得更加困难。很容易搞清楚哪个语句在等待元数据锁：DDL语句会隐式提交事务，因此它们是新事务中唯一的语句，并且可以在进程列表中发现它们处于“waiting for a metadata lock”状态。但是在进程列表中可能找不到持有元数据锁的语句，这些语句已经执行完成，但是包含这些语句的事务还没有提交。
performance_schema中的metadata_locks表包含关于当前由不同线程设置的锁的信息，以及处于等待状态的锁请求信息。要启用元数据锁监测，需要启用wait/lock/meta-data/sql/mdl插桩。
检查内存使用情况
要在performance_schema中启用内存监测，请启用memory类的插桩。
Performance Schema将内存使用统计信息存储在摘要表中，摘要表的名称以memory_summary_前缀开头。内存使用聚合统计。
检查变量
变量分为服务器变量、状态变量和用户变量。
全局变量值被存储在表global_variables中。状态变量可以按用户账户、主机、用户和线程聚合。最有趣的是线程聚合，因为它允许你快速识别哪个连接在服务器上造成了大部分资源压力
检查最常见的错误
除了特定错误信息，performance_schema还提供摘要表，可以按用户、主机、账户、线程和错误号聚合错误信息。
检查Performance Schema自身
请注意，默认情况下，如果Performance_schema被设为默认数据库，则不会跟踪对它的查询。如果需要检查对performance_schema的查询，则需要首先更新setup_actors表。一旦setup_actors表被更新，就可以使用所有的插桩。
