[MySQL 5.6 ] Performance Schema学习：命名规范、状态变量及其他(2)

PS Instrument命名规范

 

PS instrument的命名类似于树形结构，最高层次的是instrument的类型，总共四种：idle/wait/stage/statement;再下一层的命名可能是一个子模块名（例如sync,io）等，再往下一层，例如sync，又可以划分成mutex/cond/rwlock,之后也许就是具体的某个同步锁对象，或者下一层的模块。

1.1.idle:

idle对象表示socket空闲信息，在setup_instrument表里只包含一列，名字就是idle。它生产的对应事件在socket_instances中.

mysql> select count(*) from setup_instruments where name like ‘idle%';

+———-+

| count(*) |

+———-+

|        1 |

+———-+

1 row in set (0.00 sec)

1.2.stage

stage的命名规则为stage/code_area/stage_name

其中code_area值为sql/mysys

stage_name表示执行语句过程中的各个阶段，例如storing result in query cache、Waiting for global read lock 等等.

mysql> select count(*) from setup_instruments where name like ‘stage%';

+———-+

| count(*) |

+———-+

|      108 |

+———-+

1 row in set (0.00 sec)

1.3.statement

其命名规则为statement/SQL或者COM

SQL的下一级表示不同的SQL类型，例如statement/sql/xa_commit、statement/sql/rollback

另外文档标明statement/sql/select  用于CREATE DATABASE 和SELECT语句，暂未证实

COM则对应enum_server_command 中的服务器command类型，例如statement/com/Ping 代表COM_PING 

1.4.wait

wait类型的instrument应该是我们比较关注的部分，因为mysql本身的并发等待是非常值得关注的部分，也一般是导致服务器异常的罪魁祸首.另外wait类型还包括io相关instrument.

wait/io  

包括对文件的操作时间统计(wait/io/file/),socket操作(wait/io/socket)；

另外还有表的IO操作(wait/io/table/sql/handler),包括对持久表和临时表的行级别操作，那些影响到行的操作（fetch,insert,delete..）.和其他wait对象不同的是，表的wait对象可能包含其他等待时间，例如，表的I/O可能包含文件I/O或内存操作。因此在表 events_waits_current 中对表的IO信息可能还包括wait/io/file对象，应该包含两行数据

wait/lock

就一个wait/lock/table/sql/handler ，表上的锁操作

wait/synch

synch的对象比较多，包括条件变量(wait/synch/cond)、mutex(wait/synch/mutex)、读写锁(wait/synch/rwlock)

PS状态变量

 

PS提供了一些信息来显示由于内存限制导致某些统计信息没有计入PS中。

mysql> SHOW STATUS LIKE ‘perf%';

+———————————————–+——-+

| Variable_name                                 | Value |

+———————————————–+——-+

| Performance_schema_accounts_lost              | 0     |

| Performance_schema_cond_classes_lost          | 0     |

| Performance_schema_cond_instances_lost        | 0     |

| Performance_schema_digest_lost                | 0     |

| Performance_schema_file_classes_lost          | 0     |

| Performance_schema_file_handles_lost          | 0     |

| Performance_schema_file_instances_lost        | 0     |

| Performance_schema_hosts_lost                 | 0     |

| Performance_schema_locker_lost                | 0     |

| Performance_schema_mutex_classes_lost         | 0     |

| Performance_schema_mutex_instances_lost       | 0     |

| Performance_schema_rwlock_classes_lost        | 0     |

| Performance_schema_rwlock_instances_lost      | 0     |

| Performance_schema_session_connect_attrs_lost | 0     |

| Performance_schema_socket_classes_lost        | 0     |

| Performance_schema_socket_instances_lost      | 0     |

| Performance_schema_stage_classes_lost         | 0     |

| Performance_schema_statement_classes_lost     | 0     |

| Performance_schema_table_handles_lost         | 0     |

| Performance_schema_table_instances_lost       | 0     |

| Performance_schema_thread_classes_lost        | 0     |

| Performance_schema_thread_instances_lost      | 0     |

| Performance_schema_users_lost                 | 0     |

+———————————————–+——-+

23 rows in set (0.00 sec)

而相应的内存分配的大小，则取决于如下的系统变量：

mysql> show variables like ‘%perf%';

+——————————————————–+——–+

| Variable_name                                          | Value  |

+——————————————————–+——–+

| performance_schema                                     | ON     |

| performance_schema_accounts_size                       | 100    |

| performance_schema_digests_size                        | 10000  |

| performance_schema_events_stages_history_long_size     | 10000  |

| performance_schema_events_stages_history_size          | 10     |

| performance_schema_events_statements_history_long_size | 10000  |

| performance_schema_events_statements_history_size      | 10     |

| performance_schema_events_waits_history_long_size      | 10000  |

| performance_schema_events_waits_history_size           | 10     |

| performance_schema_hosts_size                          | 100    |

| performance_schema_max_cond_classes                    | 80     |

| performance_schema_max_cond_instances                  | 20900  |

| performance_schema_max_file_classes                    | 50     |

| performance_schema_max_file_handles                    | 32768  |

| performance_schema_max_file_instances                  | 100824 |

| performance_schema_max_mutex_classes                   | 200    |

| performance_schema_max_mutex_instances                 | 35000  |

| performance_schema_max_rwlock_classes                  | 30     |

| performance_schema_max_rwlock_instances                | 12800  |

| performance_schema_max_socket_classes                  | 10     |

| performance_schema_max_socket_instances                | 10020  |

| performance_schema_max_stage_classes                   | 150    |

| performance_schema_max_statement_classes               | 167    |

| performance_schema_max_table_handles                   | 4000   |

| performance_schema_max_table_instances                 | 12500  |

| performance_schema_max_thread_classes                  | 50     |

| performance_schema_max_thread_instances                | 10100  |

| performance_schema_session_connect_attrs_size          | 512    |

| performance_schema_setup_actors_size                   | 100    |

| performance_schema_setup_objects_size                  | 100    |

| performance_schema_users_size                          | 100    |

+——————————————————–+——–+各个选项配置的文档见：http://dev.mysql.com/doc/refman/5.6/en/performance-schema-system-variables.html

 

我们也可以通过SHOW ENGINE PERFORMANCE_SCHEMA STATUS\G 来看当前PS的内存占用

详细介绍点击文档，如果你的内存足够大，可以适当调整这些参数来存储更多收集的信息

另外还可以通过选项performance_schema_instrument = ‘%=on’在启动时打开所有的instrument

STATEMENT_DIGEST

当打开statements_digest时,PS会将相同类型的SQL在 events_statements_summary_by_digest表中聚集在一起，SQL中的数据部分被“?”所代替，并调整空白部分，一些标示，例如表名和库名被保留。这有点和我们内部使用的myawr功能类似，将相似的SQL聚合起来展现。在statement对应的event表中，DIGEST列存储了SQL的md5值，DIGEST_TEXT存储了被处理过的SQL。

例如，执行如下SQL:

select * from sbtest where id < 10; 

select * from sbtest where id < 20; 

会被聚合成如下记录：

                SCHEMA_NAME: sbtest

                     DIGEST: 4c3d9d47ee42d768152f70ee27f8e067

                DIGEST_TEXT: SELECT * FROM `sbtest` WHERE `id` < ?

                 COUNT_STAR: 2

             SUM_TIMER_WAIT: 3477357000

             MIN_TIMER_WAIT: 340011000

             AVG_TIMER_WAIT: 1738678000

             MAX_TIMER_WAIT: 3137346000

              SUM_LOCK_TIME: 284000000

                 SUM_ERRORS: 0

               SUM_WARNINGS: 0

          SUM_ROWS_AFFECTED: 0

              SUM_ROWS_SENT: 28

          SUM_ROWS_EXAMINED: 28

SUM_CREATED_TMP_DISK_TABLES: 0

     SUM_CREATED_TMP_TABLES: 0

       SUM_SELECT_FULL_JOIN: 0

 SUM_SELECT_FULL_RANGE_JOIN: 0

           SUM_SELECT_RANGE: 2

     SUM_SELECT_RANGE_CHECK: 0

            SUM_SELECT_SCAN: 0

      SUM_SORT_MERGE_PASSES: 0

             SUM_SORT_RANGE: 0

              SUM_SORT_ROWS: 0

              SUM_SORT_SCAN: 0

          SUM_NO_INDEX_USED: 0

     SUM_NO_GOOD_INDEX_USED: 0

                 FIRST_SEEN: 2013-03-29 16:55:01

                  LAST_SEEN: 2013-03-29 16:55:04

DIEGEST_TEXT列的长度为1024，超过了就以字符串“…”代替。而在events_statements_current, events_statements_history和 events_statements_history_long这三个表中记录了具体的SQL，而非聚合的结果


events_statements_summary_by_digest表有固定的大小，由参数performance_schema_digests_size控制，默认为10000条记录。当该表的记录满时，有一个特殊的列,其SCHEMA_NAME和DIGEST列设置为NULL，记录被加入到这个特殊的列中，如果观察该行记录的counter明显很高时，可能需要调整这个表的size。


时间： 2024-11-16 04:15:13

[MySQL 5.6 ] Performance Schema学习：命名规范、状态变量及其他(2)的相关文章

[MySQL 5.6] Performance Schema 表类型纵览 (3)

前面已经提到过了部分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_I

[MySQL 5.6] Performance Schema 之 PS配置项（1）

尽管Performance Schema(以下简称PS)在5.5中已经出现,但一直没有使用过,并且相比5.6,5.5的PS表要少很多. 以下从一个初学者的角度,阅读PS的官方文档,做一些简单的笔记 官方文档见:http://dev.mysql.com/doc/refman/5.6/en/performance-schema.html 目录:  1.开启PS 2.配置PS 2.1 setup_timers表决定了不同的instrument使用的timer类型 2.2setup_instrument

MySQL 5.7 SYS SCHEMA

 MySQL 5.7 SYS SCHEMA 官方地址:https://dev.mysql.com/doc/refman/5.7/en/sys-schema.html 1.performance schema:介绍 在MySQL5.7中,performance schema有很大改进,包括引入大量新加入的监控项.降低占用空间和负载,以及通过新的sys schema机制显著提升易用性.在监控方面,performance schema有如下功能: ①:元数据锁: 对于了解会话之间元数据锁的依赖关系至关

数据库设计规范：命名规范

命名规范 说明:指数据库对象如表(TABLE).序列(SEQUENCE).过程(PROCEDURE).触发器(TRIGGER)等的命名约定. 1. 基本命名原则 (1)规则1:命名使用具有意义的英文词汇,词汇中间以下划线分隔. (2)规则2:命名只能使用英文字母,数字,下划线,并以英文字母开头. (3)规则3:避免用ORACLE.MySQL的保留字如desc,关键字如index. 2. 表命名 (1)规则1:同一个模块的表尽可能使用相同的前缀,表名称尽可能表达含义. (2)规则2:长度不超过25

MySQL5.7新增Performance Schema表

在前面有几篇博客我们已经介绍过MySQL5.6的Performance Schema,详细可点击博客1,博客2,博客3.在MySQL5.6里这些PS表已经包含了足够丰富的信息,帮助我们来分析MySQL的内部运行状态:另外由MySQL官方开发人员写的ps_helper是一组相当好用的ps配套工具,就算对Performance Schema不熟悉的同学,也能读懂其中的信息,感兴趣的同学可以自行谷歌下载. 当然本文的重点不在Performance Schema的使用上,主要是记录下MySQL5.7里新

浅谈Android编码规范及命名规范_Android

前言: 目前工作负责两个医疗APP项目的开发,同时使用LeanCloud进行云端配合开发,完全单挑. 现大框架已经完成,正在进行细节模块上的开发 抽空总结一下Android项目的开发规范:1.编码规范 2.命名规范 注:个人经验,经供参考 一.Android编码规范 1.学会使用string.xml文件 在我看来,当一个文本信息出现的次数大于一次的时候就必须要使用string.xml 比如一个保存按钮 , 不规范写法: <Button android:id="@+id/editinfo_b

Mysql 5.7 Gtid内部学习(一) 导读

Mysql Gtid特性是5.6加入的一个强大的特性,它的目的在于使用Gtid的Mysql能够在整个复制环境中能够自动的切换,而不像以前需要指定文件和位置,这也一定是未来发展的方向,我们熟知的MGR也是基于Gtid的,所以了解Gtid的原理也是必要的. Gtid的维护是完全自动的,但是实际使用上确实有较多的坑,也导致很多朋友对Gtid还是觉得畏惧,本系列文章将从Gtid模块的源码出发分析,并且给出总结,然后结合运维和案例进行综合的解析,我希望抛砖引玉让希望了解源码的朋友也有所收获,但是能力有限特

【自然框架 NatureFramework】 项目结构、命名空间和命名规范

  请注意,这里说的是自然框架内部代码的项目结构,并不是说给客户做开发的时候,也需要这些项目.在给客户开发的时候,只需要引用编译后的dll 即可. 一.项目结构   自然框架的基本的思路还是共用函数,数据访问函数库.元数据管理.基础控件扩展.元数据控件(依据元数据动态创建的控件),用户登录.在线.权限管理,分页控件,页面基类构成. 这个并没有按照三层(分层)的要求去做,只是感觉这么分可以更清晰一些.把功能相当比较独立的部分做成一个项目.有一点MVC(不是asp.net MVC)的味道.我不想依据

浅谈Android编码规范及命名规范

前言: 目前工作负责两个医疗APP项目的开发,同时使用LeanCloud进行云端配合开发,完全单挑. 现大框架已经完成,正在进行细节模块上的开发 抽空总结一下Android项目的开发规范:1.编码规范 2.命名规范 注:个人经验,经供参考 一.Android编码规范 1.学会使用string.xml文件 在我看来,当一个文本信息出现的次数大于一次的时候就必须要使用string.xml 比如一个保存按钮 , 不规范写法: <Button android:id="@+id/editinfo_b