数据库对象事件与属性统计,performance_schema全方位介绍

qogir_env@localhost : performance_schema 04:23:52> SELECT * FROM events_waits_current limit 1G

OBJECT_TYPE: TABLE

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

     MySQL Performance-Schema中一共包罗51个表,重要分为几类:Setup表,Instance表,Wait Event表,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/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-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表记录了各样线程最近等待的13个事件,而history_long表则记录了方今有所线程发生的一千0个事件,这里的10和10000都以能够配备的。那八个表表结构同样,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:第贰个语句实施的时日
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_数据库对象事件与属性统计,performance_schema全方位介绍。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中一同包蕴五贰十一个表,首要分为几类:Setup表,Instance表,Wait Event表,Stage Ev...

| Engine |Support | Comment

AVG_TIMER_WAIT: 514656000

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

+-----------------------------------------------+

QueryOK, 0 rowsaffected(0.00sec)

这一个表列出了守候事件中的sync子类事件相关的目的、文件、连接。个中wait sync相关的靶子类型有三种:cond、mutex、rwlock。各种实例表皆有二个EVENT_NAME或NAME列,用于呈现与每行记录相关联的instruments名称。instruments名称大概具备多少个部分并转身一变档案的次序结构,详见"配置详解 | performance_schema全方位介绍"。

| Tables_in_performance_schema |

1 rows in set (0.00 sec)

| events_statements_summary_by_program |

1 row in set (0.00 sec)

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

·accounts:遵照user@host的款式来对各类客户端的连接进行总计;

| events_stages_summary_by_host_by_event_name |

·只要值为NULL,则象征表I/O未有应用到目录

| events_statements_summary_by_user_by_event_name |

咱俩先来看看表中记录的总结消息是何等体统的。

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

session_account_connect_attrs表不允许采用TRUNCATE TABLE语句。

+------------------------------------------------------+

·CURRENT_CONNECTIONS:某帐号的此时此刻连接数;

+--------------------+---------+--------------------+--------------+------+------------+

·libmysqlclient客户端库(在MySQL和MySQL Connector / C发行版中提供)提供以下属性:

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

·当行新闻中CUQashqaiRENT_CONNECTIONS 字段值大于0时,推行truncate语句不会去除那些行,TOTAL_CONNECTIONS字段值被重新载入参数为CU逍客RENT_CONNECTIONS字段值;

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

COUNT_STAR: 213055844

QueryOK, 3 rowsaffected(0.04sec)

COUNT_REPREPARE: 0

Rowsmatched: 323 Changed: 0 Warnings: 0

02

| setup_actors |

mutex_instances表列出了server实行mutex instruments时performance_schema所见的全部互斥量。互斥是在代码中选用的一种共同机制,以强制在加以时间内独有叁个线程能够访谈一些公共财富。能够感觉mutex珍爱着这么些集体能源不被随便抢占。

SOURCE: log0log.cc:1572

AVG_TIMER_WAIT: 24366870

+----------------------------------------+

admin@localhost : performance_schema 10:28:45> select * from rwlock_instances limit 1;

| events_statements_summary_global_by_event_name |

LOCK_STATUS: GRANTED

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

当客户端与server端构建连接时,performance_schema使用符合各种表的并世无双标记值来分明每一个连接表中怎样开始展览记录。假若缺点和失误对应标志值的行,则新扩充一行。然后,performance_schema会追加该行中的CULX570RENT_CONNECTIONS和TOTAL_CONNECTIONS列值。

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

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

21 rows inset (0.00 sec)

users表字段含义如下:

现行反革命,咱们曾经大约知道了performance_schema中的首要表的归类,但,怎样行使他们来为大家提供应和供给要的质量事件数量吧?上边,大家介绍怎样通过performance_schema下的配备表来配置与运用performance_schema。

SUM _TIMER_WAIT: 195829830101250

+------------------------------------------------------+

OBJECT_TYPE: TABLE

| TABLE_NAME |

* _platform:客户端机器平台(比如,x86_64)

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

+-------------------------------------------------+

TIMER_START: 1582395491787124480

# table_lock_waits_summary_by_table表

| events_transactions_summary_by_account_by_event_name |

COUNT_READ: 577

THREAD_ID: 4

| 3 |_client_name | libmysql |1|

| Tables_in_performance_schema (%transaction%) |

COUNT_STAR: 802

| events_statements_summary_by_host_by_event_name |

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

performance_schema库下的表可以遵从监视不一样的纬度举办了分组,举例:或依照差异数据库对象开始展览分组,或遵照分歧的平地风波类型进行分组,或在依据事件类型分组之后,再进一步依据帐号、主机、程序、线程、用户等,如下:

SOURCE: sql_parse.cc:6031

最终,简介了performance_schema中由什么表组成,那一个表差不离的功力是什么。

PS:MySQL server使用三种缓存才能通过缓存从文件中读取的信息来制止文件I/O操作。当然,假如内部存款和储蓄器相当不够时或然内部存款和储蓄器竞争十分大时也许引致查询效能低下,这年你恐怕要求通过刷新缓存也许重启server来让其数量经过文件I/O再次来到并不是透过缓存再次来到。

| events_transactions_history_long |

·setup_instruments表列出了instruments名称,那几个互斥体都包括wait/synch/mutex/前缀;

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

OBJECT_NAME: test

| wait/io/file/sql/FRM |452|

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

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

OBJECT _INSTANCE_BEGIN: 2658003840

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

·COUNT_MISC,SUM_TIMER_MISC,MIN_TIMER_MISC,AVG_TIMER_MISC,MAX_TIMER_MISC:这么些列总结了具备其余套接字操作,如socket的CONNECT、LISTEN,ACCEPT、CLOSE、SHUTDOWN类型操作。注意:那么些操作未有字节计数

| events_statements_history_long |

·prepare语句解除能源分配:对已检查实验的prepare语句实例试行COM_STMT_CLOSE或SQLCOM_DEALLOCATE_PREPARE命令,同期将去除prepare_statements_instances表中对应的行消息。为了防止能源泄漏,请务必在prepare语句无需采纳的时候施行此步骤释放财富。

......

+--------------------------------------+-----------------------+---------------------+

INDEX_NAME: NULL

......

| memory_summary_by_thread_by_event_name |

OBJECT _INSTANCE_BEGIN: 140568048055488

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

·COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE:试行prepare语句时的相干总计数据。

  1. 提供了一种在数据库运营时实时检查server的中间实市价况的措施。performance_schema 数据库中的表使用performance_schema存款和储蓄引擎。该数据库着重关切数据库运营进程中的质量相关的数额,与information_schema不同,information_schema首要关注server运维进程中的元数据信息
  2. performance_schema通过监视server的轩然大波来兑现监视server内部运市场价格况, “事件”便是server内部活动中所做的别的业务以及相应的光阴开销,利用那些新闻来剖断server中的相关能源消耗在了哪个地方?一般的话,事件能够是函数调用、操作系统的等待、SQL语句施行的阶段(如sql语句实行进程中的parsing 或 sorting阶段)或然全体SQL语句与SQL语句集合。事件的采访能够一本万利的提供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协助的保有平桃园事件监察和控制功用都可用,但差异平桃园用于计算事件时间支出的沙漏类型可能聚会场面不一模一样。

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

| file_summary_by_instance |

SUM_TIMER_READ: 305970952875

当今,大家知道了在 MySQL 5.7.17 版本中,performance_schema 下一共有87张表,那么,这87帐表都以贮存什么数据的吗?大家怎么采纳他们来查询大家想要查看的数额吧?先别发急,大家先来拜访那个表是哪些分类的。

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

| Tables_in_performance_schema (%wait%) |

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

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

SUM_TIMER_WAIT: 62379854922

OBJECT_TYPE: NULL

从表中的笔录内容能够看到,遵照库xiaoboluo下的表test举办分组,总计了表相关的等候事件调用次数,总计、最小、平均、最大延迟时间消息,利用这一个音信,大家得以大意明白InnoDB中表的拜访效用排名计算情状,一定水准上海电电影发行体制片厂响了对存款和储蓄引擎接口调用的频率。

11rows inset (0.00sec)

root@localhost : performance _schema 04:44:00> select * from socket_summary _by_event_nameG;

+-----------------------------------------+

·file_summary_by_event_name:依据各样事件名称实行总结的文本IO等待事件

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_unix_socket |110667520| 1 |34| |0| ACTIVE |

| wait/synch/mutex/sql/LOCK_global_system_variables |89|

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

| wait/synch/mutex/mysys/LOCK_alarm |145126935|

LOCK_TYPE: SHARED_READ

网编:

rwlock_instances表列出了server试行rwlock instruments时performance_schema所见的有所rwlock(读写锁)实例。rwlock是在代码中利用的一道机制,用于强制在给定期期内线程能够遵照有些法则访谈一些公共能源。能够感到rwlock珍重着这个财富不被别的线程随便抢占。访问方式能够是分享的(多少个线程能够同期全部分享读锁)、排他的(相同的时候独有贰个线程在给定时期足以享有排他写锁)或共享独占的(某些线程持有排他锁定期,同一时候同意任何线程实行分歧性读)。分享独占访谈被称为sxlock,该访问方式在读写场景下能够加强并发性和可扩充性。

+----------------------------------------+

* COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_W凯雷德ITE:那些列计算了具备文件写操作,包蕴FPUTS,FPUTC,FP途观INTF,VFP劲客INTF,FWCR-VITE和PWGL450ITE系统调用,还带有了那么些I/O操作的数目字节数 ;

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

SUM_ROWS_SENT: 0

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

因而对以下多个表实施查询,能够落成对应用程序的督察或DBA能够检查评定到事关互斥体的线程之间的瓶颈或死锁消息(events_waits_current能够查看到目前正值守候互斥体的线程音信,mutex_instances能够查阅到前段时间有些互斥体被哪些线程持有)。

8rows inset (0.00sec)

| file_summary_by_event_name |

+----------------------------------------------------+

·NAME:与rwlock关联的instruments名称;

SPINS: NULL

STATEMENT_ID: 1

| file_summary_by_event_name |

文件I/O事件总括表只记录等待事件中的IO事件(不带有table和socket子种类),文件I/O事件instruments私下认可开启,在setup_consumers表中无具体的附和配置。它包括如下两张表:

| Tables_in_performance_schema (%memory%) |

两张表中记录的内容很周边:

职业事件记录表,记录事务相关的事件的表,与话语事件类型的连锁记录表类似:

1row inset ( 0. 00sec)

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

| HOST |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |

MySQL的performance schema 用于监察和控制MySQL server在叁个非常低等别的运营进度中的财富消耗、能源等待等情事,它具有以下特点:

AVG _TIMER_READ _WITH_SHARED_LOCKS: 0

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

3rows inset ( 0. 00sec)

今昔,是还是不是认为上面的介绍内容太过平淡呢?假诺你这么想,那就对了,我那时候读书的时候也是如此想的。但昨日,对于什么是performance_schema这一个标题上,比起更早此前更清楚了吗?假若你还未有准备要放任读书本文的话,那么,请随行大家初始步向到"边走边唱"环节呢!

·各种文件I/O总计表都有一个或几个分组列,以声明怎么着总计那个事件信息。这一个表中的风浪名称来自setup_instruments表中的name字段:

+---------------------------------------------------+------------+

table_lock_waits_summary_by_table表:

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

·socket_summary_by_instance:针对各类socket实例的有所 socket I/O操作,那个socket操作相关的操作次数、时间和出殡和埋葬接收字节消息由wait/io/socket/* instruments发生。但当连接中断时,在该表中对应socket连接的消息将要被删去(这里的socket是指的脚下活跃的接连创制的socket实例)

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

file_instances表不容许使用TRUNCATE TABLE语句。

WHERE TABLE_SCHEMA ='performance_schema'andengine='performance_schema';

MAX_TIMER_WAIT: 9498247500

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

(3)hosts表

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

OBJECT _INSTANCE_BEGIN: 2658004160

2.2. 启用performance_schema

admin@localhost : performance _schema 10:50:38> select * from prepared_statements_instancesG;

OPERATION: lock

01

# 这个结果表明,TH卡宴_LOCK_malloc互斥事件是最热的。注:TH昂Cora_LOCK_malloc互斥事件仅在DEBUG版本中存在,GA版本不设有

·已呼吁但未给予的锁(显示怎会话正在等待哪些元数据锁);

+--------------------+---------+--------------------+--------------+------+------------+

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

TIMER_END: 1582395491787190144

MIN_TIMER_READ: 0

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

......

|Transactions | XA |Savepoints |

* 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操作未有字节计数消息。

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

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

| Tables_in_performance_schema (%file%) |

作者们先来探视表中记录的总结消息是怎么着体统的。

|wait/synch/mutex/sql/LOCK_plugin | 337 |

* COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT:这么些列总计全体I/O操作数量和操作时间 ;

+---------------------------------------+

OBJECT_SCHEMA: xiaoboluo

......

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

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

+-------+-------------+---------------------+-------------------+

2.3. performance_schema表的归类

performance_schema还总计后台线程和不恐怕声明用户的延续,对于这个连接总计行消息,USE兰德揽胜极光和HOST列值为NULL。

|4| 349 |wait/synch/mutex/innodb/fil_system_mutex | 65664 |

MIN_TIMER_EXECUTE: 0

+--------------------+---------+--------------------+--------------+------+------------+

·ATTR_NAME:连接属性名称;

| events_waits_history |

·OBJECT_SCHEMA:该锁来自于哪个库品级的目的;

+-----------------------------------------------+

2. 连连属性总结表

| setup_consumers |

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

| events_waits_summary_by_user_by_event_name |

·events_waits_current:查看线程正在等候什么rwlock;

_current表中每一种线程只保留一条记下,且若是线程完结工作,该表中不会再记录该线程的风浪音讯,_history表中著录每一种线程已经施行到位的平地风波消息,但种种线程的只事件音讯只记录10条,再多就能被遮蔽掉,*_history_long表中著录全数线程的平地风波消息,但总记录数据是一千0行,超越会被覆盖掉,未来大家查看一下历史表events_waits_history 中记录了怎么:

1 row in set (0.00 sec)

| events_waits_current |

4rows inset ( 0. 00sec)

| cond_instances |

EVENT_NAME: wait/io/file/innodb/innodb_data_file

+------------------------------------------------------+

2rows inset ( 0. 00sec)

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

当客户端断开连接时,performance_schema将压缩对应连接的行中的CURRENT_CONNECTIONS列,保留TOTAL_CONNECTIONS列值。

instance表记录了何等类型的对象会被检查实验。那么些指标在被server使用时,在该表旅长会发生一条事件记录,举个例子,file_instances表列出了文本I/O操作及其关系文件名:

| localhost |1| 1 |

+------------------------------------------------------+--------------------------------------+------------+

| NULL |41| 45 |

| events_stages_history |

OWNER_THREAD_ID: 48

+------------------------------------------------------+

·TOTAL_CONNECTIONS:某用户的总连接数。

+------------------------------------------------+

SUM _TIMER_READ _WITH_SHARED_LOCKS: 0

| EVENT_NAME |COUNT_STAR |

+------------------------------------------------+

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

(2)file_instances表

| events_waits_summary_by_host_by_event_name |

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

+----------------------------------------+----------------+

·users:依据用户名对每一个客户端连接举办总括。

+----------------------------------------+----------------+

· 对于由此Unix domain套接字(client_connection)的客户端连接,端口为0,IP为空白;

+------------------------------------------------------+

+-------+---------------------+-------------------+

| events_stages_history_long |

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

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

| NAME |OBJECT_INSTANCE_BEGIN |

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

session_account_connect_attrs表字段含义:

| events_stages_summary_by_thread_by_event_name |

rwlock_instances表字段含义如下:

+-----------------------------------------+

MIN_TIMER_WAIT: 1905016

+----------------------------------------+

* _pid:客户端进度ID

| events_statements_summary_by_digest |

·TOTAL_CONNECTIONS:某帐号的总连接数(新增一个连连累计二个,不会像当前连接数那样连接断开会降低)。

+------------------------------------------------+

+-------+-------------+---------------------+-------------------+

| memory_summary_by_user_by_event_name |

(2)users表

# 该事件消息表示线程ID为4的线程正在等待innodb存款和储蓄引擎的log_sys_mutex锁,那是innodb存款和储蓄引擎的三个互斥锁,等待时间为65664飞秒(*_ID列表示事件源于哪个线程、事件编号是稍微;EVENT_NAME表示检查测验到的具体的剧情;SOURCE表示那么些检查测试代码在哪些源文件中以及行号;放大计时器字段TIME巴博斯 SLS级_START、TIMER_END、TIMER_WAIT分别代表该事件的开首时间、结束时间、以及总的耗时,如若该事件正在运营而尚未终结,那么TIME劲客_END和TIMER_WAIT的值展现为NULL。注:沙漏总括的值是近乎值,并不是一丝一毫标准)

......

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

·LOCK_STATUS:元数据锁子系统的锁状态。有效值为:PENDING、GRANTED、VICTIM、TIMEOUT、KILLED、PRE_ACQUIRE_NOTIFY、POST_RELEASE_NOTIFY。performance_schema依据差异的阶段改动锁状态为这个值;

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

EVENT_NAME: wait/io/socket/sql/client_connection

+----------------------------------------------------+

该表包括关于内部和表面锁的新闻:

| 0 |

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

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

·COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT:这几个列计算全体socket读写操作的次数和时间音讯

| memory_summary_by_account_by_event_name |

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

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

·COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_W奥迪Q3ITE:这么些列总括了具备发送操作(socket的SEND、SENDTO、SENDMSG类型操作,即以server为参考的socket写入数据的操作)相关的次数、时间、接收字节数等消息

| variables_by_thread |

·SOCKET_ID:分配给套接字的里边文件句柄;

| events_transactions_summary_global_by_event_name |

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

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

file_instances表列出试行文书I/O instruments时performance_schema所见的有着文件。 若是磁盘上的文本未有张开,则不会在file_instances中著录。当文件从磁盘中除去时,它也会从file_instances表中删除相应的笔录。

TIMER_WAIT: 65664

该表允许使用TRUNCATE TABLE语句。只将计算列重新设置为零,实际不是删除行。对该表试行truncate还有大概会隐式truncate table_io_waits_summary_by_index_usage表

FLAGS: NULL

应用程序能够运用一些键/值对转移一些总是属性,在对mysql server创造连接时传递给server。对于C API,使用mysql_options()和mysql_options4()函数定义属性集。其余MySQL连接器可以利用部分自定义连接属性方法。

| events_waits_summary_by_thread_by_event_name |

·TIMER_PREPARE:实行prepare语句小编消耗的年月。

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

metadata_locks表是只读的,不可能立异。暗中同意保留行数会自行调治,假设要配备该表大小,能够在server运维在此以前安装系统变量performance_schema_max_metadata_locks的值。

EVENT_NAME: wait/synch/mutex/innodb/log_sys_mutex

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

如今,很欢悦的报告大家,大家依据 MySQL 官方文书档案加上我们的证实,整理了一份能够系统学习 performance_schema 的素材分享给大家,为了便于大家阅读,大家整理为了二个多种,一共7篇作品。下边,请跟随大家共同起初performance_schema系统的求学之旅吧。

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

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

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

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

metadata_locks表不允许选用TRUNCATE TABLE语句。

1row inset (0.00sec)

# file_summary_by_instance表

2、performance_schema使用高效入门

AVG_TIMER_READ_NORMAL: 0

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

· 当行音信中CUPAJERORENT_CONNECTIONS 字段值为0时,施行truncate语句会删除这么些行;

| wait/synch/mutex/sql/THD::LOCK_thd_data |115|

该表的分组列与table_io_waits_summary_by_table表相同

|目 录1、什么是performance_schema

1row inset ( 0. 00sec)

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

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

summary表提供全数事件的集中国国投息。该组中的表以不一致的不二等秘书籍集中事件数量(如:按用户,按主机,按线程等等)。比方:要查看哪些instruments占用最多的时刻,能够透过对events_waits_summary_global_by_event_name表的COUNT_STAR或SUM_TIMER_WAIT列举行询问(这两列是对事件的记录数实施COUNT(*)、事件记录的TIMEPorsche718_WAIT列执行SUM(TIMER_WAIT)总括而来),如下:

·OBJECT_SCHEMA:该锁来自于哪个库等第的对象;

| users |

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

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

+-------+---------------------+-------------------+

5rows inset (0.00sec)

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+

+------------------------------------+--------------------------------------+------------+

| memory_summary_global_by_event_name |

# file_summary_by_event_name表

|PERFORMANCE_SCHEMA | YES |Performance Schema

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

9rows inset (0.00sec)

* mutex_instances表中的THREAD_ID列呈现该互斥映未来被哪些线程持有。

下卷将为大家分享"performance_schema之二(配置表详解)" ,多谢你的开卷,我们不见不散!回去和讯,查看越来越多

+-----------------------------------------------+

| events_statements_summary_by_thread_by_event_name |

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

|performance_schema | ON |

4.套接字事件计算

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

*************************** 2. row ***************************

OBJECT_SCHEMA: NULL

| table_lock_waits_summary_by_table |# 遵照各类表展开总结的表锁等待事件

| file_instances |

| file_summary_by_instance |

+---------------------------------------+

|4| _pid |3766| 2 |

|13| 2261 |wait/synch/mutex/innodb/flush_list_mutex | 122208 |

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

  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.7.x版本暗中认可安装

COUNT_EXECUTE: 0

Database changed

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

|1、**什么是performance_schema**

|admin | localhost |1| 1 |

|EVENT_NAME | SUM_TIMER_WAIT |

下篇将为大家分享 《复制状态与变量记录表 | performance_schema全方位介绍》 ,多谢您的翻阅,大家不见不散!回来今日头条,查看越多

| events_statements_history |

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

| setup_timers |

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

| events_transactions_current |

1row inset ( 0. 00sec)

| events_stages_None ,current |

* _runtime_vendor:Java运营条件(JRE)供应商名称

+--------------------+-------+

admin@localhost : performance_schema 05:47:55> select * from table_handles;

1 row in set (0.02 sec)

对此代码中的每种互斥体,performance_schema提供了以下音讯:

+------------------------------------------------------+

1.数码库表品级对象等待事件计算

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

·各样文件I/O事件计算表有如下总计字段:

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

+-------------------------------------------------+

| setup_objects |

·file_instances:文件对象实例;

| events_transactions_summary_by_host_by_event_name |

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

| memory_summary_by_host_by_event_name |

·ORDINAL_POSITION:将接连属性增添到一连属性集的依次。

2.3. performance_schema表的分类

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

END_EVENT_ID: 60

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

+-----------+----------+------------------------------------------+------------+

SUM_TIMER_WAIT: 412754363625

[mysqld]

·当三个线程尝试得到已经被有个别线程持有的互斥体时,在events_waits_current表中会突显尝试获得那些互斥体的线程相关等待事件消息,展现它正在等候的mutex 体系(在EVENT_NAME列中得以见到),并体现正在守候的mutex instance(在OBJECT_INSTANCE_BEGIN列中能够看来);

mysqld运维现在,通过如下语句查看performance_schema是不是启用生效(值为ON代表performance_schema已开首化成功且能够使用了。假若值为OFF表示在启用performance_schema时发生一些错误。能够查阅错误日志举办排查):

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

20rows inset (0.00sec)

·USEGL450:有个别连接的用户名,假诺是三个里边线程创制的接连,只怕是心有余而力不足印证的用户创设的连接,则该字段为NULL;

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

MIN_TIMER_READ: 15213375

本篇内容到此地就类似尾声了,相信广大人都觉着,大家超越57%时候并不会一贯运用performance_schema来询问质量数据,而是使用sys schema下的视图替代,为啥不直接攻读sys schema呢?那您精晓sys schema中的数据是从何地吐出来的吧?performance_schema 中的数据实际上根本是从performance_schema、information_schema中获取,所以要想玩转sys schema,周全摸底performance_schema不可缺少。别的,对于sys schema、informatiion_schema以至是mysql schema,我们一连也会生产区别的一体系作品分享给我们。

依据数据库对象名称(库等级对象和表品级对象,如:库名和表名)举行总括的等候事件。依照OBJECT_TYPE、OBJECT_SCHEMA、OBJECT_NAME列举行分组,依照COUNT_STAR、xxx_TIMER_WAIT字段举行总结。富含一张objects_summary_global_by_type表。

品级事件记录表,记录语句施行的品级事件的表,与话语事件类型的相干记录表类似:

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

1row inset (0.00sec)

file_instances表字段含义如下:

言语事件记录表,那么些表记录了言语事件音讯,当前讲话事件表events_statements_current、历史语句事件表events_statements_history和长语句历史事件表events_statements_history_long、以及汇集后的摘要表summary,个中,summary表还可以依照帐号(account),主机(host),程序(program),线程(thread),用户(user)和全局(global)再展开私分)

6 rows inset (0.00 sec)

ORDER BY COUNT_STAR DESC LIMIT 10;

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

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

·SOURCE:源文件的名称,在那之中蕴藏生成事件音讯的检查测量检验代码行号;

+------------------------------------------------------+

OBJECT _INSTANCE_BEGIN: 139882156936704

| events_statements_current |

内需有所互斥体的职业负荷能够被以为是处于二个根本地点的做事,多少个查询大概供给以系列化的措施(三回一个串行)实施这些第一部分,但那恐怕是三个机密的品质瓶颈。

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

同意施行TRUNCATE TABLE语句,可是TRUNCATE TABLE只是重新恢复设置prepared_statements_instances表的总括音讯列,但是不会去除该表中的记录,该表中的记录会在prepare对象被灭绝释放的时候自动删除。

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

大家先来拜会表中著录的总计新闻是何许样子的。

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

·READ_LOCKED_BY_COUNT:当八个线程在分享(读)情势下持有贰个rwlock时,READ_LOCKED_BY_COUNT列值增添1,所以该列只是一个计数器,不可能平昔用来查找是哪位线程持有该rwlock,但它能够用来查阅是不是存在四个有关rwlock的读争用以及查看当前有微微个读格局线程处于活跃状态。

| NO |NO | NO |

OWNER _EVENT_ID: 49

3rows inset (0.01sec)

session_account_connect_attrs表仅包涵当前连年及其相关联的别的总是的连日属性。要翻看全体会话的连年属性,请查看session_connect_attrs表。

|wait/io/file/myisam/dfile | 322401645 |

+----------------------------------+-----------------------+

从上文中大家早已知道,performance_schema在5.7.x会同以上版本中暗许启用(5.6.x及其以下版本暗许关闭),假如要显式启用或关闭时,大家需求利用参数performance_schema=ON|OFF设置,并在my.cnf中开始展览配备:

TIMER_PREPARE: 896167000

未来,你能够在performance_schema下使用show tables语句可能经过询问 INFORMATION_SCHEMA.TABLES表中performance_schema引擎相关的元数据来精晓在performance_schema下存在着什么样表:

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

相关文章