前面已经提到过了部分Performance Schema表，这里再总结下，PS库下主要分为几类表
1.SETUP table配置表
文档点击，上一篇博客已经介绍过，这里不再展开描述
2.CURRENT EVENT table
最近的事件表，例如
events_waits_current包含每个线程最近的事件
2.1.events_waits_current
该表列出了当前线程正在等待的事件，主要包括以下几列：
THREAD_ID:线程ID
EVENT_ID：当前线程的事件ID，和THREAD_ID组成一个Primary Key.
END_EVENT_ID:当事件开始时，这一列被设置为NULL。当事件结束时，再更新为当前的事件ID
EVENT_NAME：产生该事件的INSTRUMENT名
SOURCE：该事件产生时的源码文件；例如如果在等待一个Mutex，查看对应的源码，就可以知道在那里被阻塞住。
TIMER_START, TIMER_END, TIMER_WAIT：事件开始/结束和等待的时间，单位为皮秒（picoseconds）
SPINS：互斥锁或读写锁SPIN的次数
OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE, OBJECT_INSTANCE_BEGIN：这几列的值取决于不同的对象类型
a.对于cond, mutex, rwlock类型，OBJECT_SCHEMA, OBJECT_NAME, 以及 OBJECT_TYPE 的值为NULL.OBJECT_INSTANCE_BEGIN表示该同步对象创建的内存地址
b.对于文件IO对象，OBJECT_SCHEMA为NULL，OBJECT_NAME为文件名，OBJECT_TYPE为FILE，OBJECT_INSTANCE_BEGIN是内存地址。
c.对于SOCKET对象，OBJECT_NAME为该socket的IP:SOCK值,OBJECT_INSTANCE_BEGIN是对象内存地址
d.对于表I/O对象，OBJECT_SCHEMA是表的SCHEMA名，OBJECT_NAME是表名，OBJECT_TYPE为TABLE或者TEMPORARY TABLE，OBJECT_INSTANCE_BEGIN是对象的内存地址
INDEX:使用到的索引名
NESTING_EVENT_ID：该事件锁嵌套在的事件ID，
NESTING_EVENT_TYPE：嵌套事件类型(STATEMENT, STAGE, WAIT)
OPERATION:操作类型（lock, read, write）
NUMBER_OF_BYTES:该操作读或写的比特数，对于表的I/O对象，NUMBER_OF_BYTES值为NULL
FLAGS：预留列
2.2.events_stages_current
stage表中列出了一条SQL执行的过程，例如解析SQL，打开一个表，或者执行一次filesort操作等等，可以与show processlist结合起来。该表每一行显示了该线程最近的一条记录
主要包括以下几列：
THREAD_ID：线程ID
EVENT_ID：事件ID
END_EVENT_ID：刚结束的事件ID，以上三列的含义和wait表的相同
SOURCE：源码位置
TIMER_START, TIMER_END, TIMER_WAIT：本阶段开始、结束以及持续的时间；如果事件没有结束，TIMER_END和TIMER_WAIT值为NULL；如果该事件对应的INSTRUMENT的TIMED列设置为NO(SETUP_INSTRUMENTS)，这三列的值都为NULL
NESTING_EVENT_ID：当前事件被嵌套的事件ID，一个stage事件的嵌套事件通常是一个STATEMENT事件
NESTING_EVENT_TYPE：嵌套事件类型（STATEMENT, STAGE 或者WAIT）
2.3.events_statements_current
对statement的监控从发现一个线程活跃开始，到线程的活跃行为结束。换句话说，是从服务器接受客户端的第一个通信包开始，到服务器发送完所有的响应，监控只发生在最顶层的语句，对于在语句中包含的存储过程或者子查询不会单独列出。
从客户端发出的一个请求，既可以是一个COMMAND，也可以是一条SQL，通过statement/com 和statement/sql来划分，再往下划分就是具体的SQL类型或者COMMAND。
另外还有一些错误处理的INSTRUMENT：
statement/com/Error：用于处理服务器不能理解的COMMAND
statement/sql/error：用于处理无法解析的SQL。
在刚开始服务器接受到一条SQL时，先将看做statement/com/Query，在完成解析后，再将其设置成statement/sql/*
该表的列比较多，主要包括：
THREAD_ID、EVENT_ID、END_EVENT_ID、EVENT_NAME、SOURCE：和上面介绍的两个表含义类似，这里不再赘述
TIMER_START, TIMER_END, TIMER_WAIT：和表events_stages_current解释类似，不再赘述
LOCK_TIME：等待表锁的时间
SQL_TEXT：SQL语句，对于COMMAND，值为NULL
DIGEST：该SQL格式化后的 MD5值，需要statement_digest打开才生效
DIGEST_TEXT：该SQL格式化后的字符串，需要statement_digest打开才生效
CURRENT_SCHEMA：该SQL的默认链接的数据库
OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE：保留列，值为NULL
OBJECT_INSTANCE_BEGIN：用于标示该对象在内存中的地址
MYSQL_ERRNO：该SQL产生的错误号
RETURNED_SQLSTATE：SQLSTATE值
MESSAGE_TEXT：错误信息
ERRORS：是否发生错误，如果SQLSTATE值以00（完成） 或者01（警告）开始，值为0；否则为1
WARNINGS：告警次数，以上列都取自该SQL的diagnostics area
ROWS_AFFECTED：该SQL影响的行数
ROWS_SENT：发送到客户端的行数
ROWS_EXAMINED：在SQL执行过程中从存储引擎读取的记录数
CREATED_TMP_DISK_TABLES、CREATED_TMP_TABLES、SELECT_FULL_JOIN、SELECT_FULL_RANGE_JOIN、SELECT_RANGE、SELECT_RANGE_CHECK、SELECT_SCAN、SORT_MERGE_PASSES、SORT_RANGE、SORT_ROWS、SORT_SCAN：这些列的名字也有对应的status变量，含义相同，但这里只针对当前这个SQL的统计。
NO_INDEX_USED：如果SQL执行了一次全表扫描，没有用到索引的话值为1，否则为0
NO_GOOD_INDEX_USED：如果优化器没有为该SQL找到一个好的执行计划，值为1，否则值为0.更多的信息查阅EXPLAIN输出的EXTRA列中的“Range checked for each record”
NESTING_EVENT_ID, NESTING_EVENT_TYPE：保留列，当前值为NULL
3.HISTORY table
历史事件表，比CURRENT EVENT table的记录更多点。例如events_waits_history包含每个线程最近的10个事件，而 events_waits_history_long包含每个线程最近的10,000个事件。你可以通过选项performance_schema_events_waits_history_size和performance_schema_events_waits_history_long_size来配置这两个表的大小。
HISTORY/HISTORY LONG表跟CUREENT 表结构类似，只是存储的数据量不同，这里不再赘述。
4.SUMMARY table
汇总表，对事件信息进行聚集。
汇总表是我们关注的重点，因为它省略了人工处理数据的过程，由服务器来进行数据聚集。
主要包括以下几种：
4.1.Event Wait Summaries
这三个表分别根据EVENT名/INSTANCE（EVENT_NAME、OBJECT_INSTANCE_BEGIN）以及（THREAD_ID，EVENT_NAME）进行聚合，聚合列包括：
COUNT_STAR：事件计数
SUM_TIMER_WAIT：总的等待时间
MIN_TIMER_WAIT：最小等待时间
AVG_TIMER_WAIT：平均等待时间
4.2.Stage Summaries
同样包含
COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT
4.3.Statement Summaries
除了
COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT，还包括：
SUM_
xxx：一些状态信息的SUM值，例如SUM_LOCK_TIME、SUM_ERRORS等等
在
events_statements_summary_by_digest中，还包含了额外的信息：
FIRST_SEEN_TIMESTAMP, LAST_SEEN_TIMESTAMP,该SQL的摘要（DIGEST）信息第一次生成，以及最近一次生成的时间戳。
聚合的SQL在DIGEST表中生成的规则：
a.存在对应的格式化的SQL,将其信息聚合到该记录中，更新LAST_SEEN_TIMESTAMP
b.新的记录加入到表中（表未满），FIRST_SEEN_TIMESTAMP和LAST_SEEN_TIMESTAMP更新为当前时间
c.如果表已经满了，新记录被聚合到DIGEST=NULL的那一列。该列可以帮助你确认DIGEST SUMMARY表的记录是否具有代表性，
DIGEST = NULL行记录的COUNT_STAR，一般如果小于总的5%，则说明汇总记录具有代表性，如果超过50%，可能DBA就需要调整 performance_schema_digests_size变量的值了。
4.4.Object Wait Summaries:
4.5.File I/O Summaries
跟文件操作相关的统计信息（文档http://dev.mysql.com/doc/refman/5.6/en/file-summary-tables.html）
4.6.Table I/O and Lock Wait Summaries
table_io_waits_summary_by_table是根据wait/io/table/sql/handler，并根据表名进行分组而
table_lock_waits_summary_by_table是我们需要关注的表，因为其中聚合了表锁等待事件，包括internal lock 和 external lock：
internal lock通过SQL层函数thr_lock调用，显示在OPERATION这一列，有如下值：
read normal
read with shared locks
read high priority
read no insert
write allow write
write concurrent insert
write delayed
write low priority
write normal
external lock则通过接口函数handler::external_lock调用存储引擎层，OPERATION列的值为：
read external
write external
4.7.Connection Summaries
4.8.Socket Summaries
5.INSTANCE table
实例表记录了当前被监控的事件状态，主要包括以下几种：
-
cond_instances: 条件等待对象实例列出当前正在运行的condition wait对象，只包含两列：NAME：正在等待的INSTRUMENT名OBJECT_INSTANCE_BEGIN： 该condition被监控时的内存地址
-
file_instances: 文件实例当执行file io instrument时的文件信息，当一个文件从未被打开时，不会在其中显示，如果从磁盘上删除了文件，也会从该表中删除。包含3列：NAME:文件名EVENT_NAME:instrument名OPEN_COUNT：当前文件打开的次数；如果一个文件先打开，再关闭了，这个文件的OPEN_COUNT值为0.
-
mutex_instances: 互斥同步对象实例
列出了所有当前等待的互斥量,该表包含三列：NAME:该mutex的命名OBJECT_INSTANCE_BEGIN：对象实例的内存地址
LOCKED_BY_THREAD_ID：当前锁住该互斥量的线程ID对于每一个mutex instrument，PS提供了以下信息：a.setup_instruments列出了mutex的命名，以wait/synch/mutex/为命名前缀
b.当在代码中创建了一个mutex时，就在mutex_instances中增加一行记录。OBJECT_INSTANCE_BEGIN可以认为是该mutex的唯一标示符。c.当一个线程试图锁住一个mutex时，events_waits_current为该线程记录了一行数据，表明其在等待一个mutex（在EVENT_NAME列），以及哪个MUTEX在被等待（OBJECT_INSTANCE_BEGIN列）d.当一个线程成功锁住一个mutex,会d.1.
events_waits_current显示等待该mutex已经完成(TIMER_END和TIMER_WAIT列)d.2.完成的等待事件被加入到
events_waits_history和events_waits_history_long表中d.3.mutex_instances表中显示该mutex已经被占用(LOCKED_BY_THREAD_ID列)
e.当该mutex被释放时，LOCKED_BY_THREAD_ID列被设置为NULLf.当该mutex对象被销毁时，从mutex_instances中移除对应记录通过在以下两个表上执行查询，可以有助于发现性能瓶颈：查询events_waits_current：发现线程正在等待什么mutex -
rwlock_instances: 读写锁同步对象实例这个表和mutex_instances类似，不同的是记录的读写锁，包含如下列：NAME: 该读写锁instrument命名OBJECT_INSTANCE_BEGIN：被创建时的内存地址
WRITE_LOCKED_BY_THREAD_ID：当前持有写锁的线程ID
READ_LOCKED_BY_COUNT：读锁计数器
-
socket_instances: 活跃会话对象实例记录当前所有的实时socket连接对象。主要包括两种监听socket（server_tcpip_socket或者server_unix_socket）以及一种客户端连接（client_connection），当一个用户线程中断，对应的记录被删除。该表主要包含以下几列：EVENT_NAME：命名为wait/io/socket/*
OBJECT_INSTANCE_BEGIN：该对象的内存地址THREAD_ID：线程ID
SOCKET_ID： 内部socket id
IP：客户端IP地址PORT:客户端端口号STATE:用户线程状态，IDLE或者ACTIVE
6.其他杂项表
客户端连接信息表
链接属性表：
session_account_connect_attrs、session_connect_attrs 前者记录当前session，后者记录所有的session
相对而言，这些杂项表不是我们性能调优的重点，有兴趣的可以自行阅读文档
host_cache：用于显示内部的host cache信息
threads:当前的服务器线程,包括前台和后台线程
