MySQL 初识 performance_schema

翻译自 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解析不改变,没有新的关键字或语句。

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

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

很容易添加新的工具点。

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





你可能感兴趣的:(MySQL)