金沙国际娱城 > 金沙技术 > 金沙技术初相识|performance_schema全方位介绍(一

原标题:金沙技术初相识|performance_schema全方位介绍(一

浏览次数:86 时间:2019-04-23

| events_statements_summary_by_host_by_event_name |

............

内部存款和储蓄器行为监察装置:

MySQL Performance-Schema(二) 理论篇,performanceschema

     MySQL Performance-Schema中累计包蕴55个表,首要分为几类:Setup表,Instance表,Wait 伊芙nt表,Stage 伊芙nt表Statement 伊夫nt表,Connection表和Summary表。上壹篇小说已经首要讲了Setup表,这篇文章将会分别就每种类型的表做详细的叙说。

Instance表
     instance中重视涵盖了5张表:cond_instances,file_instances,mutex_instances,rwlock_instances和socket_instances。
(1)cond_instances:条件等待对象实例
表中著录了系统中利用的口径变量的靶子,OBJECT_INSTANCE_BEGIN为对象的内部存款和储蓄器地址。举个例子线程池的timer_cond实例的name为:wait/synch/cond/threadpool/timer_cond

(2)file_instances:文件实例
表中著录了系统中开采了文件的目的,包含ibdata文件,redo文件,binlog文件,用户的表文件等,比方redo日志文件:/u01/my3306/data/ib_logfile0。open_count显示当前文件张开的多寡,假使重来未有展开过,不会油不过生在表中。

(3)mutex_instances:互斥同步对象实例
表中著录了系统中动用互斥量对象的装有记录,当中name为:wait/synch/mutex/*。比如展开文件的互斥量:wait/synch/mutex/mysys/THLX570_LOCK_open。LOCKED_BY_THREAD_ID显示哪个线程正持有mutex,若未有线程持有,则为NULL。

(4)rwlock_instances: 读写锁同步对象实例
表中著录了系统中应用读写锁对象的装有记录,在那之中name为 wait/synch/rwlock/*。WRITE_LOCKED_BY_THREAD_ID为正值有着该目的的thread_id,若没无线程持有,则为NULL,READ_LOCKED_BY_COUNT为记录了并且有多少个读者持有读锁。通过 events_waits_current 表能够了然,哪个线程在守候锁;通过rwlock_instances知道哪个线程持有锁。rwlock_instances的弱点是,只好记录持有写锁的线程,对于读锁则无法。

(5)socket_instances:活跃会话对象实例
表中记录了thread_id,socket_id,ip和port,别的表能够透过thread_id与socket_instance进行关联,获取IP-PORT新闻,可以与应用接入起来。
event_name首要含有3类:
wait/io/socket/sql/server_unix_socket,服务端unix监听socket
wait/io/socket/sql/server_tcpip_socket,服务端tcp监听socket
wait/io/socket/sql/client_connection,客户端socket

Wait Event表
      Wait表首要包括三个表,events_waits_current,events_waits_history和events_waits_history_long,通过thread_id event_id能够唯壹分明一条记下。current表记录了脚下线程等待的风浪,history表记录了各个线程近来等待的13个事件,而history_long表则记录了近年颇具线程发生的一千0个事件,那里的10和一千0都以足以布署的。那多少个表表结构一样,history和history_long表数据都来自current表。current表和history表中只怕会有重新事件,并且history表中的事件都以成功了的,未有结束的事件不会加盟到history表中。
THREAD_ID:线程ID
EVENT_ID:当前线程的事件ID,和THREAD_ID组成三个Primary Key。
END_EVENT_ID:当事件始于时,那一列被安装为NULL。当事件结束时,再立异为当前的风云ID。
SOU凯雷德CE:该事件发生时的源码文件
TIMER_START, TIMER_END, TIMER_WAIT:事件开头/甘休和等候的时刻,单位为微秒(picoseconds)

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE视情况而定
对于联合对象(cond, mutex, rwlock),这一个贰个值均为NULL
对此文本IO对象,OBJECT_SCHEMA为NULL,OBJECT_NAME为文件名,OBJECT_TYPE为FILE
对于SOCKET对象,OBJECT_NAME为该socket的IP:SOCK值
对于表I/O对象,OBJECT_SCHEMA是表的SCHEMA名,OBJECT_NAME是表名,OBJECT_TYPE为TABLE或者TEMPORARY TABLE
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT, STAGE, WAIT)
OPERATION:操作类型(lock, read, write)

Stage Event表 

       Stage表首要含有一个表,events_stages_current,events_stages_history和events_stages_history_long,通过thread_id event_id能够唯一分明一条记下。表中著录了当下线程所处的施行品级,由于能够知道各样阶段的施行时间,因而通过stage表能够收获SQL在种种阶段消耗的年华。

THREAD_ID:线程ID
EVENT_ID:事件ID
END_EVENT_ID:刚截至的事件ID
SOU揽胜CE:源码地方
TIMER_START, TIMER_END, TIMER_WAIT:事件伊始/截止和等待的时日,单位为微秒(picoseconds)
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT, STAGE, WAIT)

Statement Event表
      Statement表首要包括3个表,events_statements_current,events_statements_history和events_statements_history_long。通过thread_id event_id能够唯一明显一条记下。Statments表只记录最顶层的央浼,SQL语句或是COMMAND,每条语句一行,对于嵌套的子查询大概存款和储蓄进度不会独自列出。event_name形式为statement/sql/*,或statement/com/*
SQL_TEXT:记录SQL语句
DIGEST:对SQL_TEXT做MD伍生出的叁拾叁位字符串。若是为consumer表中从未张开statement_digest选项,则为NULL。
DIGEST_TEXT:将讲话中值部分用问号代替,用于SQL语句归类。假设为consumer表中未有打开statement_digest选项,则为NULL。
CURRENT_SCHEMA:私下认可的数码库名
OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE:保留字段,全体为NULL
ROWS_AFFECTED:影响的数据
ROWS_SENT:再次回到的记录数
ROWS_EXAMINED:读取的笔录数据
CREATED_TMP_DISK_TABLES:创设物理临时表数目
CREATED_TMP_TABLES:创造暂且表数目
SELECT_FULL_JOIN:join时,第三个表为全表扫描的数额
SELECT_FULL_RANGE_JOIN:join时,引用表接纳range形式扫描的数据
SELECT_RANGE:join时,第贰个表选拔range格局扫描的数目
SELECT_SCAN:join时,第一个表位全表扫描的多少
SORT_ROWS:排序的记录数据
NESTING_EVENT_ID,NESTING_EVENT_TYPE,保留字段,为NULL。

Connection表
     Connection表记录了客户端的音信,首要包含三张表:users,hosts和account表,accounts包涵hosts和users的音信。
USER:用户名
HOST:用户的IP

Summary表
    Summary表集中了1一维度的计算消息包蕴表维度,索引维度,会话维度,语句维度和锁维度的总括消息。
(1).wait-summary表
events_waits_summary_global_by_event_name
此情此景:按等待事件类型聚合,每一种事件一条记下。
events_waits_summary_by_instance
情景:按等待事件目标聚合,同1种等待事件,只怕有五个实例,种种实例有不一样的内部存款和储蓄器地址,由此
event_name object_instance_begin唯1鲜明一条记下。
events_waits_summary_by_thread_by_event_name
情状:按每一种线程和事件来总结,thread_id event_name唯1明确一条记下。
COUNT_STALAND:事件计数
SUM_TIMER_WAIT:总的等待时间
MIN_TIMER_WAIT:最小等待时间
MAX_TIMER_WAIT:最大等待时间
AVG_TIMER_WAIT:平均等待时间

(2).stage-summary表
events_stages_summary_by_thread_by_event_name
events_stages_summary_global_by_event_name
与前边类似

(3).statements-summary表
events_statements_summary_by_thread_by_event_name表和events_statements_summary_global_by_event_name表与日前类似。对于events_statements_summary_by_digest表,
FIRST_SEEN_TIMESTAMP:第3个语句试行的小运
LAST_SEEN_TIMESTAMP:最终三个言辞推行的岁月
地方:用于总计某一段时间内top SQL

(4).file I/O summary表
file_summary_by_event_name [按事件类型总结]
file_summary_by_instance [按实际文件总计]
场景:物理IO维度
FILE_NAME:具体文件名,比方:/u01/my3306/data/tcbuyer_0168/tc_biz_order_2695.ibd
EVENT_NAME:事件名,比如:wait/io/file/innodb/innodb_data_file
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计IO操作
COUNT_READ,SUM_TIMER_READ,MIN_TIMER_READ,AVG_TIMER_READ,MAX_TIMER_READ, SUM_NUMBER_OF_BYTES_READ
统计读
COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE, SUM_NUMBER_OF_BYTES_WRITE
统计写
COUNT_MISC,SUM_TIMER_MISC,MIN_TIMER_MISC,AVG_TIMER_MISC,MAX_TIMER_MISC
总括其余IO事件,举例create,delete,open,close等

(5).Table I/O and Lock Wait Summaries-表
table_io_waits_summary_by_table
听别人说wait/io/table/sql/handler,聚合每一个表的I/O操作,[逻辑IO]
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计IO操作
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计读
COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE, MAX_TIMER_WRITE
统计写
COUNT_FETCH,SUM_TIMER_FETCH,MIN_TIMER_FETCH,AVG_TIMER_FETCH, MAX_TIMER_FETCH
与读同样
COUNT_INSERT,SUM_TIMER_INSERT,MIN_TIMER_INSERT,AVG_TIMER_INSERT,MAX_TIMER_INSERT
INSERT总括,相应的还有DELETE和UPDATE计算。

(6).table_io_waits_summary_by_index_usage
与table_io_waits_summary_by_table类似,按索引维度计算

(7).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

(8).Connection Summaries表
events_waits_summary_by_account_by_event_name
events_waits_summary_by_user_by_event_name
events_waits_summary_by_host_by_event_name
events_stages_summary_by_account_by_event_name
events_stages_summary_by_user_by_event_name
events_stages_summary_by_host_by_event_name
events_statements_summary_by_account_by_event_name
events_statements_summary_by_user_by_event_name
events_statements_summary_by_host_by_event_name

(9).socket-summaries表
socket_summary_by_instance
socket_summary_by_event_name

其它表
performance_timers: 系统支持的总结时间单位
threads: 监视服务端的此时此刻运作的线程

Performance-Schema(贰) 理论篇,performanceschema MySQL Performance-Schema中总共包蕴53个表,重要分为几类:Setup表,Instance表,Wait 伊芙nt表,Stage Ev...

| /data/mysqldata1/mydata/mysql/server_cost.ibd |wait/io/file/innodb/innodb_data_file | 3 |

咱俩先来看看表中记录的总结音讯是怎么样样子的。

1 row in set (0.00 sec)

|2、performance_schema使用便捷入门

|TABLE | xiaoboluo |test | 140568038528544 |0| 0 |NULL | NULL |

* CURRENT_NUMBER_OF_BYTES_USED:当前已分配的内部存款和储蓄器块但未释放的计算大小。这是一个便捷列,等于SUM_NUMBER_OF_BYTES_ALLOC

|wait/io/file/myisam/kfile | 102 |

·file_instances:文件对象实例;

| events_transactions_summary_by_host_by_event_name |

OBJECT_INSTANCE_BEGIN: 955681576

| 4 |program_name | mysql |5|

# memory_summary_global_by_event_name表

产品:沃趣科学技术

· NAME:与condition相关联的instruments名称;

COUNT_STAR: 0

------------------------------------------------------

SUM _NUMBER_OF _BYTES_READ: 11567104

EVENT_NAME: memory/innodb/fil0fil

qogir_env@localhost : performance_schema 03:55:07> show tables like 'events_stage%';

MAX_TIMER_EXECUTE: 0

* HIGH_COUNT_USED和HIGH_NUMBER_OF_BYTES_USED是较高的高水位预计值。performance_schema输出的低水位值能够保证计算表中的内部存款和储蓄器分配次数和内存大于或等于当前server中真实的内部存款和储蓄器分配值

|1、**什么是performance_schema**

------------- --------------------- -------------------

* CURRENT_NUMBER_OF_BYTES_USED:减少N

| NO |NO | NO |

* mysqlbinlog定义了_client_role属性,值为binary_log_listener

*************************** 1. row ***************************

......

|4| _pid |3766| 2 |

5rows inset ( 0. 00sec)

| setup_consumers |

·DEALLOCATE PREPARE步骤:语法 {DEALLOCATE | DROP} PREPARE stmt_name,示例:drop prepare stmt; ,此时在prepared_statements_instances表中对应的prepare示例记录自动删除。

COUNT_STAR: 0

OPERATION: lock

1 row in set (0.00 sec)

* HIGH_COUNT_USED:如果CURRENT_COUNT_USED增添壹是2个新的最高值,则该字段值相应增添

  1. 启用performance_schema不会促成server的行事发生变化。比方,它不会更动线程调整机制,不会变成查询推行计划(如EXPLAIN)产生变化
  2. 启用performance_schema之后,server会持续不间断地监测,费用相当小。不会导致server不可用
  3. 在该兑现机制中未有扩展新的关键字或言辞,解析器不会调换
  4. 即使performance_schema的监测机制在里边对某事件实行监测战败,也不会影响server不奇怪运转
  5. 假诺在早先搜罗事件数量时境遇有别的线程正在针对那些事件消息进行询问,那么查询会优先试行事件数量的搜罗,因为事件数量的搜集是三个不息不断的进度,而追寻(查询)这么些事件数量仅仅只是在急需查阅的时候才进行寻找。也或许有些事件数量永久都不会去搜寻
  6. 急需很轻易地增多新的instruments监测点
  7. instruments(事件采访项)代码版本化:如若instruments的代码发生了改造,旧的instruments代码还足以再而三做事。
  8. 留神:MySQL sys schema是壹组对象(包蕴有关的视图、存款和储蓄进度和函数),能够方便地访问performance_schema搜罗的数据。同时搜寻的数量可读性也更加高(举个例子:performance_schema中的时间单位是阿秒,经过sys schema查询时会调换为可读的us,ms,s,min,hour,day等单位),sys schem在5.七.x版本暗许安装

admin@localhost : performance_schema 09 :34:49> select * from accounts;

------------------------------------------

| events_transactions_summary_global_by_event_name |

·TOTAL_CONNECTIONS:某主机的总连接数。

* 如果DIGEST = NULL行的COUNT_STAKoleos列值占领整个表中全部总计消息的COUNT_STALAND列值的比例大于0%,则表示存在由于该表限制已满导致有的语句计算新闻不大概归类保存,假使您要求保留全部语句的总计音讯,能够在server运维从前调节系统变量performance_schema_digests_size的值,私下认可大小为200

3rows inset (0.01sec)

·prepare语句预编写翻译:COM_STMT_PREPARE或SQLCOM_PREPARE命令在server中开创一个prepare语句。假使语句检测成功,则会在prepared_statements_instances表中新扩充一行。如若prepare语句不可能检验,则会加多Performance_schema_prepared_statements_lost状态变量的值。

*************************** 1. row ***************************

NESTING_EVENT_TYPE: NULL

......

......

| memory_summary_global_by_event_name |

| NULL |41| 45 |

Query OK, 377 rows affected (0.00 sec)

| ENGINE |SUPPORT | COMMENT |TRANSACTIONS | XA |SAVEPOINTS |

| NAME |OBJECT_INSTANCE_BEGIN |

EVENT_NAME: transaction

-----------------------------------------------

PS:socket总结表不会总结空闲事件生成的等候事件音信,空闲事件的等待新闻是记录在等待事件总括表中进行总计的。

events_statements_summary_by_user_by_event_name:根据各个用户名和事件名称进行计算的Statement事件

----------------------------------------------------

* _pid:客户端进度ID

events_statements_summary_by_program:根据各种存款和储蓄程序(存款和储蓄进度和函数,触发器和事件)的风云名称进行总括的Statement事件

作业事件记录表,记录事务相关的轩然大波的表,与话语事件类型的连锁记录表类似:

·各类文件I/O计算表都有1个或三个分组列,以注明怎样总结这个事件音信。这一个表中的轩然大波名称来自setup_instruments表中的name字段:

* 事务所占用的财富必要多少也或然会因作业隔开分离品级有所差异(举例:锁能源)。不过:各类server可能是应用同壹的割裂等级,所以不独立提供隔开等第相关的总计列

END_EVENT_ID: 60

SUM _TIMER_WAIT: 195829830101250

内部存款和储蓄器事件instruments中除了performance_schema自己内部存款和储蓄器分配相关的事件instruments配置暗中认可开启之外,其余的内部存款和储蓄器事件instruments配置都私下认可关闭的,且在setup_consumers表中绝非像等待事件、阶段事件、语句事件与事务事件这样的单身布署项。

开荒等待事件的保存表配置按钮,修改修改setup_consumers 配置表中对应的配置i向

------------------------------------------------------- ----------------------- --------------------------- ----------------------

* 如若该线程在threads表中从不开启搜聚成效可能说在setup_instruments中对应的instruments没有展开,则该线程分配的内部存储器块不会被监察和控制

| variables_by_thread |

PS:对于mutexes、conditions和rwlocks,在运行时尽管允许修改配置,且布局能够修改成功,可是有1部分instruments不奏效,须要在运营时配置才会立见成效,假若您品尝着使用部分采纳场景来追踪锁音讯,你也许在这个instance表中不也许查询到相应的音信。

COUNT_ALLOC: 216

|EVENT_NAME | SUM_TIMER_WAIT |

SUM_TIMER_READ: 0

SUM_LOCK_TIME: 26026000000

| events_statements_summary_global_by_event_name |

种种套接字总括表都包罗如下总结列:

AVG _TIMER_READ_ONLY: 57571000

| events_stages_history |

SQL_TEXT: SELECT 1

EVENT_NAME: memory/innodb/fil0fil

| /data/mysqldata1/mydata/mysql/engine_cost.ibd |wait/io/file/innodb/innodb_data_file | 3 |

与objects_summary_global_by_type 表计算音讯类似,表I/O等待和锁等待事件总结音讯更精细,细分了种种表的增加和删除改查的执行次数,总等待时间,最小、最大、平均等待时间,以至精细到有个别索引的增加和删除改查的等候时间,表IO等待和锁等待事件instruments(wait/io/table/sql/handler和wait/lock/table/sql/handler )暗中同意开启,在setup_consumers表中无具体的照拂配置,暗中认可表IO等待和锁等待事件总结表中就会计算有关事件消息。包罗如下几张表:

PS:对那些表使用truncate语句,影响与等待事件类似。

------------------------------------------------------ -------------------------------------- ------------

·mutex_instances:wait sync相关的Mutex对象实例;

root@localhost : performance _schema 11:08:23> select * from events_waits _summary_by _thread_by _event_name limit 1G

| events_statements_summary_by_thread_by_event_name |

要求全数互斥体的做事负荷能够被以为是居于1个要害职位的办事,多少个查询大概须求以种类化的秘籍(一回一个串行)实施那些重中之重部分,但那说不定是2个隐私的性质瓶颈。

EVENT _NAME: wait/synch/mutex/sql/TC_LOG _MMAP::LOCK_tc

SPINS: NULL

该表的分组列与table_io_waits_summary_by_table表相同

AVG _TIMER_WAIT: 0

----------------------------------------

·当呼吁元数据锁不能够及时获得时,将插入状态为PENDING的锁音讯行;

SUM _TIMER_WAIT: 0

二.一. 检查当前数据库版本是不是援救

MAX_TIMER_READ_NORMAL: 0

root@localhost : performance _schema 11:08:36> select * from events_waits _summary_by _user_by _event_name limit 1G

| wait/synch/mutex/sql/LOCK_plugin |86027823|

............

performance_schema会记录内存使用情形并群集内存使用总括音讯,如:使用的内部存款和储蓄器类型(各个缓存,内部缓冲区等)和线程、帐号、用户、主机的相干操作直接实行的内存操作。performance_schema从利用的内部存款和储蓄器大小、相关操作数量、高低水位(内存1回操作的最大和纤维的相干总计值)。

| 0 |

·当呼吁立时获得元数据锁时,将插入状态为GRANTED的锁信息行;

HOST: localhost

TIMER_WAIT: 65664

OBJECT_TYPE: TABLE

MIN_TIMER_WAIT:给定计时事件的小小等待时间

qogir_env@localhost : performance_schema 06:17:23> SELECT EVENT_NAME,COUNT_STAR FROM events_waits_summary_global_by_event_name

---------------------------------------- ----------------------- ----------- ----------- -------------------- ------- --------

* 读写作业平时比只读事务占用更加多财富,因而事务计算表包罗了用来读写和只读事务的单身计算列

------------------------------------------------

| OBJECT_TYPE |OBJECT_SCHEMA | OBJECT_NAME |OBJECT_INSTANCE_BEGIN | OWNER_THREAD_ID |OWNER_EVENT_ID | INTERNAL_LOCK |EXTERNAL_LOCK |

* 注意:若是在server运转之后再修改memory instruments,恐怕会产生由于丢失在此之前的分配操作数据而导致在放出之后内部存款和储蓄器总括音讯出现负值,所以不建议在运作时1再按钮memory instruments,要是有内部存款和储蓄器事件总计须要,提议在server运行之前就在my.cnf中配备好内需计算的轩然大波采访

| events_statements_summary_by_digest |

对应的instruments为wait/io/table/sql/handler和wait/lock/table/sql/handler,私下认可开启。

COUNT_STAR: 7

下卷将为我们分享 "performance_schema之二(配置表详解)" ,多谢您的读书,我们不见不散!再次来到搜狐,查看更加多

3rows inset ( 0. 00sec)

COUNT_STAR: 1

5rows inset (0.00sec)

| Tables_in_performance_schema (%file_summary%) |

| events_stages_summary_by_account_by_event_name |

|performance_schema | ON |

accounts表字段含义如下:

EVENT_NAME: memory/innodb/fil0fil

-------------------- -------

root@localhost : performance _schema 05:11:45> select * from socket_summary _by_instance where COUNT_STAR!=0G;

1 row in set (0.00 sec)

qogir_env@localhost : performance_schema 02:41:54> show engines;

·OBJECT_TYPE:呈现handles锁的类别,表示该表是被哪些table handles展开的;

-------------------------------------------------

| events_waits_history_long |

咱俩先来看看表中记录的总计音信是何许体统的。

root@localhost : performance _schema 11:29:27> select * from events_stages _summary_by _host_by _event_name where HOST is not null limit 1G

Rowsmatched: 3 Changed: 3 Warnings: 0

OBJECT_SCHEMA: xiaoboluo

当某给定对象被删去时,该目的在events_statements_summary_by_program表中的总括音讯就要被去除;

ORDER BY COUNT_STAR DESC LIMIT 10;

session_account_connect_attrs表差别意使用TRUNCATE TABLE语句。

| events_statements_summary_by_host_by_event_name |

------------------------------------------------

·只要值为NULL,则意味着表I/O未有利用到目录

事情聚合计算规则

5rows inset (0.01sec)

允许实行TRUNCATE TABLE语句,可是TRUNCATE TABLE只是重新初始化prepared_statements_instances表的计算音信列,可是不会去除该表中的记录,该表中的记录会在prepare对象被灭绝释放的时候自动删除。

* 平时,truncate操作会复位总括消息的原则数据(即清空从前的数据),但不会修改当前server的内部存储器分配等情事。相当于说,truncate内部存款和储蓄器总括表不会自由已分配内存

***************************

admin@localhost : performance_schema 06:50:03> show tables like '%table%summary%';

root@localhost : performance _schema 01:25:13> select * from events_transactions _summary_by _host_by _event_name where COUNT_STAR!=0 limit 1G

------------------------------------------------------

file_instances表字段含义如下:

------------------------------------------------------------

------------------------------------------------------

LOCK_STATUS: GRANTED

MAX _TIMER_WAIT: 0

| variables_by_thread |

·OBJECT_INSTANCE_BEGIN:此列是套接字实例对象的绝无仅有标记。该值是内部存款和储蓄器中对象的地址;

# events_statements_summary_by_user_by_event_name表

直接在performance_schema库下使用show tables语句来查阅有如何performance_schema引擎表:

对于代码中的每一个互斥体,performance_schema提供了以下消息:

1 row in set (0.00 sec)

------------------------------------------------------

·file_summary_by_event_name:根据种种事件名称实行计算的文件IO等待事件

MIN _TIMER_WAIT: 0

-----------------------------------------------

应用程序能够动用mysql_options()和mysql_options肆()C API函数在一而再时提供一些要传送到server的键值对接二连三属性。

MAX_TIMER_WAIT: 80968744000

| events_statements_current |

上面对这么些表分别展开验证。

HOST: localhost

--------------------------------------------------- ------------

* _program_name:客户端程序名称

SUM _SELECT_FULL _RANGE_JOIN: 0

| wait/synch/mutex/mysys/THR_LOCK_open |187|

| localhost |1| 1 |

* SUM_NUMBER_OF_BYTES_FREE:增加N

主编:

·THREAD_ID:由server分配的里边线程标识符,各种套接字都由单个线程实行田间管理,因而各类套接字都得以映射到三个server线程(假若得以映射的话);

* COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE:施行prepare语句对象的总结音信

Rowsmatched: 323 Changed: 0 Warnings: 0

(2)users表

USER: root

| Tables_in_performance_schema (%setup%) |

MIN _TIMER_WAIT: 56688392

# events_transactions_summary_by_user_by_event_name表

---------------------------------------- ----------------

------------------------------------ -------------------------------------- ------------

# events_statements_summary_by_account_by_event_name表

今日,你能够在performance_schema下使用show tables语句或许通过查询 INFOEnclaveMATION_SCHEMA.TABLES表中performance_schema引擎相关的元数据来了解在performance_schema下存在着哪些表:

·VICTIM,TIMEOUT和KILLED状态值停留时间很轻巧,当多个锁处于这么些情景时,那么表示该锁行消息就要被去除(手动施行SQL大概因为日子原因查看不到,能够使用程序抓取);

COUNT_STAR: 0

| file_summary_by_instance |

SUM_LOCK_TIME: 0

SUM _TIMER_READ_WRITE: 8592136000

2.3. performance_schema表的归类

EVENT_NAME: wait/io/socket/sql/server_unix_socket

root@localhost : performance _schema 11:08:05> select * from events_waits _summary_by_instance limit 1G

| /data/mysqldata1/mydata/mysql/help_relation.ibd |wait/io/file/innodb/innodb_data_file | 3 |

------------------------------------------------------- ----------------------- --------------------------- ----------------------

当贰个可被监察和控制的内部存款和储蓄器块N被分配时,performance_schema会对内部存款和储蓄器总计表中的如下列进行立异:

PS:本体系小说所使用的数据库版本为 MySQL 官方 5.七.一柒版本

·ATTR_NAME:连接属性名称;

events_waits_summary_by_account_by_event_name表:按照列EVENT_NAME、USEBMWX伍、HOST实行分组事件信息

----------- ---------- ------------------------------------------ ------------

MAX_TIMER_WAIT: 18446696808701862260

admin@localhost : performance_schema 06:37:45> show tables like '%events_transactions_summary%';

1row inset (0.00sec)

table_handles表不允许行使TRUNCATE TABLE语句。

| events_statements_summary_by_thread_by_event_name |

-----------------------------------------

* _os:操作系统类型(比方Linux,Win6四)

# events_stages_summary_by_host_by_event_name表

------------------------------------------------------

·server 监听三个socket以便为网络连接协议提供协理。对于监听TCP/IP或Unix套接字文件接二连三来讲,分别有二个名称为server_tcpip_socket和server_unix_socket的socket_type值,组成对应的instruments名称;

1 row in set (0.00 sec)

  1. row ***************************

·LOCK_DURATION:来自元数据锁子系统中的锁定期间。有效值为:STATEMENT、TRANSACTION、EXPLICIT,STATEMENT和TRANSACTION值分别表示在说话或作业甘休时会释放的锁。 EXPLICIT值表示能够在言语或工作甘休时被会保留,需求显式释放的锁,举例:使用FLUSH TABLES WITH READ LOCK获取的大局锁;

我们先来看望那些表中著录的总结新闻是如何样子的。

|4| 341 |wait/synch/mutex/innodb/fil_system_mutex | 84816 |

我们先来看望表中著录的总计音讯是何许样子的。

--------------------------------------------------------------

root@localhost : performance_schema 12:18:46> show tables like '%setup%';

| table_lock_waits_summary_by_table |# 根据每一种表进行计算的表锁等待事件

............

qogir_env@localhost : performance_schema 03:53:51> show tables like 'events_wait%';

·OBJECT_NAME:instruments对象的称号,表品级对象;

root@localhost : performance _schema 11:55:11> select * from memory_summary _by_thread _by_event _name where COUNT_ALLOC!=0 limit 1G

2.4. performance_schema轻易安插与利用

-------------------------------------------------

SUM _NUMBER_OF _BYTES_FREE: 3296

| cond_instances |

-----------------------------------------------

| events_statements_summary_global_by_event_name |

NUMBER_OF_BYTES: NULL

| Tables_in_performance_schema (%socket%summary%) |

1row inset ( 0. 00sec)

| events_transactions_history_long |

|4| _platform |x86_64 | 4 |

由于performance_schema表内部存款和储蓄器限制,所以珍视了DIGEST = NULL的离奇行。 当events_statements_summary_by_digest表限制体积已满的情事下,且新的讲话总结新闻在须要插入到该表时又不曾在该表中找到相称的DIGEST列值时,就会把那几个语句总计消息都总括到 DIGEST = NULL的行中。此行可援救您猜想events_statements_summary_by_digest表的限量是还是不是须求调动

ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

admin@localhost : performance_schema 10:49:34> select * from socket_instances;

# events_waits_summary_by_user_by_event_name表

|目 录1、什么是performance_schema

由此对以下七个表实行查询,能够达成对应用程序的监督或DBA能够检查测试到关系互斥体的线程之间的瓶颈或死锁信息(events_waits_current能够查阅到近年来正在等候互斥体的线程音信,mutex_instances可以查看到当下某些互斥体被哪些线程持有)。

-------------------------------------------------

2.3. performance_schema表的分类

admin@localhost : performance_schema 02:50:02> select * from cond_instances limit 1;

注意:那些表只针对专门的学业事件音信实行总括,即包蕴且仅包罗setup_instruments表中的transaction采撷器,各类职业事件在各样表中的计算记录行数要求看怎么分组(举例:依照用户分组总括的表中,有稍许个活泼用户,表中就会有稍许条一样搜集器的笔录),别的,总括计数器是不是见效还索要看transaction采撷器是还是不是启用。

TIMER_START: 1582395491787124480

session_account_connect_attrs表字段含义:

root@localhost : performance _schema 11:50:46> update setup_instruments set enabled='yes',timed='yes' where name like 'memory/%';

2、performance_schema使用高效入门

COUNT_REPREPARE: 0

*************************** 1. row ***************************

------------------------------------------------------

|4| _os |linux-glibc2. 5| 0 |

* LOW_COUNT_USED和HIGH_COUNT_USED将重新初始化为CU宝马7系RENT_COUNT_USED列值

| 4 |350| wait/synch/mutex/innodb/log_sys_mutex |25536|

AVG_TIMER_READ_NORMAL: 0

prepared_statements_instances:依据种种prepare语句实例聚合的计算新闻

-------------------- --------- ---------------------------------------------------------------- -------------- ------ ------------

我们先来探视表中记录的总计音信是怎样体统的。

COUNT _READ_ONLY: 1

| events_waits_summary_global_by_event_name |

# socket_summary_by_event_name表

# events_statements_summary_by_program表(必要调用了蕴藏进程或函数之后才会有数据)

-------------------- -------

OBJECT _INSTANCE_BEGIN: 2655350784

OBJECT_SCHEMA: sys

21 rows inset (0.00 sec)

COUNT_STAR: 1

root@localhost : performance _schema 11:37:03> select * from events_stages _summary_by _thread_by _event_name where thread_id is not null limit 1G

| /data/mysqldata1/mydata/mysql/innodb_table_stats.ibd |wait/io/file/innodb/innodb_data_file | 3 |

·多多MySQL客户端程序设置的属性值与客户端名称相等的2个program_name属性。例如:mysqladmin和mysqldump分别将program_name连接属性设置为mysqladmin和mysqldump,其余一些MySQL客户端程序还定义了增大属性:

events_statements_summary_by_thread_by_event_name:依照每一个线程和事件名称实行总括的Statement事件

------------------------------------------------------

# table_lock_waits_summary_by_table表

THREAD_ID: 37

配置好之后,大家就能够查阅server当前正在做什么,能够经过查询events_waits_current表来获知,该表中各样线程只含有一行数据,用于展示每种线程的洋气监视事件(正在做的业务):

admin@localhost : performance_schema 03:23:47> select * from mutex_instances limit 1;

SUM_SELECT_SCAN: 45

2.2. 启用performance_schema

·对此经过TCP/IP 套接字(client_connection)的客户端连接,端口是server随机分配的,但不会为0值. IP是源主机的IP(127.0.0.一或地点主机的:: 壹)。

performance_schema把内部存款和储蓄器事件总结表也依照与等待事件总计表类似的规则实行分拣总计。

OBJECT_NAME: NULL

原标题:数据库对象事件与品质总括 | performance_schema全方位介绍(五)

对此内部存款和储蓄器块的放飞,遵照如下规则举办检查测试与集中:

qogir_env@localhost : performance_schema 03:51:36> show tables like 'events_statement%';

MIN_TIMER_WAIT: 1905016

EVENT_NAME: transaction

| /data/mysqldata1/undo/undo004 |wait/io/file/innodb/innodb_data_file | 3 |

OBJECT_NAME: test

| events_statements_summary_by_account_by_event_name |

金沙技术 1

OWNER_OBJECT_NAME: NULL

| events_statements_summary_by_program |

qogir_env@localhost: performance_schema 03:34:40> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'where name like 'wait%';;

| wait/io/socket/sql/server_tcpip_socket |110667200| 1 |32| :: |3306| ACTIVE |

COUNT_STAR: 7

| events_statements_summary_by_user_by_event_name |

admin@localhost : performance _schema 01:56:16> select * from table_io _waits_summary _by_table where SUM _TIMER_WAIT!=0G;

1 row in set (0.00 sec)

| memory_summary_by_account_by_event_name |

# file_summary_by_instance表

USER: root

等第事件记录表,记录语句推行的级差事件的表,与话语事件类型的连锁记录表类似:

·OBJECT_INSTANCE_BEGIN:读写锁实例的内部存储器地址;

*************************** 1. row ***************************

| /data/mysqldata1/mydata/mysql/help_category.ibd |wait/io/file/innodb/innodb_data_file | 3 |

·metadata_locks:元数据锁的享有和请求记录;

HOST: NULL

9rows inset (0.00sec)

从表中的记录内容能够看出,依据库xiaoboluo下的表test实行分组,计算了表相关的等候事件调用次数,总括、最小、平均、最大延迟时间音信,利用这一个信息,大家能够大约掌握InnoDB中表的造访功用排名总括意况,一定水准上反应了对存款和储蓄引擎接口调用的频率。

COUNT_ALLOC: 103

performance_schema完结机制遵从以下设计目的:

这么些连接表都允许使用TRUNCATE TABLE语句:

CURRENT_COUNT_USED: 0

当今,异常的热情洋溢的告诉大家,大家依据 MySQL 官方文书档案加上我们的辨证,整理了1份能够系统学习 performance_schema 的资料分享给大家,为了便于大家阅读,大家整理为了1个雨后冬笋,一共七篇小说。下边,请跟随我们一同起来performance_schema系统的学习之旅吧。

EVENT_NAME: wait/io/file/innodb/innodb_data_file

# 假如须求计算内存事件音信,须求展开内部存款和储蓄器事件收集器

MySQL的performance schema 用于监察和控制MySQL server在1个异常的低等其他周转进程中的能源消耗、财富等待等意况,它具备以下特征:

*************************** 1. row ***************************

EVENT_NAME: statement/sql/select

原标题:初相识|performance_schema全方位介绍(1)

文本I/O事件计算表允许行使TRUNCATE TABLE语句。但只将总括列重新恢复设置为零,而不是删除行。

从地点表中的以身作则记录新闻中,大家得以看出,同样与等待事件类似,依照用户、主机、用户 主机、线程等纬度举办分组与计算的列,分组列与等待事件类似,那里不再赘述,但对此内部存款和储蓄器总结事件,总计列与别的二种事件总结列区别(因为内部存款和储蓄器事件不总结时间支出,所以与任何二种事件类型相比较无1致总结列),如下:

_current表中各个线程只保留一条记下,且壹旦线程落成职业,该表中不会再记录该线程的轩然大波音信,_history表中著录各个线程已经推行到位的风云消息,但种种线程的只事件音讯只记录十条,再多就会被掩盖掉,*_history_long表中著录全部线程的事件音信,但总记录数据是一千0行,当先会被覆盖掉,未来咱们查看一下历史表events_waits_history 中著录了何等:

------------------------------------------------

SUM _TIMER_WAIT: 0

| events_stages_summary_by_host_by_event_name |

*************************** 3. row ***************************

1 row in set (0.00 sec)

通过从INFORMATION_SCHEMA.tables表查询有哪些performance_schema引擎的表:

·STATE:套接字状态,有效值为:IDLE或ACTIVE。追踪活跃socket连接的等待时间利用相应的socket instruments。跟着空闲socket连接的等候时间利用3个号称idle的socket instruments。若是一个socket正在等候来自客户端的呼吁,则该套接字此时高居空闲状态。当套接字处于空闲时,在socket_instances表中对应socket线程的音信中的STATE列值从ACTIVE状态切换成IDLE。EVENT_NAME值保持不变,不过instruments的命宫采访功效被暂停。同时在events_waits_current表中记录EVENT_NAME列值为idle的一条龙事件音信。当以此socket接收到下三个请求时,idle事件被甘休,socket instance从闲暇状态切换来活动状态,并上升套接字连接的时光收罗功效。

THREAD_ID: 46

|wait/io/file/sql/casetest | 104324715 |

performance_schema提供了针对性prepare语句的监督记录,并依照如下方法对表中的剧情开始展览管理。

EVENT_NAME: statement/sql/select

-----------------------------------------

* file_summary_by_event_name表:按照EVENT_NAME列实行分组 ;

*************************** 1. row ***************************

8rows inset (0.00sec)

·已予以的锁(展现怎么会话具备当前元数据锁);

events_waits_summary_by_thread_by_event_name表:按照列THREAD_ID、EVENT_NAME举行分组事件新闻

------------------------------------------------------

1 row in set (0.00 sec)

1 row in set (0.00 sec)

----------------------------------------

从客户端发送到服务器的总是属性数据量存在限制:客户端在一连之前客户端有1个融洽的一向长度限制(不可配置)、在客户端连接server时服务端也有1个定点长度限制、以及在客户端连接server时的连天属性值在存入performance_schema中时也有二个可安排的长短限制。

AVG _TIMER_WAIT: 0

依据事件类型分组记录质量事件数量的表

·对于Unix domain套接字(server_unix_socket)的server端监听器,端口为0,IP为空白;

AVG _TIMER_WAIT: 0

|4| 343 |wait/io/file/innodb/innodb_log_file | 544126864 |

·PORT:TCP/IP端口号,取值范围为0〜65535;

1 row in set (0.00 sec)

instance表记录了怎么着项目标靶子会被检验。那些目标在被server使用时,在该表师长会生出一条事件记录,举个例子,file_instances表列出了文件I/O操作及其关联文件名:

·TOTAL_CONNECTIONS:某帐号的总连接数(新增加个老是累计1个,不会像当前连接数那样连接断开会收缩)。

SUM _TIMER_WAIT: 0

| Tables_in_performance_schema (%stage%) |

依照数据库对象名称(库等级对象和表等级对象,如:库名和表名)举行计算的等候事件。根据OBJECT_TYPE、OBJECT_SCHEMA、OBJECT_NAME列举办分组,依据COUNT_STAR、xxx_TIMER_WAIT字段进行总计。包罗一张objects_summary_global_by_type表。

SUM_ROWS_AFFECTED: 0

performance_schema被视为存款和储蓄引擎。假诺该引擎可用,则应该在INFORAV4MATION_SCHEMA.ENGINES表或SHOW ENGINES语句的输出中都能够看来它的SUPPORT值为YES,如下:

元数据锁instruments使用wait/lock/metadata/sql/mdl,暗许未开启。

MIN _TIMER_WAIT: 0

qogir_env@localhost : performance_schema 03:21:06> show tables from performance_schema;

| file_summary_by_instance |

MIN _TIMER_WAIT: 0

| events_stages_current |

admin@localhost : performance _schema 11:01:23> select * from file_summary _by_instance where SUM _TIMER_WAIT!=0 and EVENT_NAME like '%innodb%' limit 1G;

# events_waits_summary_by_thread_by_event_name表

EVENT_NAME: wait/synch/mutex/innodb/log_sys_mutex

·OBJECT_SCHEMA:该锁来自于哪个库级其余靶子;

* 借使给定语句的计算新闻行在events_statements_summary_by_digest表中未有已存在行,并且events_statements_summary_by_digest表空间限制未满的动静下,会在events_statements_summary_by_digest表中新插入壹行总括音讯,FI昂科雷ST_SEEN和LAST_SEEN列都选择当前岁月

1row inset (0.00sec)

* 使用mysqlnd编译:只有_client_name属性,值为mysqlnd

COUNT_STAR: 0

| wait/io/file/sql/MYSQL_LOG |1599816582|

每种连接音讯表都有CULANDRENT_CONNECTIONS和TOTAL_CONNECTIONS列,用于追踪连接的此时此刻连接数和总连接数。对于accounts表,每种连接在表中每行新闻的绝无仅有标记为USE猎豹CS陆 HOST,可是对于users表,唯有三个user字段举行标记,而hosts表唯有一个host字段用于标记。

DIGEST: 4fb483fe710f27d1d06f83573c5ce11c

EVENT_ID: 60

SUM_TIMER_WAIT: 412754363625

USER: root

| events_statements_history |

| table_io_waits_summary_by_index_usage |# 根据各种索引进行总结的表I/O等待事件

*************************** 1. row ***************************

qogir_env@localhost : performance_schema 02:41:41> SELECT * FROM INFORMATION_SCHEMA.ENGINES WHERE ENGINE ='PERFORMANCE_SCHEMA';

·rwlock_instances:wait sync相关的lock对象实例;

root@localhost : performance _schema 01:25:27> select * from events_transactions _summary_by _thread_by _event_name where SUM _TIMER_WAIT!=0G

qogir_env@localhost : performance_schema 03:58:27> show tables like '%file%';

·当连接终止时,在socket_instances表中对应的总是音讯行被剔除。

咱俩先来探望那几个表中记录的总括消息是怎么着体统的(由于单行记录较长,那里只列出memory_summary_by_account_by_event_name 表中的示例数据,其他表的以身作则数据省略掉①部分同样字段)。

“翻过那座山,你就可以看来一片海”

* _client_version:客户端libmysql库版本

| 阶段事件计算表

监视文件系统层调用的表:

OBJECT_SCHEMA: xiaoboluo

COUNT_STAR: 7

| Tables_in_performance_schema (%statement%) |

按照与table_io_waits_summary_by_table的分组列 INDEX_NAME列进行分组,INDEX_NAME有如下几种:

* 内存instruments在setup_instruments表中全部memory/code_area/instrument_name格式的名号。但私下认可情况下大诸多instruments都被剥夺了,暗许只开启了memory/performance_schema/*开头的instruments

开荒等待事件的搜集器配置项开关,必要修改setup_instruments 配置表中对应的采撷器配置项

socket_instances表列出了连接到MySQL server的活跃接连的实时快照消息。对于各种连接到mysql server中的TCP/IP或Unix套接字文件接二连三都会在此表中著录一行新闻。(套接字总括表socket_summary_by_event_name和socket_summary_by_instance中提供了一些增大消息,比方像socket操作以及互连网传输和接收的字节数)。

events_waits_summary_global_by_event_name表:按照EVENT_NAME列进行分组事件新闻

| events_waits_current |

table_lock_waits_summary_by_table表:

* SUM_NUMBER_OF_BYTES_ALLOC,SUM_NUMBER_OF_BYTES_FREE:已分配和已出狱的内部存款和储蓄器块的总字节大小

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

·当3个线程正在等候某事产生时,condition NAME列呈现了线程正在等候什么condition(但该表中并不曾此外列来显示对应哪个线程等音信),不过目前还尚未一贯的艺术来判断有个别线程或少数线程会促成condition发生变动。

IT从业多年,历任运行程序猿、高档运营程序员、运转首席营业官、数据库程序员,曾参加版本宣布类别、轻量级监察和控制连串、运行处理平台、数据库管理平台的规划与编辑,熟谙MySQL种类布局,Innodb存款和储蓄引擎,喜好专研开源技艺,追求布帆无恙。

使用 INFORMATION_SCHEMA.ENGINES表来询问你的数据库实例是或不是援助INFO汉兰达MATION_SCHEMA引擎

作者们先来探视表中著录的总结音讯是怎么样体统的。

*************************** 1. row ***************************

蹲点内存使用的表:

mutex_instances.LOCKED_BY_THREAD_ID和rwlock_instances.WRITE_LOCKED_BY_THREAD_ID列对于排查质量瓶颈或死锁难点根本。

| Tables_in_performance_schema (%events_waits_summary%) |

|wait/io/file/sql/FRM | 1292823243 |

---------------- ---------------------------------- --------------------- ------------------

events_statements_summary_by_account_by_event_name:根据每种帐户和语句事件名称举办总结

|wait/synch/mutex/mysys/THR_LOCK_malloc | 1530083250 |

*************************** 1. row ***************************

SCHEMA_NAME: NULL

| /data/mysqldata1/mydata/multi_master/test.ibd |wait/io/file/innodb/innodb_data_file | 1 |

1row inset ( 0. 00sec)

MIN _TIMER_WAIT: 0

qogir_env@localhost : performance_schema 03:55:30> show tables like 'events_transaction%';

· OWNER_THREAD_ID:持有该handles锁的线程ID;

MAX_TIMER_WAIT:给定计时事件的最大等待时间

| accounts |

admin@localhost : performance _schema 11:00:44> select * from file_summary _by_event _name where SUM_TIMER _WAIT !=0 and EVENT_NAME like '%innodb%' limit 1G;

# events_statements_summary_by_host_by_event_name表

| /data/mysqldata1/mydata/mysql/help_topic.ibd |wait/io/file/innodb/innodb_data_file | 3 |

......

......

|PERFORMANCE_SCHEMA | YES |Performance Schema

MIN_TIMER_EXECUTE: 0

当某给定对象在server中第1遍被应用时(即采取call语句调用了蕴藏进度或自定义存款和储蓄函数时),将要events_statements_summary_by_program表中加多壹行计算音信;

-------------------- --------- ---------------------------------------------------------------- -------------- ------ ------------

*************************** 1. row ***************************

*************************** 1. row ***************************

[mysqld]

MAX _TIMER_WAIT: 56688392

COUNT_ALLOC: 158

| users |

SUM_ROWS_SENT: 0

关于events_statements_summary_by_digest表

本文由金沙国际娱城发布于金沙技术,转载请注明出处:金沙技术初相识|performance_schema全方位介绍(一

关键词: 金沙国际娱城 科技 58 AR CES

上一篇:金沙技术金立P30/P30 Pro:陆仟万像素摄像头 十倍

下一篇:没有了