微尼斯人娱乐MySQL Performance-Schema(贰) 理论篇,p

作者:威尼斯人技术

|wait/io/file/sql/pid | 72591750 |

# table_io_waits_summary_by_table表

OBJECT _INSTANCE_BEGIN: 32492032

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

     MySQL Performance-Schema中一共包罗5二个表,首要分为几类:Setup表,Instance表,Wait 伊芙nt表,Stage 伊芙nt表Statement 伊芙nt表,Connection表和Summary表。上一篇文章已经首要讲了Setup表,那篇小说将会分别就每连串型的表做详细的描述。

Instance表
     instance中驷不及舌包含了伍张表: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/TH冠道_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-POEscortT音信,能够与运用接入起来。
event_name主要含有三类:
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表则记录了近期全部线程发生的10000个事件,这里的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。
SOUPAJEROCE:该事件产生时的源码文件
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能够唯1鲜明一条记下。表中记录了当下线程所处的实践阶段,由于能够通晓各类阶段的实行时间,因而通过stage表能够拿走SQL在各个阶段消耗的年月。

THREAD_ID:线程ID
EVENT_ID:事件ID
END_EVENT_ID:刚结束的轩然大波ID
SOU奥迪Q5CE:源码地点
TIMER_START, TIMER_END, TIMER_WAIT:事件初始/甘休和等候的光阴,单位为阿秒(picoseconds)
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT, STAGE, WAIT)

Statement Event表
      Statement表重要涵盖二个表,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时,第3个表位全表扫描的数量
SORT_ROWS:排序的记录数据
NESTING_EVENT_ID,NESTING_EVENT_TYPE,保留字段,为NULL。

Connection表
     Connection表记录了客户端的新闻,首要不外乎3张表:users,hosts和account表,accounts包蕴hosts和users的新闻。
USER:用户名
HOST:用户的IP

Summary表
    Summary表聚集了各种维度的总计音讯包罗表维度,索引维度,会话维度,语句维度和锁维度的计算信息。
(1).wait-summary表
events_waits_summary_global_by_event_name
境况:按等待事件类型聚合,每种事件一条记下。
events_waits_summary_by_instance
此情此景:按等待事件目的聚合,同壹种等待事件,大概有八个实例,每一个实例有两样的内部存款和储蓄器地址,由此
event_name object_instance_begin唯一分明一条记下。
events_waits_summary_by_thread_by_event_name
此情此景:按每种线程和事件来总结,thread_id event_name唯一明显一条记下。
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:第5个语句执行的年月
LAST_SEEN_TIMESTAMP:最终一个口舌执行的小时
现象:用于总结某1段时间内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
INSE中华VT总括,相应的还有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中一共包罗5两个表,主要分为几类:Setup表,Instance表,Wait 伊夫nt表,Stage Ev...

| events_stages_history_long |

......

SUM _TIMER_WAIT: 0

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

OBJECT _INSTANCE_BEGIN: 2658004160

COUNT_ALLOC: 216

NESTING_EVENT_ID: NULL

COUNT_REPREPARE: 0

由于performance_schema表内部存款和储蓄器限制,所以爱戴了DIGEST = NULL的很是行。 当events_statements_summary_by_digest表限制体积已满的场所下,且新的讲话计算信息在需求插入到该表时又从不在该表中找到相配的DIGEST列值时,就会把那么些语句总结音信都计算到 DIGEST = NULL的行中。此行可帮助您测度events_statements_summary_by_digest表的限定是或不是要求调动

近年来,是还是不是认为下边的介绍内容太过平淡呢?倘使您那样想,那就对了,作者当下求学的时候也是那样想的。但未来,对于哪些是performance_schema那么些题材上,比起更早在此以前更清晰了吧?要是你还尚无打算要放任读书本文的话,那么,请随行大家初步进入到"边走边唱"环节呢!

admin@localhost : performance _schema 11:10:42> select * from objects_summary _global_by _type where SUM_TIMER_WAIT!=0G;

USER: root

|PERFORMANCE_SCHEMA | YES |Performance Schema | NO |NO | NO |

3rows inset ( 0. 00sec)

root@localhost : performance _schema 11:08:53> select * from events_waits _summary_global _by_event_name limit 1G

mysqld运转之后,通过如下语句查看performance_schema是不是启用生效(值为ON表示performance_schema已初始化成功且可以应用了。假设值为OFF表示在启用performance_schema时爆发1些错误。能够查阅错误日志举行排查):

OBJECT _INSTANCE_BEGIN: 2655351104

咱俩先来看看这一个表中记录的总结音讯是怎么体统的。

| events_transactions_summary_by_user_by_event_name |

当客户端与server端建立连接时,performance_schema使用符合各样表的绝无仅有标识值来鲜明每一个连接表中哪些进行记录。即便缺乏对应标识值的行,则新添加一行。然后,performance_schema会大增该行中的CU奥迪Q三RENT_CONNECTIONS和TOTAL_CONNECTIONS列值。

如果setup_consumers配置表中statements_digest consumers启用,则在言语执行到位时,将会把讲话文本进行md5 hash总结之后 再发送到events_statements_summary_by_digest表中。分组列基于该语句的DIGEST列值(md5hash值)

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

·OBJECT_INSTANCE_BEGIN:mutex instruments实例的内存地址;

SUM_TIMER_WAIT: 234614735000

summary表提供具有事件的汇聚新闻。该组中的表以差别的方法集中事件数量(如:按用户,按主机,按线程等等)。例如:要查看哪些instruments占用最多的时日,能够透过对events_waits_summary_global_by_event_name表的COUNT_STAR或SUM_TIMER_WAIT列举办查询(那两列是对事件的记录数执行COUNT(*)、事件记录的TIMEQashqai_WAIT列执行SUM(TIMER_WAIT)总括而来),如下:

二.表I/O等待和锁等待事件总括

MAX _TIMER_WAIT: 0

THREAD_ID: 4

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

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

| events_stages_summary_by_host_by_event_name |

table_lock_waits_summary_by_table表:

......

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

·execute步骤:语法EXECUTE stmt_name[USING @var_name [, @var_name] …],示例:execute stmt; 再次来到执行结果为1,此时在prepared_statements_instances表中的计算音信会进展更新;

MIN _TIMER_WAIT: 0

|EVENT_NAME | SUM_TIMER_WAIT |

AVG_TIMER_READ: 0

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

| 4 |348| wait/io/file/innodb/innodb_log_file |693076224|

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

AVG _TIMER_READ_ONLY: 57571000

| 0 |

文件I/O事件总括表允许利用TRUNCATE TABLE语句。但只将总括列重置为零,而不是删除行。

EVENT_NAME: memory/innodb/fil0fil

performance_schema库下的表能够依据监视不一致的纬度实行了分组,例如:或根据分化数据库对象进行分组,或遵照差异的风云类型举行分组,或在根据事件类型分组之后,再进一步依据帐号、主机、程序、线程、用户等,如下:

·session_account_connect_attrs:记录当前对话及其相关联的别的会话的几次三番属性;

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

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

socket_instances表字段含义如下:

AVG _TIMER_WAIT: 0

# 那么些结果评释,TH猎豹CS陆_LOCK_malloc互斥事件是最热的。注:TH福睿斯_LOCK_malloc互斥事件仅在DEBUG版本中留存,GA版本不设有

MAX_TIMER_READ_NORMAL: 0

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

| 4 |342| wait/synch/mutex/innodb/fil_system_mutex |32832|

咱俩先来看看表中著录的总计消息是什么样样子的。

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

|Transactions | XA |Savepoints |

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

......

动态对performance_schema实行配备的配置表:

下边对那些表分别进行表达。

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

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

| Tables_in_performance_schema (%table%summary%) |

MAX _TIMER_WAIT: 0

qogir_env@localhost : performance_schema 03:58:38> show tables like '%memory%';

·OBJECT_TYPE:呈现handles锁的品种,表示该表是被哪些table handles打开的;

SUM _TIMER_WAIT: 0

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

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

内部存款和储蓄器计算表允许利用TRUNCATE TABLE语句。使用truncate语句时有如下行为:

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

MIN _TIMER_READ _WITH_SHARED_LOCKS: 0

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

微尼斯人娱乐 1

SOURCE: sql_parse.cc:6031

AVG _TIMER_WAIT: 0

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

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

root@localhost : performance _schema 11:21:04> select * from events_stages _summary_by _account_by _event_name where USER is not null limit 1G

遵照事件类型分组记录品质事件数量的表

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

SUM_SORT_RANGE: 0

| setup_consumers |

· OBJECT_INSTANCE_BEGIN:instruments condition的内部存款和储蓄器地址;

root@localhost : performance _schema 11:01:51> select * from events_statements _summary_by_digest limit 1G

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

admin@localhost : performance_schema 02:53:40> select * from file_instances where OPEN_COUNT> 0limit 1;

原标题:事件总结 | performance_schema全方位介绍(4)

| /home/mysql/program/share/english/errmsg.sys |wait/io/file/sql/ERRMSG

SUM_TIMER_READ_NORMAL: 0

# events_waits_summary_by_instance表

| variables_by_thread |

OBJECT_SCHEMA: xiaoboluo

MAX _TIMER_WAIT: 0

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

OBJECT_TYPE: TABLE

AVG _TIMER_WAIT: 1235672000

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

| NAME |OBJECT_INSTANCE_BEGIN |

1 row in set (0.00 sec)

Rowsmatched: 323 Changed: 0 Warnings: 0

·accounts:依照user@host的样式来对每一种客户端的总是进行总结;

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

| memory_summary_global_by_event_name |

应用程序能够运用mysql_options()和mysql_options四()C API函数在再而叁时提供1些要传送到server的键值对连年属性。

SUM _TIMER_WAIT: 0

| events_waits_summary_by_thread_by_event_name |

* _pid:客户端进度ID

| 等待事件总计表

NUMBER_OF_BYTES: NULL

透过对以下三个表执行查询,可以兑现对应用程序的监察和控制或DBA能够检查评定到关系锁的线程之间的部分瓶颈或死锁音信:

| events_transactions_summary_by_user_by_event_name |

| events_stages_summary_global_by_event_name |

·ORDINAL_POSITION:将接连属性添加到三番五次属性集的逐一。

| memory_summary_by_account_by_event_name |

ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

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

5rows inset ( 0. 00sec)

qogir_env@localhost : performance_schema 06:27:26> SELECT * FROM file_instances limit 20;

(1) session_account_connect_attrs表

SUM _TIMER_WAIT: 0

2.3. performance_schema表的归类

MIN_TIMER_EXECUTE: 0

1 row in set (0.00 sec)

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

·1经值为NULL,则代表表I/O未有动用到目录

root@localhost : performance _schema 11:02:15> select * from events_statements _summary_by _host_by _event_name where COUNT_STAR!=0 limit 1G

| events_statements_summary_by_user_by_event_name |

......

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

使用 INFORMATION_SCHEMA.ENGINES表来查询你的数据库实例是不是帮助INFO兰德酷路泽MATION_SCHEMA引擎

咱俩先来看看表中记录的总括消息是什么样子的。

AVG _TIMER_WAIT: 0

| events_stages_summary_by_user_by_event_name |

MAX_TIMER_READ: 9498247500

SCHEMA_NAME: NULL

| memory_summary_by_user_by_event_name |

OBJECT_NAME: test

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

END_EVENT_ID: 60

·session_connect_attrs:全体会话的连接属性。

MAX _TIMER_WAIT: 0

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

大家先来看望表中记录的总括新闻是怎么着样子的。

EVENT_NAME: memory/innodb/fil0fil

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

cond_instances表字段含义如下:

MAX_TIMER_WAIT: 80968744000

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

OBJECT_TYPE: TABLE

COUNT_STAR: 0

| events_statements_history |

EVENT_NAME: wait/io/socket/sql/client_connection

内部存储器事件在setup_consumers表中并没有独自的布署项,且memory/performance_schema/* instruments暗许启用,不能够在运转时或运转时关闭。performance_schema相关的内存总结音信只保存在memory_summary_global_by_event_name表中,不会保存在遵照帐户,主机,用户或线程分类聚合的内部存款和储蓄器总结表中。

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

套接字计算表允许使用TRUNCATE TABLE语句(除events_statements_summary_by_digest之外),只将总括列重置为零,而不是去除行。

SUM_ROWS_SENT: 1635

| /data/mysqldata1/innodb_log/ib_logfile0 |wait/io/file/innodb/innodb_log_file | 2 |

* _runtime_vendor:Java运转环境(JRE)供应商名称

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

| Engine |Support | Comment

|wait/synch/rwlock/session/LOCK_srv_session_collection | 31856216 |NULL | 0 |

MAX _TIMER_WAIT: 0

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

1 row in set (0.00 sec)

1 row in set (0.00 sec)

OBJECT_NAME: NULL

| table_lock_waits_summary_by_table |# 依照各种表进行总计的表锁等待事件

6rows inset ( 0. 00sec)

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

COUNT_STAR: 2560

COUNT_STAR: 7

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

OBJECT_NAME: test

# events_waits_summary_by_host_by_event_name表

| Tables_in_performance_schema (%wait%) |

咱俩先来看看表中著录的统计新闻是什么样子的。

1 row in set (0.00 sec)

| events_stages_current |

·当已予以的锁或挂起的锁请求被杀掉时,其锁状态从GRANTED或PENDING更新为KILLED;

EVENT_NAME: memory/innodb/fil0fil

打开等待事件的采集器配置项开关,须要修改setup_instruments 配置表中对应的采集器配置项

admin@localhost : performance_schema 09 :49:41> select * from hosts;

SUM _SELECT_FULL_JOIN: 21

讲话事件记录表,那么些表记录了话语事件新闻,当前讲话事件表events_statements_current、历史语句事件表events_statements_history和长语句历史事件表events_statements_history_long、以及汇聚后的摘要表summary,当中,summary表仍是能够遵照帐号(account),主机(host),程序(program),线程(thread),用户(user)和全局(global)再实行分割)

session_account_connect_attrs表分歧意采用TRUNCATE TABLE语句。

USER: root

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

·OBJECT_INSTANCE_BEGIN:此列是套接字实例对象的唯一标识。该值是内部存款和储蓄器中对象的地方;

| 阶段事件总括表

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

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

......

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

SUM _TIMER_READ: 56688392

* 以前缀memory/performance_schema命名的instruments能够收集performance_schema本身消耗的里边缓存区大小等音信。memory/performance_schema/* instruments暗中同意启用,不恐怕在运营时或运转时关闭。performance_schema本身相关的内部存款和储蓄器计算消息只保存在memory_summary_global_by_event_name表中,不会保存在依据帐户,主机,用户或线程分类聚合的内部存款和储蓄器计算表中

performance_schema= ON# 注意:该参数为只读参数,须要在实例运营在此以前安装才生效

Performance Schema通过metadata_locks表记录元数据锁音信:

AVG _TIMER_READ_WRITE: 1432022000

qogir_env@localhost : performance_schema 03:13:10> SHOW VARIABLES LIKE 'performance_schema';

二. 连连属性总结表

1 row in set (0.00 sec)

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

1 row in set (0.00 sec)

MAX _TIMER_WAIT: 0

PS:本连串小说所选拔的数据库版本为 MySQL 官方 伍.7.17版本

* _client_name:客户端名称(客户端库的libmysql)

大家先来看望这一个表中著录的总计消息是何等样子的。

| Tables_in_performance_schema (%file%) |

session_account_connect_attrs表字段含义:

HIGH _NUMBER_OF _BYTES_USED: 32

| /data/mysqldata1/innodb_ts/ibdata1 |wait/io/file/innodb/innodb_data_file | 3 |

MIN _TIMER_WAIT: 2971125

COUNT_ALLOC: 158

ORDER BY COUNT_STAR DESC LIMIT 10;

1 row in set (0.00 sec)

# events_stages_summary_by_host_by_event_name表

|performance_schema | ON |

我们先来探视表中著录的总括新闻是什么样体统的。

Rows matched: 377 Changed: 377 Warnings: 0

| wait/io/file/myisam/kfile |411193611|

* 如果log_error_verbosity系统变量设置值大于1,则performance_schema还会将错误新闻写入错误日志:

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

5rows inset (0.01sec)

* COUNT_MISC,SUM_TIMER_MISC,MIN_TIMER_MISC,AVG_TIMER_MISC,MAX_TIMER_MISC:那几个列计算了装有其余文件I/O操作,包含CREATE,DELETE,OPEN,CLOSE,STREAM_OPEN,STREAM_CLOSE,SEEK,TELL,FLUSH,STAT,FSTAT,CHSIZE,RENAME和SYNC系统调用。注意:这一个文件I/O操作未有字节计数新闻。

* HIGH_COUNT_USED和HIGH_NUMBER_OF_BYTES_USED是较高的高水位推断值。performance_schema输出的低水位值能够确认保障总结表中的内存分配次数和内部存款和储蓄器大于或等于当前server中真实的内部存款和储蓄器分配值

|导 语很久在此之前,当自身还在品尝着系统地球科学习performance_schema的时候,通过在网上各个搜索资料进行学习,但很遗憾,学习的成效并不是很鲜明,很多标称类似 "深远浅出performance_schema" 的篇章,基本上都以那种动不动就贴源码的品格,然后深入了后头却出不来了。对系统学习performance_schema的效能有限。

·LOCK_TYPE:元数据锁子系统中的锁类型。有效值为:INTENTION_EXCLUSIVE、SHARED、SHARED_HIGH_PRIO、SHARED_READ、SHARED_WRITE、SHARED_UPGRADABLE、SHARED_NO_WRITE、SHARED_NO_READ_WRITE、EXCLUSIVE;

HOST: NULL

| setup_instruments |

PS:socket总括表不会总括空闲事件生成的等候事件新闻,空闲事件的守候音讯是记录在伺机事件总计表中开始展览总结的。

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

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

* COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT:那几个列总结全数I/O操作数量和操作时间 ;

当二个可被监督的内部存款和储蓄器块N被分配时,performance_schema会对内部存款和储蓄器总括表中的如下列进行翻新:

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

3rows inset ( 0. 00sec)

| Tables_in_performance_schema (%events_transactions_summary%) |

| events_stages_summary_by_thread_by_event_name |

| admin |1| 1 |

当某给定对象被实施时,其相应的总计新闻将记录在events_statements_summary_by_program表中并开展总括。

| NO |NO | NO |

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

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

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

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

THREAD_ID: 47

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

| file_summary_by_instance |

COUNT_STAR: 7

TIMER_END: 1582395491787190144

2rows inset ( 0. 00sec)

COUNT_STAR: 55

| 0 |

COUNT_STAR: 802

5rows inset ( 0. 00sec)

NESTING_EVENT_TYPE: NULL

OBJECT_SCHEMA: xiaoboluo

EVENT_NAME: statement/sql/select

qogir_env@localhost : performance_schema 03:20:43> use performance_schema

......

SUM _SELECT_FULL _RANGE_JOIN: 0

本文小结

| Tables_in_performance_schema (%socket%summary%) |

AVG _TIMER_WAIT: 0

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

table_handles表字段含义如下:

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

Database changed

文本I/O事件计算表只记录等待事件中的IO事件(不含有table和socket子类别),文件I/O事件instruments暗中认可开启,在setup_consumers表中无实际的照应配置。它含有如下两张表:

* LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将重置为CUPRADORENT_NUMBER_OF_BYTES_USED列值

SOURCE: log0log.cc:1572

performance_schema通过如下表来记录相关的锁音信:

从地点表中的言传身教记录消息中,我们可以看到:

| /home/mysql/program/share/charsets/Index.xml |wait/io/file/mysys/charset

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

SUM _CREATED_TMP _DISK_TABLES: 3

| Variable_name |Value |

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

OBJECT_NAME: ps_setup_enable_consumer

  1. 提供了1种在数据库运转时实时检查server的里边实施意况的方式。performance_schema 数据库中的表使用performance_schema存款和储蓄引擎。该数据库重点关注数据库运营进程中的质量相关的数据,与information_schema不同,information_schema首要关怀server运维进程中的元数据音讯
  2. performance_schema通过监视server的事件来促成监视server内部运维景况, “事件”就是server内部活动中所做的别的事情以及相应的命宫消耗,利用那几个音信来判定server中的相关能源消耗在了哪儿?一般的话,事件能够是函数调用、操作系统的等待、SQL语句执行的等级(如sql语句执行进程中的parsing 或 sorting阶段)或许全部SQL语句与SQL语句集合。事件的搜集能够1本万利的提供server中的相关存款和储蓄引擎对磁盘文件、表I/O、表锁等能源的联合调用音讯。
  3. performance_schema中的事件与写入贰进制日志中的事件(描述数据修改的events)、事件安顿调度程序(那是壹种存款和储蓄程序)的轩然大波差异。performance_schema中的事件记录的是server执行有个别活动对少数财富的消耗、耗费时间、这几个移动实施的次数等情况。
  4. performance_schema中的事件只记录在地头server的performance_schema中,其下的那几个表中数据发生变化时不会被写入binlog中,也不会通过复制机制被复制到别的server中。
  5. 当前活蹦乱跳事件、历史事件和事件摘要相关的表中记录的信息。能提供有些事件的施行次数、使用时长。进而可用以分析有个别特定线程、特定对象(如mutex或file)相关联的位移。
  6. PERFORMANCE_SCHEMA存储引擎使用server源代码中的“检验点”来贯彻事件数量的收集。对于performance_schema达成机制自笔者的代码未有有关的单独线程来检查实验,这与其他功效(如复制或事件布置程序)分歧
  7. 采集的事件数量存款和储蓄在performance_schema数据库的表中。那些表能够使用SELECT语句询问,也得以应用SQL语句更新performance_schema数据库中的表记录(如动态修改performance_schema的setup_*起首的多少个布局表,但要注意:配置表的更改会立马生效,那会影响多少收集)
  8. performance_schema的表中的多寡不会持久化存款和储蓄在磁盘中,而是保存在内部存储器中,壹旦服务注重启,这么些多少会丢掉(包含配置表在内的壹切performance_schema下的富有数据)
  9. MySQL援救的有所平哈博罗内事件监察和控制效用都可用,但区别平塞内加尔达喀尔用来总计事件时间支付的计时器类型或然会有所差异。

* _client_version:客户端库版本

| Tables_in_performance_schema (%events_waits_summary%) |

| events_stages_summary_by_account_by_event_name |

元数据锁instruments使用wait/lock/metadata/sql/mdl,暗中同意未张开。

# events_statements_summary_by_program表(须求调用了储存进程或函数之后才会有多少)

| wait/io/file/sql/binlog_index |1385291934|

admin@localhost : performance _schema 01:55:49> select * from table_io _waits_summary _by_index _usage where SUM_TIMER_WAIT!=0G;

MAX _TIMER_WAIT: 0

| events_statements_current |

rwlock_instances表列出了server执行rwlock instruments时performance_schema所见的享有rwlock(读写锁)实例。rwlock是在代码中应用的协同机制,用于强制在加以时间内线程能够依据某个规则访问壹些公共能源。可以认为rwlock爱慕着这么些能源不被别的线程随意抢占。访问情势能够是共享的(八个线程可以而且具备共享读锁)、排他的(同时唯有四个线程在给定时间足以拥有排他写锁)或共享独占的(有些线程持有排他锁定时,同时允许任何线程执行不壹致性读)。共享独占访问被称为sxlock,该访问形式在读写场景下能够拉长并发性和可扩大性。

内部存款和储蓄器大小总结音信有助于了然当前server的内部存款和储蓄器消耗,以便及时开始展览内部存储器调整。内部存款和储蓄器相关操作计数有助于领会当前server的内部存款和储蓄器分配器的总体压力,及时掌握server品质数据。例如:分配单个字节第一百货公司万次与单次分配一百万个字节的性质成本是例外的,通过跟踪内部存款和储蓄器分配器分配的内部存款和储蓄器大小和分配次数就能够精通互相的异样。

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

PS:什么是prepare语句?prepare语句其实就是二个预编写翻译语句,先把SQL语句实行编写翻译,且能够设定参数占位符(例如:?符号),然后调用时经过用户变量传入具体的参数值(叫做变量绑定),假如三个言语供给频仍进行而仅仅只是where条件分裂,那么使用prepare语句可以大大减弱硬解析的支出,prepare语句有七个步骤,预编写翻译prepare语句,执行prepare语句,释放销毁prepare语句,prepare语句补助二种协议,前边已经涉嫌过了,binary协商1般是提须要应用程序的mysql c api接口格局访问,而文本协议提供给通过客户端连接到mysql server的方式访问,下边以文件协议的方法访问进行现身说法验证:

* HIGH_COUNT_USED:如果CURRENT_COUNT_USED扩展一是二个新的最高值,则该字段值相应扩充

instance表记录了什么类型的指标会被检查评定。那几个指标在被server使用时,在该表大校会时有发生一条事件记录,例如,file_instances表列出了文本I/O操作及其涉及文件名:

| qfsys |1| 1 |

1 row in set (0.00 sec)

......

小编:

* FIRST_SEEN,LAST_SEEN:显示某给定语句第二遍插入 events_statements_summary_by_digest表和最终贰次立异该表的小时戳

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

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

| events_statements_summary_global_by_event_name |

| setup_objects |

·PHP定义的习性重视于编写翻译的天性:

COUNT_ALLOC: 193

qogir_env@localhost : performance_schema 06:19:20> SELECT EVENT_NAME,SUM_TIMER_WAIT FROM events_waits_summary_global_by_event_name

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

| memory_summary_by_host_by_event_name |

11rows inset (0.00sec)

LOCK_TYPE: SHARED_READ

LOW_COUNT_USED: 0

1row inset (0.00sec)

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

DIGEST_TEXT: SELECT @@`version_comment` LIMIT ?

......

·rwlock_instances:查看当前rwlock行的部分锁音讯(独占锁被哪些线程持有,共享锁被有个别个线程持有等)。

1 row in set (0.00 sec)

qogir_env@localhost: performance_schema 04:23:40> UPDATE setup_consumers SET ENABLED = 'YES'where name like '%wait%';

1row inset ( 0. 00sec)

LAST_SEEN: 2018-05-20 10:24:42

正文首先,大约介绍了怎么样是performance_schema?它能做哪些?

·ATTR_VALUE:连接属性值;

USER: root

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

PS:对于mutexes、conditions和rwlocks,在运作时纵然允许修改配置,且布局能够修改成功,可是有一些instruments不奏效,要求在运维时配置才会收效,假设你尝试着使用部分运用场景来追踪锁音讯,你也许在那些instance表中不能够查询到相应的信息。

......

SPINS: NULL

·注重于连接表中音讯的summary表在对那一个连接表执行truncate时会同时被隐式地执行truncate,performance_schema维护着依照accounts,hosts或users总括各样风云计算表。那一个表在名称包含:_summary_by_account,_summary_by_host,*_summary_by_user

events_statements_summary_by_digest表有投机额外的总结列:

| file_summary_by_event_name |

* _thread:客户端线程ID(仅适用于Windows)

| events_stages_summary_by_account_by_event_name |

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

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

从地点表中的言传身教记录音讯中,咱们能够看来,同样与等待事件类似,遵照用户、主机、用户 主机、线程等纬度实行分组与总计的列,分组列与等待事件类似,那里不再赘言,但对于内部存款和储蓄器总计事件,总括列与其它三种事件总计列差别(因为内部存款和储蓄器事件不计算时间支付,所以与任何三种事件类型相比较无1致总括列),如下:

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

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

events_statements_summary_by_user_by_event_name:依照各样用户名和事件名称进行总计的Statement事件

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

AVG_TIMER_WAIT: 514656000

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

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

那一个音讯使您能够掌握会话之间的元数据锁信赖关系。不仅能够看看会话正在等候哪个锁,还足以见见近年来持有该锁的会话ID。

* 尽管给定语句的总计消息行在events_statements_summary_by_digest表中曾经存在,则将该语句的总括消息实行更新,并更新LAST_SEEN列值为最近些天子

监视内部存款和储蓄器使用的表:

PS:MySQL server使用两种缓存技术通过缓存从文件中读取的音讯来制止文件I/O操作。当然,倘若内存不够时要么内部存款和储蓄器竞争比较大时只怕造成查询效能低下,那年你或然供给经过刷新缓存可能重启server来让其数额经过文件I/O再次来到而不是通过缓存重临。

关于events_statements_summary_by_digest表

| Tables_in_performance_schema (%setup%) |

通过对以下多少个表执行查询,能够兑现对应用程序的监察或DBA能够检验到关系互斥体的线程之间的瓶颈或死锁新闻(events_waits_current可以查看到当前正在等候互斥体的线程新闻,mutex_instances能够查阅到日前某些互斥体被哪些线程持有)。

举办该语句时有如下行为:

| events_transactions_history_long |

|4| _platform |x86_64 | 4 |

微尼斯人娱乐 2

| memory_summary_by_host_by_event_name |

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

| events_stages_summary_global_by_event_name |

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

1 row in set (0.00 sec)

COUNT _READ_WRITE: 6

FLAGS: NULL

·刑释元数据锁时,对应的锁新闻行被去除;

| events_stages_summary_by_user_by_event_name |

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

我们先来看望表中著录的总计新闻是怎么样样子的。

1 row in set (0.00 sec)

| events_statements_summary_by_program |

IP:PO奥迪Q7T列组合值可用以标识1个连连。该组合值在events_waits_xxx表的“OBJECT_NAME”列中使用,以标识这么些事件新闻是出自哪个套接字连接的:

| events_transactions_summary_by_thread_by_event_name |

|PERFORMANCE_SCHEMA | YES |Performance Schema

1 row in set (0.00 sec)

Query OK, 377 rows affected (0.00 sec)

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

AVG _TIMER_WAIT: 56688392

AVG _TIMER_WAIT: 0

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

3rows inset ( 0. 00sec)

罗小波·沃趣科技(science and technology)尖端数据库技术专家

今后,很欢跃的告诉我们,大家依据 MySQL 官方文书档案加上大家的注解,整理了一份能够系统学习 performance_schema 的资料分享给我们,为了方便大家阅读,我们整理为了2个两种,一共7篇小说。上边,请随行我们一块起来performance_schema系统的上学之旅吧。

| 10.10.20.15 |1| 1 |

admin@localhost : performance_schema 06:27:58> show tables like '%events_statements_summary%';

| events_waits_summary_by_instance |

admin@localhost : performance_schema 11:05:51> select * from session_connect_attrs;

MAX _TIMER_WAIT: 2427645000

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

table_handles表差别意利用TRUNCATE TABLE语句。

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

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

套接字事件计算了套接字的读写调用次数和出殡和埋葬接收字节计数音讯,socket事件instruments暗许关闭,在setup_consumers表中无具体的对应配置,包涵如下两张表:

* 假设二个线程没有打开采集功用,不过内部存款和储蓄器相关的instruments启用了,则该内部存款和储蓄器释放的操作会被监督到,总结数据会产生转移,那也是近期提到的为何反复在运维时修改memory instruments只怕导致总计数据为负数的原委

| events_transactions_summary_by_host_by_event_name |

AVG _TIMER_WAIT: 3496961251500

performance_schema把语句事件计算表也如约与等待事件计算表类似的规则进行分类总括,语句事件instruments默许全体开启,所以,语句事件计算表中暗中同意会记录全体的言辞事件总计音讯,言辞事件总括表包罗如下几张表:

EVENT_ID: 60

·COUNT_READ,SUM_TIMER_READ,MIN_TIMER_READ,AVG_TIMER_READ,MAX_TIMER_READ,SUM_NUMBER_OF_BYTES_READ:那么些列计算全部接受操作(socket的RECV、RECVFROM、RECVMS类型操作,即以server为参考的socket读取数据的操作)相关的次数、时间、接收字节数等音信

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

EVENT_NAME: wait/synch/mutex/innodb/log_sys_mutex

·COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_W路虎极光ITE:那几个列总括了装有发送操作(socket的SEND、SENDTO、SENDMSG类型操作,即以server为参考的socket写入数据的操作)相关的次数、时间、接收字节数等音讯

注意:这一个表只针对工作事件音信实行总计,即含有且仅蕴涵setup_instruments表中的transaction采集器,各样工作事件在种种表中的总括记录行数须求看怎样分组(例如:遵照用户分组总结的表中,有多少个活泼用户,表中就会有稍许条相同采集器的笔录),别的,总计计数器是还是不是见效还亟需看transaction采集器是还是不是启用。

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

rwlock_instances表分裂意利用TRUNCATE TABLE语句。

EVENT_NAME: statement/sql/select

| Tables_in_performance_schema |

cond_instances表列出了server执行condition instruments 时performance_schema所见的装有condition,condition表示在代码中一定事件时有发生时的同台非复信号机制,使得等待该条件的线程在该condition满意条件时得以还原工作。

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

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

4rows inset ( 0. 00sec)

root@localhost : performance _schema 12:34:43> select * from events_statements _summary_by_programG;

TIMER_WAIT: 65664

·TIMER_PREPARE:执行prepare语句作者消耗的光阴。

COUNT_FREE: 103

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

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

| events_waits_summary_by_thread_by_event_name |

数据库刚刚初阶化并运营时,并非全体instruments(事件采访项,在搜集项的安排表中每壹项都有3个开关字段,或为YES,或为NO)和consumers(与征集项类似,也有1个相应的轩然大波类型保存表配置项,为YES就象征对应的表保存质量数据,为NO就象征对应的表不保留品质数据)都启用了,所以私下认可不会征集全数的轩然大波,恐怕您需求检查测试的事件并未打开,须求开始展览设置,可以行使如下八个语句打开对应的instruments和consumers(行计数也许会因MySQL版本而异),例如,我们以布署监测等待事件数量为例举办验证:

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

......

| events_waits_summary_by_account_by_event_name |

performance_schema通过table_handles表记录表锁新闻,以对当下每一个打开的表所持有的表锁实行追踪记录。table_handles输出表锁instruments采集的始末。这么些音信彰显server中已打开了什么表,锁定方式是怎么着以及被哪些会话持有。

# events_stages_summary_by_thread_by_event_name表

8rows inset (0.00sec)

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

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

等候事件记录表,与话语事件类型的连锁记录表类似:

七.锁目的记录表

属性事件计算表在setup_consumers表中只受控于"global_instrumentation"配置项,也正是说一旦"global_instrumentation"配置项关闭,全数的计算表的总计条目都不履行总括(总括列值为0);

|wait/synch/mutex/mysys/THR_LOCK_malloc | 6419 |

总是属性记录在如下两张表中:

下1篇将为大家分享 《数据库对象事件计算与品质总括 | performance_schema全方位介绍》 ,谢谢你的翻阅,大家不见不散!回来天涯论坛,查看越来越多

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

OBJECT_NAME: test

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

| cond_instances |

MIN_TIMER_READ: 15213375

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

| events_statements_summary_by_account_by_event_name |

老是新闻表accounts中的user和host字段含义与mysql系统数据库中的MySQL grant表(user表)中的字段含义类似。

EVENT_NAME: stage/sql/After create

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

·COUNT_MISC,SUM_TIMER_MISC,MIN_TIMER_MISC,AVG_TIMER_MISC,MAX_TIMER_MISC:那些列计算了全部别的套接字操作,如socket的CONNECT、LISTEN,ACCEPT、CLOSE、SHUTDOWN类型操作。注意:这一个操作未有字节计数

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

通过从INFORMATION_SCHEMA.tables表查询有怎样performance_schema引擎的表:

·CURRENT_CONNECTIONS:某主机的当下连接数;

EVENT_NAME: transaction

本文由威尼斯人科技发布,转载请注明来源

关键词: 微尼斯人娱乐 威尼斯人棋牌