金沙国际娱城 > 金沙技术 > MySQL Performance-Schema(二) 理论篇,performanceschema

原标题:MySQL Performance-Schema(二) 理论篇,performanceschema

浏览次数:113 时间:2019-08-08

rwlock_instances表不容许行使TRUNCATE TABLE语句。

当server中的某线程试行了内部存款和储蓄器分配操作时,遵照如下法则举行检查实验与聚焦:

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

     MySQL Performance-Schema中总共富含伍十个表,主要分为几类:Setup表,Instance表,Wait 伊芙nt表,Stage Event表Statement Event表,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/THEscort_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表重要涵盖3个表,events_waits_current,events_waits_history和events_waits_history_long,通过thread_id event_id能够独一分明一条记下。current表记录了当下线程等待的风云,history表记录了各类线程近来静观其变的12个事件,而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。
SOURCE:该事件发生时的源码文件
TIMER_START, TIMER_END, TIMER_WAIT:事件伊始/截止和等候的年华,单位为皮秒(picoseconds)

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE视景况而定
对于联合对象(cond, mutex, rwlock),这一个3个值均为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表首要含有3个表,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
SOURCE:源码地方
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做MD5生出的叁十三个人字符串。假诺为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表记录了客户端的消息,首要包涵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_STA昂科威:事件计数
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中累计包罗54个表,首要分为几类:Setup表,Instance表,Wait Event表,Stage Ev...

(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

SUM_ERRORS: 0

* CURRENT_NUMBER_OF_BYTES_USED:增加N

(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的后天不足是,只好记录持有写锁的线程,对于读锁则无从。

AVG_TIMER_READ_NORMAL: 0

1 row in set (0.00 sec)

其它表
performance_timers: 系统支持的计算时间单位
threads: 监视服务端的当前运维的线程

OBJECT_TYPE: TABLE

COUNT_STAR: 0

Wait Event表
      Wait表首要涵盖3个表,events_waits_current,events_waits_history和events_waits_history_long,通过thread_id event_id能够独一明确一条记下。current表记录了当下线程等待的事件,history表记录了各种线程近期静观其变的十三个事件,而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。
SOURCE:该事件产生时的源码文件
TIMER_START, TIMER_END, TIMER_WAIT:事件始于/停止和等候的光阴,单位为皮秒(picoseconds)

* 已到位的等候事件将助长到events_waits_history和events_waits_history_long表中 ;

AVG_TIMER_WAIT:给定计时事件的平分等待时间

external lock则经过接口函数handler::external_lock调用存款和储蓄引擎层,
OPERATION列的值为:
read external
write external

* 使用libmysqlclient编写翻译:php连接的属性集结使用标准libmysqlclient属性,参见上文

1 row in set (0.00 sec)

(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等

| wait/io/socket/sql/client_connection |110668160 | 46 |53| |0| ACTIVE |

MIN _TIMER_WAIT: 0

events_statements_summary_by_account_by_event_name
events_statements_summary_by_user_by_event_name
events_statements_summary_by_host_by_event_name

* _client_version:客户端libmysql库版本

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

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

·USE奥迪Q5:某老是的客户端用户名。假如是贰当中间线程创造的三回九转,只怕是爱莫能助证实的用户创立的连天,则该字段为NULL;

# events_statements_summary_global_by_event_name表

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

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

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

Stage Event表 

LOCK_STATUS: GRANTED

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

THREAD_ID:线程ID
EVENT_ID:事件ID
END_EVENT_ID:刚甘休的平地风波ID
SOURCE:源码位置
TIMER_START, TIMER_END, TIMER_WAIT:事件初始/甘休和等候的光阴,单位为阿秒(picoseconds)
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT, STAGE, WAIT)

·users:依据用户名对每一种客户端连接进行计算。

OBJECT _INSTANCE_BEGIN: 32492032

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE视景况而定
对于联合对象(cond, mutex, rwlock),这些3个值均为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)

OPEN_COUNT:文件当前已展开句柄的计数。就算文件张开然后关门,则张开1次,但OPEN_COUNT列将加一然后减一,因为OPEN_COUNT列只计算当前已开荒的文本句柄数,已关闭的文本句柄会从中减去。要列出server中当前张开的兼具文件消息,能够运用where WHERE OPEN_COUNT> 0子句举行查看。

* 常常,truncate操作会重新恢复设置总计新闻的规格数据(即清空以前的数量),但不会修改当前server的内部存款和储蓄器分配等情景。也正是说,truncate内部存款和储蓄器总括表不会释放已分配内部存款和储蓄器

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做MD5生出的三18人字符串。即使为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。

admin@localhost : performance _schema 04:55:42> select * from metadata_locksG;

# events_waits_summary_by_instance表

(6).table_io_waits_summary_by_index_usage
与table_io_waits_summary_by_table类似,按索引维度总括

·CURRENT_CONNECTIONS:某主机的近年来连接数;

| events_statements_summary_by_account_by_event_name |

(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

·COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT:那个列计算全体socket读写操作的次数和时间新闻

1 row in set (0.00 sec)

(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总括。

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

admin@localhost : performance_schema 06:23:02> show tables like '%events_stages_summary%';

     MySQL Performance-Schema中总括满含52个表,重要分为几类:Setup表,Instance表,Wait 伊芙nt表,Stage Event表Statement Event表,Connection表和Summary表。上一篇文章已经重要讲了Setup表,那篇文章将会分别就各样档案的次序的表做详细的叙说。

从上边表中的记录新闻大家可以看出(与公事I/O事件总计类似,两张表也分头根据socket事件类型总计与服从socket instance举行计算)

COUNT_STAR: 0

(3)mutex_instances:互斥同步对象实例
表中记录了系统中利用互斥量对象的兼具记录,当中name为:wait/synch/mutex/*。比如张开文件的互斥量:wait/synch/mutex/mysys/THCR-V_LOCK_open。LOCKED_BY_THREAD_ID展现哪个线程正持有mutex,若未有线程持有,则为NULL。

从客户端发送到服务器的接连属性数据量存在限制:客户端在连年以前客户端有一个谈得来的定势长度限制(不可配置)、在客户端连接server时服务端也可能有三个定位长度限制、以及在客户端连接server时的连日属性值在存入performance_schema中时也会有二个可配置的长度限制。

1 row in set (0.00 sec)

(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

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

USER: NULL

(2)file_instances:文件实例
表中著录了系统中开采了文本的目的,满含ibdata文件,redo文件,binlog文件,用户的表文件等,举个例子redo日志文件:/u01/my3306/data/ib_logfile0。open_count展现当前文件展开的多少,若是重来未有张开过,不谋面世在表中。

admin@localhost : performance_schema 06:48:12> show tables like '%file_summary%';

* CURRENT_COUNT_USED:减少1

events_stages_summary_by_account_by_event_name
events_stages_summary_by_user_by_event_name
events_stages_summary_by_host_by_event_name

网编:

MIN_TIMER_WAIT: 72775000

       Stage表重要涵盖3个表,events_stages_current,events_stages_history和events_stages_history_long,通过thread_id event_id能够独一鲜明一条记下。表中记录了脚下线程所处的实践阶段,由于能够掌握各种阶段的推行时间,由此通过stage表能够博得SQL在各种阶段消耗的年华。

·STATEMENT_NAME:对于二进制协议的言辞事件,此列值为NULL。对于文本协议的说话事件,此列值是用户分配的外界语句名称。举个例子:PREPARE stmt FROM'SELECT 1';,语句名叫stmt。

EVENT_NAME: transaction

(2).stage-summary表
events_stages_summary_by_thread_by_event_name
events_stages_summary_global_by_event_name
与近些日子类似

·MySQL Connector/Net定义了之类属性:

COUNT_STAR: 0

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_STA奥迪Q5:事件计数
SUM_TIMER_WAIT:总的等待时间
MIN_TIMER_WAIT:最小等待时间
MAX_TIMER_WAIT:最大等待时间
AVG_TIMER_WAIT:平均等待时间

·EVENT_NAME:生成事件音信的instruments 名称。与setup_instruments表中的NAME值对应;

COUNT_STAR: 53

(9).socket-summaries表
socket_summary_by_instance
socket_summary_by_event_name

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

5rows inset ( 0. 00sec)

(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:第一个语句推行的时间
LAST_SEEN_TIMESTAMP:最终叁个话语实践的日子
气象:用于总计某一段时间内top SQL

performance_schema还总括后台线程和不可能表达用户的连年,对于那么些连接总括行信息,USE讴歌MDX和HOST列值为NULL。

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

连天属性记录在如下两张表中:

# events_stages_summary_by_account_by_event_name表

EVENT_NAME: wait/io/file/innodb/innodb_data_file

performance_schema把语句事件总结表也遵循与等待事件总计表类似的法则进行归类计算,语句事件instruments暗中认可全体拉开,所以,语句事件总括表中暗中同意会记录全体的言辞事件总括消息,话语事件计算表包罗如下几张表:

套接字事件总计了套接字的读写调用次数和出殡和埋葬接收字节计数音信,socket事件instruments暗中同意关闭,在setup_consumers表中无实际的照管配置,富含如下两张表:

AVG _TIMER_WAIT: 0

[Warning] Connection attributes oflength N were truncated

COUNT_ALLOC: 1

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

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

socket_instances表不容许选用TRUNCATE TABLE语句。

AVG _TIMER_WAIT: 0

| wait/synch/mutex/mysys/THR_LOCK_heap |32576832| NULL |

* 若是二个线程未有打开发集作用,然而内部存款和储蓄器相关的instruments启用了,则该内部存款和储蓄器释放的操作会被监控到,总括数据会发生变动,那也是目前提到的为什么频频在运营时修改memory instruments恐怕导致总括数据为负数的原因

......

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

| file_summary_by_event_name |

......

·ATTR_VALUE:连接属性值;

* 若是给定语句的计算信息行在events_statements_summary_by_digest表中一直不已存在行,且events_statements_summary_by_digest表空间范围已满的场地下,则该语句的计算消息将增长到DIGEST 列值为 NULL的超过常规规“catch-all”行,纵然该极其行荒诞不经则新插入一行,FI途胜ST_SEEN和LAST_SEEN列为当前光阴。要是该非常行已存在则更新该行的消息,LAST_SEEN为最近时间

这几个连接表都允许行使TRUNCATE TABLE语句:

罗小波·沃趣科学技术尖端数据库技艺专家

·COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_WPRADOITE:那些列计算了具有发送操作(socket的SEND、SENDTO、SENDMSG类型操作,即以server为参照的socket写入数据的操作)相关的次数、时间、接收字节数等新闻

SUM _TIMER_WAIT: 8649707000

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

SUM _TIMER_WAIT: 0

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

MAX _TIMER_WAIT: 0

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

| 导语

文本I/O事件总计表允许利用TRUNCATE TABLE语句。但只将总结列复位为零,并非删除行。

可经过如下语句查看语句事件总结表:

·放飞元数据锁时,对应的锁新闻行被删除;

MAX _TIMER_WAIT: 0

可透过如下语句查看:

......

socket_instances表列出了连接到MySQL server的生气勃勃接连的实时快速照相消息。对于每一种连接到mysql server中的TCP/IP或Unix套接字文件接二连三都会在此表中记录一行音讯。(套接字计算表socket_summary_by_event_name和socket_summary_by_instance中提供了一些外加音讯,比如像socket操作以及互连网传输和吸收接纳的字节数)。

......

·HOST:有些连接的主机名,倘诺是多少个之中线程创立的再而三,大概是无法注脚的用户成立的连天,则该字段为NULL;

| Tables_in_performance_schema (%events_waits_summary%) |

mutex_instances表字段含义如下:

MAX _TIMER_WAIT: 0

我们先来拜望表中记录的总计消息是哪些体统的。

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

·各种文件I/O总计表都有二个或多少个分组列,以申明如何总结这个事件音信。这个表中的事件名称来自setup_instruments表中的name字段:

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

# file_summary_by_event_name表

| events_waits_summary_by_host_by_event_name |

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

HOST: localhost

AVG _TIMER_READ _WITH_SHARED_LOCKS: 0

FIRST_SEEN: 2018-05-19 22:33:50

accounts表满含连接到MySQL server的每一种account的笔录。对于每一个帐户,没个user host唯一标志一行,每行单独总结该帐号的近来连接数和总连接数。server运转时,表的轻重缓急会自行调节。要显式设置表大小,能够在server运转在此以前设置系统变量performance_schema_accounts_size的值。该体系变量设置为0时,表示禁止使用accounts表的总结信息功用。

CURRENT _NUMBER_OF _BYTES_USED: 0

笔者们先来探视表中著录的计算新闻是怎么着体统的。

对于内部存款和储蓄器总括表中的低水位推断值,在memory_summary_global_by_event_name表中假诺内部存款和储蓄器全部权在线程之间传输,则该估计值可能为负数

* FEDERATED存款和储蓄引擎连接的program_name属性值被定义为mysqld、定义了_client_role属性,值为federated_storage

| memory_summary_by_host_by_event_name |

·当线程成功锁定(持有)互斥体时:

admin@localhost : performance_schema 06:28:48> show tables like '%prepare%';

| socket_summary_by_event_name |

HOST: NULL

| 3 |_client_name | libmysql |1|

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

·cond_instances:wait sync相关的condition对象实例;

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

rwlock_instances表列出了server推行rwlock instruments时performance_schema所见的具有rwlock(读写锁)实例。rwlock是在代码中应用的同台机制,用于强制在加以时间内线程能够遵循有些法规访问一些公共能源。能够感到rwlock爱慕着那些能源不被别的线程随便抢占。访谈形式可以是分享的(四个线程能够而且兼有分享读锁)、排他的(同期独有八个线程在给定时期足以具备排他写锁)或分享独占的(有个别线程持有排他锁按时,同期允许任何线程实行差别性读)。分享独占访谈被称为sxlock,该访谈格局在读写场景下能够增加并发性和可增加性。

* CURRENT_NUMBER_OF_BYTES_USED:减少N

table_lock_waits_summary_by_table表:

从地点表中的亲自过问记录消息中,大家能够看来,同样与等待事件类似,根据用户、主机、用户 主机、线程等纬度进行分组与总括的列,那几个列的意义与等待事件类似,这里不再赘言,但对于专门的工作计算事件,针对读写事务和只读事务还单身做了总结(xx_READ_WRITE和xx_READ_ONLY列,只读事务要求设置只读事务变量transaction_read_only=on才会进展总计)。

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

| events_statements_summary_by_user_by_event_name |

accounts表字段含义如下:

SUM _TIMER_WAIT: 0

(1)cond_instances表

AVG _TIMER_WAIT: 0

# table_lock_waits_summary_by_table表

| events_waits_summary_by_thread_by_event_name |

·HOST:某总是的客户端主机名。假若是贰个之中线程创建的接连,可能是无法注脚的用户创立的连接,则该字段为NULL;

内部存款和储蓄器事件总结表有如下几张表:

·IP:客户端IP地址。该值能够是IPv4或IPv6地址,也足以是空荡荡,表示那是一个Unix套接字文件一而再;

SUM _TIMER_WAIT: 0

·setup_instruments表列出了instruments名称,那些互斥体都饱含wait/synch/mutex/前缀;

SUM _TIMER_WAIT: 0

......

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

6.instance 统计表

AVG _TIMER_WAIT: 1235672000

从上面表中的记录新闻我们得以看出:

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

LOCK_DURATION: TRANSACTION

PS:内存计算表不含有计时音讯,因为内部存款和储蓄器事件不协理时间音讯搜罗。

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

SUM _NO_GOOD _INDEX_USED: 0

PS:socket计算表不会总结空闲事件生成的守候事件消息,空闲事件的等候消息是记录在等候事件总括表中举办总计的。

HOST: localhost

......

SUM _CREATED_TMP _DISK_TABLES: 3

品质总括表

* LOW_COUNT_USED和LOW_NUMBER_OF_BYTES_USED是非常的低的低水位猜想值。performance_schema输出的低水位值可以确认保障总计表中的内存分配次数和内部存款和储蓄器小于或等于当前server中真实的内部存款和储蓄器分配值

该表的分组列与table_io_waits_summary_by_table表相同

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

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

EVENT_NAME: transaction

AVG_TIMER_WAIT: 24366870

EVENT_NAME: statement/sql/select

OBJECT _INSTANCE_BEGIN: 2655351104

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

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

SUM _NUMBER_OF _BYTES_FREE: 3296

SOURCE: sql_parse.cc:6031

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

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

咱俩先来探访那些表中记录的总计消息是怎样体统的。

file_instances表字段含义如下:

* 以前缀memory/performance_schema命名的instruments能够收罗performance_schema自个儿消耗的内部缓存区大小等新闻。memory/performance_schema/* instruments暗中同意启用,无法在运维时或运维时关闭。performance_schema本人有关的内部存款和储蓄器计算音信只保存在memory_summary_global_by_event_name表中,不会保存在遵照帐户,主机,用户或线程分类聚合的内部存款和储蓄器总结表中

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

Query OK, 377 rows affected (0.00 sec)

OBJECT _INSTANCE_BEGIN: 2655350784

| Tables_in_performance_schema (%memory%summary%) |

咱俩先来看看表中著录的总括消息是何等样子的。

......

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

COUNT_FREE: 103

(1) session_account_connect_attrs表

events_statements_summary_by_host_by_event_name:遵照各样主机名和事件名称进行总括的Statement事件

* _pid:客户端进程ID

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

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

USER: root

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

MAX _TIMER_WAIT: 2427645000

·LOCKED_BY_THREAD_ID:当一个线程当前享有贰个排斥锁定期,LOCKED_BY_THREAD_ID列呈现全体线程的THREAD_ID,如果未有被别的线程持有,则该列值为NULL。

root@localhost : performance _schema 01:19:07> select * from events_transactions _summary_by _account_by _event_name where COUNT_STAR!=0 limit 1G

·prepare语句解除能源分配:对已检查测验的prepare语句实例试行COM_STMT_CLOSE或SQLCOM_DEALLOCATE_PREPARE命令,同有毛病间将去除prepare_statements_instances表中对应的行音信。为了幸免能源泄漏,请务必在prepare语句无需使用的时候实践此步骤释放能源。

1row inset ( 0. 00sec)

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

EVENT_NAME: statement/sql/select

| 4 |_client_version | 5.7.18 |3|

COUNT_STAR: 7

金沙技术 1

EVENT_NAME: statement/sql/select

该表允许选取TRUNCATE TABLE语句。只将总括列复位为零,却非剔除行。

关于内部存款和储蓄器事件的作为监督装置与注意事项

·SUM_xxx:其余的SUM_xxx开头的列与语句总计表中的音讯一样,语句总结表后续章节会详细介绍。

......

4 rows in set (0.00 sec)

PS:等待事件总括表允许行使TRUNCATE TABLE语句。

| EVENT_NAME |OBJECT_INSTANCE_BEGIN | THREAD_ID |SOCKET_ID | IP |PORT | STATE |

大家先来寻访这么些表中著录的总结音信是如何样子的(由于单行记录较长,这里只列出events_statements_summary_by_account_by_event_name 表中的示例数据,其他表的亲自去做数据省略掉一部分雷同字段)。

·假使值为NULL,则代表表I/O未有应用到目录

5rows inset ( 0. 00sec)

经过对以下五个表实践查询,能够兑现对应用程序的监督或DBA能够检查实验到关系互斥体的线程之间的瓶颈或死锁音信(events_waits_current能够查阅到当前正在等候互斥体的线程消息,mutex_instances可以查看到日前有个别互斥体被哪些线程持有)。

# memory_summary_by_account_by_event_name表

·EVENT_NAME:与公事相关联的instruments名称;

MAX _TIMER_READ_WRITE: 2427645000

* events_waits_current表中得以查看到当下正值等待互斥体的线程时间消息(比如:TIMETiguan_WAIT列表示曾经等候的时间) ;

MIN_TIMER_WAIT:给定计时事件的微乎其微等待时间

6 rows inset (0.00 sec)

1 row in set (0.00 sec)

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

| events_stages_summary_by_host_by_event_name |

透过对以下多个表实行查询,能够兑现对应用程序的监察或DBA能够检查实验到关系锁的线程之间的有些瓶颈或死锁消息:

SUM_SORT_SCAN: 6

02

THREAD_ID: 37

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

1 row in set (0.00 sec)

我们先来拜访表中记录的计算消息是哪些体统的。

performance_schema把阶段事件总计表也如约与等待事件总计表类似的法则实行分类聚合,阶段事件也可能有部分是暗中同意禁止使用的,一部分是打开的,阶段事件总结表包括如下几张表:

·hosts:依照host名称对种种客户端连接实行总括;

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

4rows inset ( 0. 00sec)

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

* COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_W福特ExplorerITE:这几个列计算了具有文件写操作,包含FPUTS,FPUTC,FP陆风X8INTF,VFPTucsonINTF,FWOdysseyITE和PWHavalITE系统调用,还隐含了那么些I/O操作的多寡字节数 ;

| memory_summary_by_account_by_event_name |

1 rows in set (0.00 sec)

本性事件总结表中的数码条款是无法去除的,只可以把相应总括字段清零;

COUNT_STAR: 2560

events_waits_summary_by_host_by_event_name表:按照列EVENT_NAME、HOST实行分组事件音讯

每一个连接消息表都有CU普拉多RENT_CONNECTIONS和TOTAL_CONNECTIONS列,用于追踪连接的当前连接数和总连接数。对于accounts表,各类连接在表中每行消息的无出其右标志为USE奥迪Q3 HOST,可是对于users表,独有一个user字段进行标记,而hosts表独有四个host字段用于标志。

检查评定内部存款和储蓄器职业负荷峰值、内部存款和储蓄器总体的办事负荷稳固性、或者的内部存款和储蓄器泄漏等是重大的。

·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读取数据的操作)相关的次数、时间、接收字节数等音讯

| 事务事件总括表

对此代码中的各个互斥体,performance_schema提供了以下消息:

| memory_summary_global_by_event_name |

·socket_summary_by_event_name:针对种种socket I/O instruments,这么些socket操作相关的操作次数、时间和发送接收字节信息由wait/io/socket/* instruments发生(这里的socket是指的日前活蹦乱跳的总是创造的socket实例)

AVG _TIMER_WAIT: 0

1row inset ( 0. 00sec)

COUNT_STAR: 0

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

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

·INTERNAL_LOCK:在SQL等第使用的表锁。有效值为:READ、READ WITH SHARED LOCKS、READ HIGH PHighlanderIOKoleosITY、READ NO INSERT、W中华VITE ALLOW W奔驰G级ITE、WTiguanITE CONCU途乐RENT INSERT、W大切诺基ITE LOW P君越IOPRADOITY、WCRUISERITE。有关那一个锁类型的详细音信,请参阅include/thr_lock.h源文件;

SUM_SORT_ROWS: 170

STATEMENT_NAME: stmt

* 读写作业日常比只读事务占用越来越多能源,因而事务总括表包罗了用来读写和只读事务的单身总括列

* COUNT_READ,SUM_TIMER_READ,MIN_TIMER_READ,AVG_TIMER_READ,MAX_TIMER_READ,SUM_NUMBER_OF_BYTES_READ:那么些列总括了具有文件读取操作,饱含FGETS,FGETC,FREAD和READ系统调用,还包蕴了那一个I/O操作的多寡字节数 ;

COUNT_STAR: 0

咱俩先来探问表中记录的总结音讯是怎么样体统的。

AVG _TIMER_WAIT: 0

OBJECT_NAME: test

| events_transactions_summary_by_account_by_event_name |

SUM _NUMBER_OF _BYTES_READ: 11567104

events_waits_summary_by_instance表:按照列EVENT_NAME、OBJECT_INSTANCE_BEGIN进行分组事件消息。假若叁个instruments(event_name)创制有三个实例,则种种实例都负有独一的OBJECT_INSTANCE_BEGIN值,由此各样实例会开始展览单独分组

instance表记录了如何项指标靶子被检查测量试验。那一个表中记录了平地风波名称(提供采摘作用的instruments名称)及其一些解释性的动静新闻(举个例子:file_instances表中的FILE_NAME文件名称和OPEN_COUNT文件张开次数),instance表首要有如下多少个:

政工聚合总结法则

友情提醒:下文中的总结表中山大学部分字段含义与上一篇 《事件总结 | performance_schema全方位介绍》 中关系的总结表字段含义一样,下文中不再赘言。其它,由于有的总括表中的笔录内容过长,限于篇幅会轻巧部分文件,如有供给请自行设置MySQL 5.7.11之上版本跟随本文进行同步操作查看。

events_waits_summary_by_user_by_event_name表:按照列EVENT_NAME、USEKuga进行分组事件消息

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

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

·PHP定义的性质重视于编译的习性:

THREAD_ID: 46

笔者们先来探视表中记录的总结音信是如何体统的。

从上边表中的身体力行记录消息中,大家得以见见,一样与等待事件类似,遵照用户、主机、用户 主机、线程等纬度实行分组与总计的列,分组列与等待事件类似,这里不再赘述,但对此内部存款和储蓄器计算事件,计算列与其余二种事件计算列不一样(因为内部存储器事件不总结时间支出,所以与别的两种事件类型相比较无一致总括列),如下:

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

DIGEST: 4fb483fe710f27d1d06f83573c5ce11c

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

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

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

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

| Tables_in_performance_schema (%table%summary%) |

| Tables_in_performance_schema (%events_transactions_summary%) |

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

AVG _TIMER_WAIT: 0

笔者们先来看看表中著录的计算新闻是何等样子的。

* 别的,遵照帐户,主机,用户或线程分类总计的内部存款和储蓄器总计表或memory_summary_global_by_event_name表,纵然在对其借助的accounts、hosts、users表实施truncate时,会隐式对那个内部存款和储蓄器总结表实施truncate语句

metadata_locks表字段含义如下:

# events_stages_summary_by_host_by_event_name表

2rows inset ( 0. 00sec)

MAX _TIMER_WAIT: 0

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

SUM _CREATED_TMP_TABLES: 10

| NULL |41| 45 |

* 事务事件的访谈不思量隔断等级,访谈格局或机关提交情势

(2)users表

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

4.套接字事件计算

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

MIN_TIMER_READ_NORMAL: 0

1 row in set (0.00 sec)

users表字段含义如下:

MIN _TIMER_WAIT: 0

1row inset ( 0. 00sec)

注意:这一个表只针对等候事件音信实行总结,即含有setup_instruments表中的wait/%伊始的采撷器 idle空闲采撷器,各类等待事件在各类表中的计算记录行数要求看什么分组(比方:依据用户分组总括的表中,有多少个活泼用户,表中就能够有稍许条同样搜罗器的笔录),其余,总计计数器是或不是见效还索要看setup_instruments表中相应的守候事件收集器是还是不是启用。

COUNT_STAR: 1

SUM _SELECT_RANGE_CHECK: 0

本文由金沙国际娱城发布于金沙技术,转载请注明出处:MySQL Performance-Schema(二) 理论篇,performanceschema

关键词: perfor 科技 58 AR CES

上一篇:若果委婉的戳到魅族用户的痛点?

下一篇:没有了