MySQL 性能方案

翻译自 dev.mysql.com/doc/refman/5.6/en/performance-schema.html

一、3个基本库

数据库初始化安装完毕会有三个基本库mysql 、information_schema、performace_schema。作为应用程序开发者，平时较少关注这些数据库尤其是后两者。但是通过对这些基本数据库的学习，必然会对数据库存储有更好的理解。

mysql

包含权限配置，事件，存储引擎状态，主从信息，日志，时区信息，用户权限配置等

information_schema

对数据库元数据的抽象分析，由此提供了SQL语句方式来查询数据库运行时状态，每次对information_schema的查询都产生对metadata的互斥访问，影响其他数据库的访问性能。

performance_schema

内存型数据库，使用performance_schema 存储引擎，通过事件机制将mysql服务的运行时状态采集并存储在performace_schema数据库。注意，两个单词之间用下划线连接时，表示performance_schema是一个数据库；用空格分开时，表示一个数据库性能方案，也表示一个存储引擎。

二、performance schema

2.1 特性

一个数据库性能方案，它提供了对运行时数据库服务进行内部检查的方式，这个方案通过performace schema存储引擎和performance_schema数据库进行了实现。这个方案关注mysql数据库服务的运行时的性能数据，而information_schema主要用于对元数据的检查。

性能方案监控了服务事件，事件是服务所花费时间来做并被感知到的任何事，因为被感知到，这些事件的时间信息可以被收集。总的来说，一个事件可以是函数调用、一个系统等待，一个数据查看语句的执行阶段（比如解析、分类），或者整个语句、整组语句，甚至是临界文件、表I/O、表级锁和数据库存储引擎的同步调用信息。

性能方案的事件不同于被写进服务日志中的事件（描述了数据修改）和调度事件（存储程序类型）

性能方案特定于一个数据库服务，性能方案数据库中的表关联到数据服务，表的修改不会被备份也不会写进二进制日志。

当前事件是可用的，和历史事件以及总结一样。这使得你可以判断有多少次被感知的活动以及它们的花费时间。时间信息可用来展示特定线程的活动，或着是互斥资源文件的访问活动。

性能方案存储引擎使用“感知点“”来收集事件数据

被收集的事件存储在performance_schema数据库，可以通过select语句进行查询。

性能方案配置可以被动态的执行SQL来修改，配置的改变会立即影响到数据收集。

性能数据库的表是内存型，没有持久化到磁盘存储，这些数据表在服务停止时被丢弃，服务启动时再次创建。

监控可用于所有被mysql支持的平台。

一些局限性可能存在：定时器的类型在不同平台上差异巨大，应用在多种存储引擎的工具可能不适用于所有的存储引擎。第三方引擎的工具服从于引擎维护者。

数据收集通过修改服务源码添加工具来实现。有几个不可分离的进程与性能方案有关，不同于其他备份或事件调度等特性。

2.2 性能方案计划用于获取服务执行的有用信息，在此期间对服务性能产生很小的影响，目的实现下面这些设计目标：

使用性能方案不对服务运行产生变化，例如，不会造成线程调度的改变，不造成查询执行计划（用explain展示）的改变。

在服务启动时，分配的内存不会超出，通过使用先前固定大小的分配结构，没有必须再去调整或重分配内存，对于实现很好的运行时性能至关重要。

服务监控持续发生并很少发生溢出，激活性能方案不会让服务不可用。

SQL解析不改变，没有新的关键字或语句。

甚至性能方案失败了，服务依旧进行。

当性能进程在事件收集初期或事件获取之后选择时，优先选择让收集进程执行更快的那个，因为收集不管进行而获取是按需进行甚至不会发生。

很容易添加新的工具点。

工具是版本化的，如果工具的实现改变了，先前的工具代码会继续工作。这让第三方插件的开发者受益，因为没必要为了与最新的性能方案保持同步而升级每一个插件。