事件记录

新葡萄京娱乐网站 1

原标题:事件记录 | performance_schema全方位介绍(3)

[MySQL Reference Manual] 23 Performance Schema结构,manualschema

新葡萄京娱乐网站 1

23 MySQL Performance Schema

23 MySQL Performance Schema.. 1

2三.1 品质框架飞快运营… 三

贰三.贰 质量框架配置… 5

二三.贰.一 质量框架编写翻译时配置… 伍

2三.二.二 品质框架运维配置… 六

二3.2.叁 运行时质量框架配置… 八

2三.②.三.一 质量架构事件按时… 八

23.二.3.二 质量框架事件过滤… 九

二三.二.三.叁 事件预过滤… 十

贰3.二.3.4命著名记者录点恐怕消费者的过滤… 12

二3.贰.3.伍 识别哪些已经被记录… 1二

23.3 品质框架查询… 一3

二三.四 质量框架记录点命名约定… 一三

二三.5 品质框架和境况监察和控制… 15

二3.陆 质量框架和成员原子性事件… 17

贰三.七 品质框架statement digests17

二3.8 品质框架常用表个性… 1九

2叁.玖 品质框架表描述… 1九

二3.9.1 品质框架表索引… 1九

二三.玖.二 品质框架setup表…
1九

23.9.2.1 setup_actors表… 19

23.9.2.2 setup_consumers表… 20

23.9.2.3 setup_instruments表… 20

23.9.2.4 setup_objects表… 21

23.9.2.5 setup_timers表… 22

二叁.九.三 质量框架实例表… 2贰

23.9.3.1 cond_instances表… 22

23.9.3.2 file_instances表… 22

23.9.3.3 mutex_instances表… 22

23.9.3.4 Rwlock_instances表… 23

23.9.3.5 socket_instance表… 23

2三.九.四 质量框架事件等待表… 25

23.9.4.1 events_waits_current表… 26

23.9.4.2 Events_waits_history表… 28

23.9.4.3 events_waits_history_long 表… 28

二3.玖.伍 品质框架Stage事件表…
2八

23.9.5.1 events_stages_current表… 30

23.9.5.2 events_stage_history表… 30

23.9.5.3 events_stage_history_long表… 31

二三.玖.陆 品质框架语句事件表… 3一

2三.玖.7 性能框架事务表… 32

二三.九.八 品质框架连接表… 35

贰三.9.玖 质量框架连接属性表… 3伍

二3.9.拾 质量框架用户变量表… 3伍

二3.九.11 质量框架复制表… 3六

23.9.11.1
replication_connection_configure表…
38

23.9.11.2
replication_connection_status38

23.9.11.3 replication_applier_configure.
39

23.9.11.4
replication_applier_status39

23.9.11.5
replication_applier_status_by_coordinator39

23.9.11.6
replication_applier_statys_by_worker40

23.9.11.7
replication_group_members40

23.9.11.8
replication_group_member_status40

二三.九.1二 品质框架锁相关表… 四1

23.9.12.1 metadata_locks41

23.9.12.2 table_handles42

二3.玖.壹三 品质框架类别变量表… 42

②三.⑨.1四 质量框架种类状态变量表… 四叁

2叁.九.一5 品质框架总结表… 四三

二3.九.1陆 品质框架其余表… 4四

2三.拾 质量框架选项和变量… 肆伍

二三.1一 品质框架命令选项… 四5

二3.1二 质量框架连串变量… 4伍

2叁.一3 质量框架状态变量… 四五

贰3.14 品质框架内部存款和储蓄器分配模型… 四伍

二三.一伍 品质框架和…
4六

二三.16 使用质量框架会诊… 47

二三.壹7 迁移到品质框架连串和状态变量表… 4七

 

MySQL Performance Schema用来监督MySQL
Server的运作运转在底层。质量框架有这么些特点:

·         品质框架提供了壹种格局检查当中的劳务运作。通过PE汉兰达FOTucsonMANCE_SCHEMA存储引擎和performance_schema达成。质量框架首要关切于数据品质。和INFO哈弗MANCE_SCHEMA不同,INFORMACE_SCHEMA首要检查元数据。

·         质量框架监察和控制服务事件,事件是服务必要花时间的其余事物,并且已经被记录如此时间新闻方可被采撷。日常叁个事件能够是贰个函数调用,二个操作系统等待,SQL语句实践的级差例如解析或然排序,或然全部讲话可能1组语句。时间搜集提供。时间收集提供了协同调用文件和表IO,表锁等信息。

·         品质框架事件的风云和binlog的轩然大波,事件调节的轩然大波分歧。

·         质量框架事件被钦点到有些MySQL服务。品质框架表别人小编是地面服务,他们的修改不会被写入到binary
log,也不会被复制。

·         当前风浪,历史事件和事件下结论是可用的,那么就可以规定记录被运维了略微次,用了略微时间。事件音讯能够查阅钦赐线程的运动如故钦赐对象的活动,比方文件和信号量。

·         PERFORMANCE_SCHEMA存款和储蓄引擎使用代码中的记录点来采访音信。

·         收罗的音讯被保存在performance_schema数据库中。能够用select查询。

·         品质框架配置能够动态的被改造,通过改变performance_schema数据库配置数据搜集。

·         Performance_schema上的表是视图恐怕权且表,不会保留到磁盘中。

·         MySQL匡助具备平台的监察。

·         通过在源代码中插手记录点落成数量收罗。未有一定线程使用相关的性子框架。

导语

贰三.一 质量框架连忙运维

对此质量框架要启用,须求求在MySQL编写翻译的时候配置好。能够透过mysqld的扶持验证。假如质量框架可用输出就会带—performance_schema参数。

假诺那些参数未有出现,那么代码在编写翻译时就不协理质量框架。

假使品质框架可用,暗中认可是可用的。能够经过安插文件配置:

[mysqld]
performance_schema=ON

当服务运营,发掘performance_schema就会准备开首化品质框架,能够查阅performance_schema变量检查早先化是或不是中标。

mysql> SHOW VARIABLES LIKE ‘performance_schema’;

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

| Variable_name      | Value |

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

| performance_schema | ON    |

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

以此值表示,质量框架已经可用,假设为off表示爆发错误,检查错误日志。

质量框架完成和存储引擎类似。若是引擎可用可以在show
engine查看是或不是扶助PE奥迪Q伍FOLacrosseMANCE_SCHEMA存款和储蓄引擎。

Performance_schema中的数据库能够被剪切为几块,当前几日子,历史事件,总计,对象实例和安装音信。

本来,其实并不是装有的记录点和搜罗器都以可用。所以质量框架不会征集全体的数据。可以由此以下语句张开全部的积攒点和搜罗器:

mysql> UPDATE setup_instruments SET ENABLED = ‘YES’, TIMED =
‘YES’;

Query OK, 560 rows affected (0.04 sec)

mysql> UPDATE setup_consumers SET ENABLED = ‘YES’;

Query OK, 10 rows affected (0.00 sec)

此时此刻事变表,能够经过events_waits_current查看当前服务在做怎么着。各样线程都有1行。

历史表,表结交涉脚下事件一样,event_waits_history和event_waits_history_long表包括了各样线程方今13个event和各类线程近日10000个events。

1个新的轩然大波被投入,老的轩然大波就会去除。

总结表提供了全数事件的聚焦的音讯。那么些表经过分组壹不等方式测算事件数量。为了查看那些记录点呗实施的次数最多照旧等待事件最长,通过对表上的count_star或者sum_timer_wait列进行排序:

mysql> SELECT EVENT_NAME, COUNT_STAR

    -> FROM events_waits_summary_global_by_event_name

    -> ORDER BY COUNT_STAR DESC LIMIT 10;

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

| EVENT_NAME                                        | COUNT_STAR |

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

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

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

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

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

| wait/synch/mutex/mysys/LOCK_alarm                 |        147 |

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

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

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

| wait/synch/mutex/mysys/THR_LOCK::mutex            |         89 |

| wait/synch/mutex/sql/LOCK_open                    |         88 |

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

 

mysql> SELECT EVENT_NAME, SUM_TIMER_WAIT

    -> FROM events_waits_summary_global_by_event_name

    -> ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

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

| EVENT_NAME                             | SUM_TIMER_WAIT |

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

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

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

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

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

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

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

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

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

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

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

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

如,上面结果THTucson_LOCK非时限信号量是走俏,二个语句分别代表实践的光热和等待事件长度。

实例表,记录了对象类型被记录了。当服务应用了3个笔录对象,那么会爆发2个事变。这么些表提供了轩然大波名,解释性的注脚恐怕状态。举个例子file_instances表,记录了文本io操作和他们相应的文书。

mysql> SELECT * FROM file_instances\G

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

 FILE_NAME: /opt/mysql-log/60500/binlog.000007

EVENT_NAME: wait/io/file/sql/binlog

OPEN_COUNT: 0

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

 FILE_NAME: /opt/mysql/60500/data/mysql/tables_priv.MYI

EVENT_NAME: wait/io/file/myisam/kfile

OPEN_COUNT: 1

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

 FILE_NAME: /opt/mysql/60500/data/mysql/columns_priv.MYI

EVENT_NAME: wait/io/file/myisam/kfile

OPEN_COUNT: 1

...

Setup表用来铺排和监察和控制特点的,比方setup_timers表:

mysql> SELECT * FROM setup_timers;

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

| NAME        | TIMER_NAME  |

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

| idle        | MICROSECOND |

| wait        | CYCLE       |

| stage       | NANOSECOND  |

| statement   | NANOSECOND  |

| transaction | NANOSECOND  |

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

Setup_instruments列了什么能够被记录的风浪。然后经过改换那几个表开调控是还是不是运转那些记录。

mysql> UPDATE setup_instruments SET ENABLED = 'NO'

    -> WHERE NAME = 'wait/synch/mutex/sql/LOCK_mysql_create_db';

质量框架使用,搜聚来的风浪来更新到performance_schema数据库,数据库作为事件音讯的主顾。Setup_consumers表列出了可用的买主。

支配是或不是质量框架珍贵一个主顾作为事件新闻的靶子。能够安装为enabled值。

在上一篇 《配置详解 |
performance_schema全方位介绍》中,大家详细介绍了performance_schema的陈设表,坚贞不屈读完的是真爱,也恭喜大家翻过了壹座火焰山。相信有好四人读完未来,已经等不比的想要蓄势待发了,前些天将教导我们共同踏上一而再串第二篇的道路(全系共五个篇章),在这一期里,大家将为大家无微不至授课performance_schema中事件原本记录表。上面,请随行大家一道起头performance_schema系统的求学之旅吧。

二3.二 质量框架配置

等待事件表

贰三.二.壹 质量框架编写翻译时布署

为了让质量框架启用必须在编写翻译时被布署,由官方提供的MySQL是支撑品质框架的,要是是其余发表方公布的,那么要先反省是或不是协理。

设倘诺从源代码宣布的,那么在揭橥的时候要先安装:

shell> cmake . -DWITH_PERFSCHEMA_STORAGE_ENGINE=1

在MySQL 伍.柒.三从此,也足以支撑运转质量框架,但是不包蕴全部的记录点,比方:

shell> cmake . -DWITH_PERFSCHEMA_STORAGE_ENGINE=1 \

        -DDISABLE_PSI_STAGE=1 \

        -DDISABLE_PSI_STATEMENT=1

一经您安装MySQL到贰个老的设置上,并且未有配备过质量框架,当确认保障performance_schema数据库包蕴了装有的脚下表后,能够利用mysql_upgrade运营服务。然后重启,有个迹象要尤其在意:

[ERROR] Native table ‘performance_schema’.’events_waits_history’
has the wrong structure
[ERROR] Native table
‘performance_schema’.’events_waits_history_long’has the wrong
structure

因而以下查看mysql是不是帮助品质框架:

shell> mysqld –verbose –help

  –performance_schema

                      Enable the performance schema.

  –performance_schema_events_waits_history_long_size=#

                      Number of rows in events_waits_history_long.

也足以因而连日到劳动之后采取show engine查看是或不是留存PE宝马X3FO奔驰M级MANCE_SCHEMA存款和储蓄引擎。如若在build的时候从不被安顿那么show engines不会显得PEOdysseyFOSportageMANCE_SCHEMA存款和储蓄引擎。

普通,大家在碰着品质瓶颈时,假如其他的艺术难以寻觅质量瓶颈的时候(比方:硬件负载不高、SQL优化和库表结构优化都不便见效的时候),大家日常要求依据等待事件来展开辨析,寻找在MySQL
Server内部,到底数据库响应慢是慢在何地。

2三.2.2 质量框架运营配置

设若品质框架是可用的,那么暗许是开发银行的也得以在布局文件中配置:

[mysqld]
performance_schema=ON

万1服务无法在起始化质量框架的时候分配内部缓存,那么质量框架本人关闭并且安装performance_schema为off,服务在未有记录点景况下运转。

属性框架能够以命令行参数形式布置。

–performance-schema-instrument=’instrument_name=value

关闭全体记录点:

–performance-schema-instrument=’%=OFF’

相比较长的记录点名会比短的储存点名要先期于短的方式名,不管顺序。

切切实实能够看前边章节:二三.二.3.四命名记录点或然消费者的过滤

2个不能别识别的记录点名会被忽略。为了垄断消费者,可以利用以下选项:

–performance-schema-consumer-consumer_name=value

consumer_name是一个顾客名比方events_waits_history,value是以下3个值:

l  OFF,False或然0:不采访这些消费者的风云

l  ON,True或许一:搜聚消费者的轩然大波

比如消费者名是events_waits_history:

--performance-schema-consumer-events-waits-history=ON

被允许的消费者名能够在setup_consumers表上找到。在表中消费者名字都以下划线,在挑选配置的时候,下划线和减号未有区分。

性格框架提供了数不尽体系变量可以用来配置:

mysql> SHOW VARIABLES LIKE 'perf%';

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

| Variable_name                                          | Value   |

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

| performance_schema                                     | ON      |

| performance_schema_accounts_size                       | 100     |

| performance_schema_digests_size                        | 200     |

| performance_schema_events_stages_history_long_size     | 10000   |

| performance_schema_events_stages_history_size          | 10      |

| performance_schema_events_statements_history_long_size | 10000   |

| performance_schema_events_statements_history_size      | 10      |

| performance_schema_events_waits_history_long_size      | 10000   |

| performance_schema_events_waits_history_size           | 10      |

| performance_schema_hosts_size                          | 100     |

| performance_schema_max_cond_classes                    | 80      |

| performance_schema_max_cond_instances                  | 1000    |

...

Performance_Schema代表了品质框架是不是运营,其余参数表示表的大小伙内部存款和储蓄器分配的值。

能够行使布置文件开设置那么些变量:

[mysqld]

performance_schema

performance_schema_events_waits_history_size=20

performance_schema_events_waits_history_long_size=15000

1经没有点名值,那么私下认可那么些变量会有一个暗许值。在MySQL
五.7.六,质量框架分配内部存款和储蓄器会依照服务符合增添伙子减少,而不是在劳务运营的时候一次性分配完了。所以众多参数并不须要在起步的时候都分配好,更加多内容能够看二3.1二品质框架连串变量。

各类机关分配的参数不是在运转时设置也许安装为-一,品质框架决定哪些依据以下的参数来安装这几个值:

max_connections

open_files_limit

table_definition_cache

table_open_cache

比方要覆盖机关安装的值可能电动范围的值,就在运转的时候设置五个加以的值而不是给-一这么品质框架就会设置一个加以的值。

在运转时,show variables会突显自动安装的值,自动范围设置的会给-一.万1质量框架被禁止使用,自动安装和自行范围参数都会被安装为-一,并且出示为-一.

伺机事件记录表包罗三张表,那些表记录了现阶段与近来在MySQL实例中爆发了怎么等待事件,时间消耗是稍稍。

二三.二.3 运营时质量框架配置

  • events_waits_current表:记录当前正值实行的等待事件的,各个线程只记录一行记录
  • events_waits_history表:记录已经实施完的近年的等候事件历史,默许每一个线程只记录十行记录
  • events_waits_history_long表:记录已经推行完的近年的等候事件历史,暗中认可全体线程的总记录行数为一千0行

二叁.二.三.1 品质框架结构事件按期

事件被采访也便是说记录点被加到了劳务源代码中。记录点时间事件,是性质框架怎样提供三个事变频频多短期的方案。也得以配备记录点搜聚定期消息。

质量框架停车计时器

三个脾气框架表提供了电磁照看计时器消息:

l  Performance_timers,保存了可用的timers和它们的本性。

l  Setup_timers,证明了哪些记录点使用了哪位timers。

每个setup_timers使用的电磁打点计时器躲在performance_timers表中。

mysql> SELECT * FROM performance_timers;

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

| TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD
|

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

| CYCLE       |      2389029850 |                1 |             72 |

| NANOSECOND  |      1000000000 |                1 |            112 |

| MICROSECOND |         1000000 |                1 |            136 |

| MILLISECOND |            1036 |                1 |            168 |

| TICK        |             105 |                1 |           2416 |

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

TIMER_NAME:表示可用timer的名字,CYCLE表示给予cpu计数器

TIMER_FREQUENCY:表示每秒的timer个数。对于cycle timer,频率和cpu事件有关,别的timer是秒的若干分。

TIMER_RESOLUTION:表示每便扩展的单位

TIMER_OVE大切诺基HEAD:内定周期获取2个定期供给的极小cycles个数。种种事件都会在上马三保终结的时候调用timer,因而是展现的负载的二倍。

修改setup_timer表的timer_name:

mysql> UPDATE setup_timers SET TIMER_NAME = ‘MICROSECOND’

    -> WHERE NAME = ‘idle’;

mysql> SELECT * FROM setup_timers;

+————-+————-+

| NAME        | TIMER_NAME  |

+————-+————-+

| idle        | MICROSECOND |

| wait        | CYCLE       |

| stage       | NANOSECOND  |

| statement   | NANOSECOND  |

| transaction | NANOSECOND  |

+————-+————-+

暗中认可质量框架会为各种记录点类型设置timer,也足以修改。

对于记录等待事件的时刻,最器重的是在岁月精度上压缩负荷,所以使用cycle
timer最合适。

对此说话或然stage的实行比进行一个简练的等待要大的多,并且须要三个精确的量,并且和计算机非亲非故,所以最棒不要选取cycle。默认使用NANOSECOND。就算负荷比cycle要大,不过不重大,因为调用1次计数器的多寡级远远比进行语句小编的cpu时间要小。

Cycle提供的精度和cpu有关,如果管理器是1Gh要么越来越高,cycle能够提供比微秒还小的速度。使用cycle计数器比得到一个1天的实在事件支出小。

Cycle的缺点:

l  从cycles转化为时间单位是比较费心的。为了越来越快,那几个转化操作知识相当粗糙的乘法总结。

l  管理器cycle,恐怕会遍,例如台式机进入省电形式,那么cpu
cycle会下跌假若cpu cycle有动乱,那么转化就会出错。

l  Cycle 计数器大概是不可靠的或许不可用的,和Computer可能操作系统有关。

l  一些管理器,乱序推行大概多管理器同步,或许会导致计数器忽高忽低。

脾性框架计数器在事变中的表现

仓库储存在性质框架表的近日事变,有1个列表示事件,TIME本田UR-V_START,TIMER_END表示事件运行和终结,TIME帕杰罗_WAIT代表事件的大运。

Set_instruments表有ENABLED字段来代表,事件是或不是要搜罗。TIMED字段表示记录点是还是不是被时光标志。若是记录点未有运营,那么就不会变卦事件。要是否timed,那么生成的事件,中TIME途达_START,TIME_END,TIMER_WAIT是null。那么在总结表总计最大时间,最时辰间的时候会被忽略。

个中,事件运行的时候,timer以给定的单位保存在事件之中,当要来得的时候,timers被出示为职业的风波单位,不管选了如何timer都会议及展览示为,微秒。

Setup_timers的修改会登时见效。已经在管理的会使用老的timer。为了不形成不能预料的结果出现,最棒先把计算表使用truncate
table进行重新设置。

Timer的基线,在劳务运维的时候被开端化。TIME酷路泽_START,TIMER_END代表从基线以来的阿秒数。TIMECRUISER_WAIT代表占用的阿秒。

要注意:等待事件相关陈设中,setup_instruments表中多方面包车型大巴等候事件instruments都未有拉开(IO相关的守候事件instruments默许超越1/3已开启),setup_consumers表中waits相关的consumers配置暗中同意未有展开

二3.2.三.二 质量框架事件过滤

事件是以生产者消费者方式管理的:

l  记录点代码是事件的源,产惹祸件被用来搜聚,setup_instruments表列出了能够被搜罗的记录点。Setup_instruments表提供了成百上千event的产生。

l  质量框架表示事件的目标地。Setup_consumers,列出了颇具顾客类型。

预过滤,通过改造质量框架配置落成,能够透过启用只怕剥夺记录点和顾客达成。使用预过滤的目标:

n  减弱负荷。品质框架运转要求消功耗源,即使很少。

n  不尊崇的轩然大波能够不写入消费者中。

n  防止维护多个项目的事件表。

·           事后过滤,能够应用where语句在询问品质框架的时候过滤。

events_waits_current 表

二叁.二.③.三 事件预过滤

预过滤有性能框架产生同时会全局的影响全体用户。预过滤能够在劳动者或然消费者的管理阶段上:

·           多少个表能够用来布署生产者的预过滤:

§   Setup_instruments表达哪个记录点是可用的,假诺那么些表上八个记录点被禁止使用,不管其余表怎么布局,都不会再发生事件。

§   Setup_objects调控了品质框架特定表和累积进度对象。

§   Threads表示是或不是每一种服务线程都有监察和控制

§   Setup_actors新的后台进度的开首监察和控制意况

·           要配备预过滤在消费者阶段,那么要修改setup_comsumers表。setup_comsumers也会影响事件的爆发。假如钦点的风浪不会发送给任啥地方方,那么品质框架不会产生

修改放4表都会应声影响监察和控制,不过多少区别:

·         修改有个别setup_instruments表唯有的服务启动的时候生效。在运作时修改不会一蹴而就。

·         修改setup_actors表,只会影响后台线程。

当修改监察和控制配置,品质框架不会刷新历史表。历史表和近日表的风浪不会被沟通,除非又新的轩然大波。假若禁止使用三个记录点的时候,须求等待1段时间,来替换老的风浪。也得以用truncate
table清空。

在修改完记录点之后,或许下10分药伤处summary表清理计算音信对于events_statements_summary_by_digest或然内部存款和储蓄器计算表。Truncate table只会重新初始化值为0,并不会去除行。

events_waits_current表包罗当前的等待事件新闻,各样线程只显示1行方今监视的等候事件的目前情状

23.二.三.三.1 记录点预过滤

支配记录点的过滤,是过滤setup_instruments表设置enables字段。修改setup_instruments大繁多会立马见效。对于一些记录点,修改只会在服务器运行才会一蹴而就。setup_instruments提供了最基本的记录点调控。

在装有包括等待事件行的表中,events_waits_current表是最基础的数量来源于。其余富含等待事件数据表在逻辑上是根源events_waits_current表中的当前事件消息(汇总表除却)。比如,events_waits_history和events_waits_history_long表中的数据是events_waits_current表数据的二个小集结汇总(具体存放多少行数据会集有独家的变量支配)

二叁.贰.3.三.2 对象预过滤

Setup_objects表调整了品质框架部分表和积存进程。修改Setup_objects会立即相应。

mysql> SELECT * FROM setup_objects;

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

| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME | ENABLED | TIMED |

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

OBJECT_TYPE:表示对象类型,比如表大概事件,存款和储蓄进度等。

OBJECT_SCHEMA和OBJECT_NAME包括了schema大概目标名的字符串,也能够是通配符

ENABLED列表示对象是否被监察和控制,TIMED列表示是不是搜聚timing音信。

默许会搜集除了mysql,information_schema,performance_schema外全数的的数据库对象。

表记录内容示例(那是三个施行select
sleep(100);语句的线程等待事件音讯)

2三.贰.3.三.三 线程预过滤

threads表为每一个线程保存了①行数据。每行数据都带有了线程的音信同时申明是或不是被监察和控制。对于品质框架监察和控制四个线程必须知足一下她条件:

·         表sestup_consumers表中的thread_instrumentation必须为yes

·         Threads.instrumented列必须为yes

·         只监控setup_instruments表中的记录点

threads表也表明了种种服务线程是还是不是实施历史事件记录。假若要记录历史事件以下标准都必须为真:

·         对应的消费者配置,setup_consumers表必须为yes。

·         Threads.HISTO昂CoraY列必须为yes。

·         只监控setup_instruments表中的记录点

对此后台线程,instrumented和history的起头数据,取决于setup_action中的配置。

mysql> SELECT * FROM setup_actors;

+——+——+——+———+———+

| HOST | USER | ROLE | ENABLED | HISTORY |

+——+——+——+———+———+

| %    | %    | %    | YES     | YES     |

+——+——+——+———+———+

thread表的instrumented和history的规则如下:

·         假诺最好相称,enabled=yes,那么instrumented=yes,最棒相称history=yes,那么threads表的history=yes

·         假设最好相配,enabled=no,那么instrumented=no,最好相称history=no,那么threads表的history=no

·         借使不能够合营,那么instrumented,history都为no

在mysql 五.7.六 以前,没有enabled字段,只要有相当,那么instrumented=yes

在mysql5.7.8,在此之前,未有history字段,线程要不全部得以进入history要不都不能,取决于setup_consumer的配置。

暗中认可,后台的保有线程都是会被记录的,因为setup_actors有一行都以‘%’。

root@localhost : performance _schema 12:15:03> select * from
events_waits _current where EVENT_NAME=’wait/synch/cond/sql/Item
_func_sleep::cond’G;

二三.贰.三.三.4 消费者预过滤

Setup_cunsumers表包括了具备的顾客。修改这一个表来过滤那么些event会被发送。

Setup_consumers表中安装消费者,从高端到低端。首要的尺码如下:

·           除非质量框架检查消费者,并且消费者是可用的,不然不会受到信息。

·           唯有当顾客依赖的有所的顾客都可用了,才会被检查

·           被信赖的顾客,有和好的依赖性消费者。

·           倘使一个轩然大波未有目标,那么品质框架不会被发生。

全局和线程消费者

·           Global_instrumentation是高端消费者,借使global_instrumentation为no,那么具有的的全局记录点都被剥夺。全体其他低档的都不会被检查。当global_instrumentation运维了,才会去反省thread_instrumentation

·           Thread_instrumentation,即使是no,那么这些等级上边包车型客车品级都不会被检查,若是是yes,质量框架就会维护线程钦点音信,并且检查events_xxx_current消费者。

Wait Event消费者

这几个消费者,需求global_instrumentation,thread_instrumention为yes。即便被检查行为如下:

·           Events_waits_current,假若为no,禁用对种种wait
event搜罗。借使为yes检查history消费者和history_long消费者。

·           Events_waits_history,假使上边为no不检讨,为yes,搜罗种种等待事件。

·           Events_waits_history_long,和下面类似

Stage event,statement event和方面类似。

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

二三.二.三.肆命名记录点可能消费者的过滤

能够对点名记录名只怕消费者举行过滤:

mysql> UPDATE setup_instruments

    -> SET ENABLED = ‘NO’

    -> WHERE NAME =
‘wait/synch/mutex/myisammrg/MYRG_INFO::mutex’;

 

mysql> UPDATE setup_consumers

    -> SET ENABLED = ‘NO’ WHERE NAME = ‘events_waits_current’;

钦定一组记录点恐怕消费者:

mysql> UPDATE setup_instruments

    -> SET ENABLED = ‘NO’

    -> WHERE NAME LIKE ‘wait/synch/mutex/%’;

 

mysql> UPDATE setup_consumers

    -> SET ENABLED = ‘NO’ WHERE NAME LIKE ‘%history%’;

THREAD_ID: 46

二三.贰.三.5 识别哪些已经被记录

透过检查setup_instruments表,你能够摸清包含了什么记录点被记录:

mysql> SELECT * FROM setup_instruments WHERE NAME LIKE
‘wait/io/file/innodb/%’;

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

| NAME                                 | ENABLED | TIMED |

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

| wait/io/file/innodb/innodb_data_file | YES     | YES   |

| wait/io/file/innodb/innodb_log_file  | YES     | YES   |

| wait/io/file/innodb/innodb_temp_file | YES     | YES   |

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

EVENT_ID: 140

2三.3 质量框架查询

预过滤限制了何等事件消息被采访,许多用户都不可同日而语。能够通过select过滤event。

mysql> SELECT THREAD_ID, NUMBER_OF_BYTES

    -> FROM events_waits_history

    -> WHERE EVENT_NAME LIKE ‘wait/io/file/%’

    -> AND NUMBER_OF_BYTES IS NOT NULL;

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

| THREAD_ID | NUMBER_OF_BYTES |

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

|        11 |              66 |

|        11 |              47 |

|        11 |             139 |

|         5 |              24 |

|         5 |             834 |

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

END_EVENT_ID: NULL

二三.四 质量框架记录点命名约定

记录点命名是1串组件然后用‘/’分割:

wait/io/file/myisam/log
wait/io/file/mysys/charset
wait/lock/table/sql/handler
wait/synch/cond/mysys/COND_alarm
wait/synch/cond/sql/BINLOG::update_cond
wait/synch/mutex/mysys/BITMAP_mutex
wait/synch/mutex/sql/LOCK_delete
wait/synch/rwlock/sql/Query_cache_query::lock
stage/sql/closing tables
stage/sql/Sorting result
statement/com/Execute
statement/com/Query
statement/sql/create_table
statement/sql/lock_tables

记录点命名类似于树形结构。从左到右越来越详细,组件的名称以来与计数器类型。

名字由二局地构成:

·           组件名,比如mysiam

·           变量名,一种是全局变量,还有1种是class::value。值class类中的变量。

超级记录点组件

·           Idle:表示idle事件的记录点。

·           Memory:memory事件记录点

·           Stage:阶段事件记录点

·           Statement:语句事件记录点

·           Transaction:事务事件记录点

·           Wait:等待事件记录点

Idle记录点组件

Idle记录点用于idle事件,具体看:二叁.九.3.5 socket_instance表

内部存款和储蓄器记录点组件

多多内部存款和储蓄器记录点暗中同意是不可用的,可以手动运营,修改setup_instruments表。记录点前缀,memory/performance_schema/表示有些许品质框架之中的内存分配。memory/performance_schema/总是启用的,并且不可能被剥夺。这件记录点被收集在 memory_summary_global_by_event_name表。

Stage记录点组件

Stage表示语句阶段性管理的比方说sorting
result也许sending data。

语句记录点组件

·           Statement/abstract/*: 抽象语句操作记录点。抽象记录点在言语早期采纳。

·           Statement/com :是记录点命令操作。并且有名字对应到com_xxx操作,比如statement/com/Connect 和 statement/com/Init DB对应到COM_CONNECT和COM_INIT_DB命令。

·           Statement/scheduler/event:单个记录点用来追踪全部事件调节生成的轩然大波。

·           Statement/sp :存款和储蓄进度举行内部的记录点,比如statement/sp/cfetch
和statement/sp/freturn,用来游标获取和函数再次来到。

·           Statement/sql:sql操作的记录点,比方statement/sql/create_db和statement/sql/select,用于创立数据库和select语句。

等候记录点指令

·           Wait/io,io操作记录点

§   Wait/io/file:文件io操作记录点,对于文本,等待是伺机文件操作文件落成。因为缓存的关联,物理文件io或许在这么些操作上不会奉行

§   Wait/io/socket:socket操作记录点,socket记录点有以下命名格式:wait/io/socket/sql/socket_type。服务有3个监听socket用来援救各类网络协议。那一个记录点帮忙监听socket是tcpip可能unix
socket文件。socket_type的值为server_tcpip_socket或者server_unix_socket。当监听socket开采1个总是,服务把那些一而再调换成独门的线程。那么新的接连线程的socket_type为client_connection。

§   Wait/io/table: 表io操作记录点。包罗持久性表大概一时表的行等级访问。对行的影响正是fetch,insert,update,delete。对于视图,是被视图引用的基表。和其他等待区别,表的io等待报货别的等待。比如表io或许带有,文件io只怕内部存款和储蓄器操作。由此events_waits_current中对此行的守候也许有二行。

·           Wait/lock ,锁操作的记录点

§   Wait/lock/table,表锁记录点操作

§   Wait/lock/metadata/sql/mdl,元数据所操作

·           Wait/synch,同步对象记录点

§   Wait/synch/cond,条件被用来三个线程文告别的三个线程,有些它们等待的事物已经做到。借使三个线程等待贰个原则,那么会醒来并且管理。假诺四个线程等待那么会都新来并且做到它们等待的能源。

§   Wait/synch/mutex,多排他对象用来走访3个能源,制止别的线程访问财富。

§   Wait/synch/rwlock,三个读写锁对象用来锁定特定的变量,防止别的线程使用。一个共享读所能够七个线程同时获得。1个排他写锁只好由三个线程获取。

§   Wait/synch/sxlock,共享排他锁是读写锁的rwlock的一种,提供当四个线程写时,其余线程可以非一致性读。Sxlock在mysql 5.7中动用为了优化rwlock的或显示。

EVENT_NAME: wait/synch/cond/sql/Item_func_sleep::cond

二叁.伍 品质框架和境况监察和控制

能够行使show status like ‘%perf%’查看品质框架的情形。

性格框架状态变量提供了有关记录点因为内部存款和储蓄器的缘由尚未被创制大概加载的新闻。遵照气象命名有几类:

·           Performance_Schema_xxx_class_lost,表示有个别许xxx类型的记录点无法被加载。

·           Performance_schema_xxx_instance_lost,表示有微微xxx类型的记录点不能够被创设。

·           Performance_schema_xxx_handlees_lost,表示有稍许xxx类型的记录点无法被展开。

·           Performance_schema_locker_lost,表示有多少日子都以要么未有被记录。

比方,三个确定性信号量是记录点,不过服务不可能为记录点分配内部存款和储蓄器。那么会加多performnace_schema_mutex_classes_lost。然而功率信号量照旧以用来对象同步。可是质量数据就不能被搜罗,若是记录点被分配,用来开始化记录点实信号量实体。对于单身的频域信号量比方全局复信号量,唯有2个实例。有个别实信号量的实例个数会生成,例如各个连接的实信号量。要是服务不能够创造一个点名记录点时域信号量实体,就会大增,performance_schema_mutex_instance_lost。

假使有以下原则:

·           服务运转参数,–performance_schema_max_mutex_classes=200,由此有200个时域信号量空间。

·           150功率信号量已经被加载

·           插件plugin_a有三十三个非信号量

·           插件plugin_b有1九个复信号量

劳动为插件,分配复信号量记录点正视于已经分配了略微,举个例子以下语句:

INSTALL PLUGIN plugin_a

那么服务业已有了150+四十多个能量信号量。

UNINSTALL PLUGIN plugin_a;

固然插件已经卸载,但是依旧有1九十个时域信号量。全部插件代码生成的野史数据依然实惠。不过新的记录点事件不会被分配。

INSTALL PLUGIN plugin_a;

劳务意识四十多少个记录点已经被分配,因而新的记录点不会被创立,并且在此之前分配的当中buffer会被重新利用,非功率信号量还是1捌拾陆个。

INSTALL PLUGIN plugin_b;

其一应用可用非时限信号量已经唯有13个了,新的插件要21个记录点。11个已经被加载,1叁个会被裁撤大概丢失。Performance_schema_mutex_classes_lost会标识这一个丢失的记录点。

mysql> SHOW STATUS LIKE “perf%mutex_classes_lost”;

+—————————————+——-+

| Variable_name                         | Value |

+—————————————+——-+

| Performance_schema_mutex_classes_lost | 10    |

+—————————————+——-+

1 row in set (0.10 sec)

Plugin_b任然会搜集施行部分记录点。

当服务不可能创制三个时限信号量记录点,那么会生出以下情状:

·           不会有新行被插入到setup_instruments表

·           Performance_Schema_mutex_classes_lost增加1

·           Performance_schema_mutex_instance_lost,不会变动。

地方描述的适用于具备记录点,不单单是复信号量。

当Performance_Schema_mutex_classes_lost大于0那么有2种情况:

·           为了保存一些内存,你能够运维,Performance_Schema_mutex_classes=N,N小于暗许值。默许值是满足加载全数插件的mysql公布。可是部分插件假如不加载只怕会少一点。例如您能够不加载默写存款和储蓄引擎。

·           你加载一个第三方插件,是性质框架的记录点,不过在劳务运行的时候,分歧意插件记录点内部存款和储蓄器获取。因为来自第壹方,那些引擎的记录点内部存款和储蓄器并不会被记录在performance_schema_max_mutex_classes.
设若服务不能够知足插件记录点的财富,未有彰显的分配越多的 performance_schema_max_mutex_classes,那么久会现出记录点的饥饿。

 

如果performance_schema_max_mutex_classes.太小,未有不当会被写入到不当日志,并且在运转时并没错误。但是performance_schema上的表会丢失事件。performance_schema_max_mutex_classes_lost状态变量只是标识一些轩然大波归因于制造记录点失利被删除。

 

假如记录点未有丢失,那么就会通知质量框架,当在代码中(THD::LOCK_delete)成立了非确定性信号量,单个记录点就会被使用。那么就必要过多功率信号量实体。今年,每个线程都有lock_delete,比如有1000个线程,1000个lock_delete信号量记录点实例。

只要服务未有空间存放全数一千个时域信号量记录点实体,一些非确定性信号量会被创建记录点,一些就不会被成立。假诺服务效果创立800个,那么其它200个会丢掉,Performance_schema_mutex_instances_lost会增加200个。

Performance_schema_mutex_instances_lost,可能在要伊始化的时域信号量记录点大于配置的Performance_schema_mutex_instances=N那么久会生出。

壹经SHOW STATUS LIKE ‘perf%’未有丢失任何事物,那么新能框架数据是足以被正视的。倘诺有一些都以了,那么数量是不完全的,并且品质框架不会记录全体。那样Performance_schema_xxx_lost就证实了难点范围。

些微时候饥饿时方可平衡的,比方您恐怕不需求文件io的多少,那么能够把持有质量框架参数,和文书io相关的都设置为0,那么久不会把内部存款和储蓄器分配到和文书有关的类,对象实例大概句柄中。

SOURCE: item_func.cc:5261

二三.六 品质框架和成员原子性事件

对此1个表的io事件,平日有二行在events_waits_current,不是一个如:

Row# EVENT_NAME                 TIMER_START TIMER_END
—- ———-                 ———– ———
   1 wait/io/file/myisam/dfile        10001 10002
   2 wait/io/table/sql/handler        10000 NULL

行得到会导致文件读取。举例,表io获取事件在文书io事件在此以前,然则还不曾到位。那么文件io嵌入在表io事件。

和别的原子性等待事件分歧,表io事件是成员,包含别的事件。伊夫nts_waits_current中,表io事件数见不鲜有2行:

·           壹行是当前表io等待事件

·           一行是任何任何类型的等待事件。

习认为常,别的类型的等待事件不是表io事件。当副事件造成,会从events_waits_current中消失。

TIMER_START: 14128809267002592

2三.七 品质框架statement digests

MySQL服务有本事保证statement digest消息。Digest进程把二个sql语句转化为正规的格式并且总结3个hash结果。标准化允许相似的言语分组并且计算暴露一些说话的项目和产生的成效。

在性质框架,语句digest涉及那一个组件:

·           Setup_comsumers的statement_digset调节了,质量框架如何有限援救digest新闻。

·           语句事件表有列包涵digest和连锁的值的列:

§   DIGEST_TEXT,标准化的言辞。

§   DIGEST,是digest MD5 hash值。

Digest总括,最大的可用空间十2肆B。MySQL 5.七.8后那些值能够经过参数,performance_schema_max_digest_length修改。此前运用max_digest_length。

·           语句事件表也有sql_text列包含了原始的sql语句。语句展现的最大为1024B,能够透过performance_schema_max_sql_text_length字段修改。

·           events_statements_summary_by_digest,提供综合的语句digset音讯。

基准贰个言辞转化,会保留语句结构,删除不须要的新闻:

·           对象标志符,比如表也许数据库名会被保存。

·           文本值会被替换来变量。

·           注释会被剔除,空格会被调解。

诸如如下3个语句:

SELECT * FROM orders WHERE customer_id=10 AND quantity>20

SELECT * FROM orders WHERE customer_id = 20 AND quantity > 100

轮换后会产生:

SELECT * FROM orders WHERE customer_id = ? AND quantity > ?

对此每一个标准化的话语提供三个DIGEST_TEXT和DIGEST1个hash值。语句Digest总括表,提供了言语的profile新闻,展现语句运转效能运维次数等。

events_statements_summary_by_digest大小固定的,所以1旦满了,如果在表上未有相配的,那么具备的说话都会被总结在schema_name和digest为null的笔录里面,当然能够扩大digest大小,performance_schema_digests_size,假设未有点名,那么品质框架会自身评估多少个值。

performance_schema_max_digest_length系统变量支配digest buffer最大可用字节。可是实际的语句digest的尺寸往往比buffer长,那是因为根本字和文本值的关系。也就是说digest_text的长度或者超过performance_schema_max_digest_length。

对此应用程序生成了不长的口舌,唯有最后不一致,扩张performance_schema_max_digest_length能够让digest得以总计,识别语句。反过来收缩performance_schema_max_digest_length会导致服务就义很少的内部存款和储蓄器来保存语句的digest,不过扩张了话语的相似度,被当成同贰个digest。假如长度必要长,那么保存的也要更加多。

能够透过show engine performance_schema
status语句,恐怕监察之下语句查看sql语句保存使用的内部存款和储蓄器量。

mysql> SELECT NAME FROM setup_instruments

    -> WHERE NAME LIKE '%.sqltext';

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

| NAME                                                             |

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

| memory/performance_schema/events_statements_history.sqltext      |

| memory/performance_schema/events_statements_current.sqltext      |

| memory/performance_schema/events_statements_history_long.sqltext |

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

 

mysql> SELECT NAME FROM setup_instruments

    -> WHERE NAME LIKE 'memory/performance_schema/%.tokens';

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

| NAME                                                                 |

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

| memory/performance_schema/events_statements_history.tokens           |

| memory/performance_schema/events_statements_current.tokens           |

| memory/performance_schema/events_statements_summary_by_digest.tokens |

| memory/performance_schema/events_statements_history_long.tokens      |

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

TIMER_END: 14132636159944419

二3.八 品质框架常用表本性

Performance_schema数据库是小写的,数据Curry面包车型客车表名也是小写的。查询要使用小写。

广大表在performance_schema数据库是只读的不可能被改换。一些setup表的某个列可以被涂改。一些也足以被插入和删除。事务能够被允许清理搜罗的风云,所以truncate
table能够用来清理新闻。

Truncate table能够在总计表上选用,不过无法再events_statements_summary_by_digest和内部存款和储蓄器总计表上利用,效果只是把总括列清理为0.

TIMER_WAIT: 3826892941827

23.九 品质框架表描述

SPINS: NULL

二叁.九.一 质量框架表索引

具体看:

OBJECT_SCHEMA: NULL

二三.9.贰 质量框架setup表

Setup表提供关于当前搜集点启用音信。使用表而不是全局变量提供了越来越高端别的质量框架配置。举个例子你能够利用贰个sql语句配置四个记录点。

那个setup表示可用的:

·           Setup_actors:如何伊始化后台线程

·           Setup_consumers:决定怎么着音信会被发送和积累。

·           Setup_instruments:记录点对象,哪些事件要被采访。

·           Setup_objects:哪些对象要被监督

·           Setup_timers:当前事件电磁照管计时器。

OBJECT_NAME: NULL

23.9.2.1 setup_actors表

setup_actors表包罗了音信决定是或不是监察和控制恐怕对新的后台线程实行历史数据记录。那么些表暗许最多拾0行,能够透过修改参数performance_schema_setup_actors_size修改尺寸。

对此新的后台线程,在setup_actors中,质量框架满意的用户和host。若是3个行负荷enabled,histroy列,对应到threads表上的instrumented和history列。假诺找不到卓殊那么instrumented和history列就为no。

对此后台线程, Instrumented和history暗中同意都以yes,setup_actors私下认可未有界定。

Setup_actors伊始化内容,不过滤任何数据:

mysql> SELECT * FROM setup_actors;

+——+——+——+———+———+

| HOST | USER | ROLE | ENABLED | HISTORY |

+——+——+——+———+———+

| %    | %    | %    | YES     | YES     |

+——+——+——+———+———+

修改setup_actors表只会潜移默化后台线程,不会潜移默化已经存在的线程。为了影响已经存在的threads表,修改instrumented和history列。

INDEX_NAME: NULL

23.9.2.2 setup_consumers表

Setup_consumers表列了各种品类的消费者:

mysql> SELECT * FROM setup_consumers;

+———————————-+———+

| NAME                             | ENABLED |

+———————————-+———+

| events_stages_current            | NO      |

| events_stages_history            | NO      |

| events_stages_history_long       | NO      |

| events_statements_current        | YES     |

| events_statements_history        | YES     |

| events_statements_history_long   | NO      |

| events_transactions_current      | NO      |

| events_transactions_history      | NO      |

| events_transactions_history_long | NO      |

| events_waits_current             | NO      |

| events_waits_history             | NO      |

| events_waits_history_long        | NO      |

| global_instrumentation           | YES     |

| thread_instrumentation           | YES     |

| statements_digest                | YES     |

+———————————-+———+

Setup_consumers设置产生从高到低的品级。产生重视,借使高档其他设置了低等别才会有机会被检查。

OBJECT_TYPE: NULL

23.9.2.3 setup_instruments表

Setup_consumers表列了装有记录点对象:

mysql> SELECT * FROM setup_instruments;

各样记录点被扩张到源代码中,都会在那一个表上有1行,尽管记录点代码未有被钦定。当二个记录点运维了或许实行了,记录点实例就会被创造会显得在*_instrances表。

修改setup_instruments行会立时影响监察和控制。对于一些记录点,修改只会在下次起头才会生效。在指定时修改并不会收效。

OBJECT _INSTANCE_BEGIN: 140568905519072

23.9.2.4 setup_objects表

Setup_objects表调控了怎么样对象的属性框架会被监察和控制。那个目的默感觉十0行可以透过修改换量来决定,performance_schema_setup_objects_size。

早先化的setup_objects如下:

mysql> SELECT * FROM setup_objects;

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

| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME | ENABLED | TIMED |

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

| EVENT       | mysql              | %           | NO      | NO    |

| EVENT       | performance_schema | %           | NO      | NO    |

| EVENT       | information_schema | %           | NO      | NO    |

| EVENT       | %                  | %           | YES     | YES   |

| FUNCTION    | mysql              | %           | NO      | NO    |

| FUNCTION    | performance_schema | %           | NO      | NO    |

| FUNCTION    | information_schema | %           | NO      | NO    |

| FUNCTION    | %                  | %           | YES     | YES   |

| PROCEDURE   | mysql              | %           | NO      | NO    |

| PROCEDURE   | performance_schema | %           | NO      | NO    |

| PROCEDURE   | information_schema | %           | NO      | NO    |

| PROCEDURE   | %                  | %           | YES     | YES   |

| TABLE       | mysql              | %           | NO      | NO    |

| TABLE       | performance_schema | %           | NO      | NO    |

| TABLE       | information_schema | %           | NO      | NO    |

| TABLE       | %                  | %           | YES     | YES   |

| TRIGGER     | mysql              | %           | NO      | NO    |

| TRIGGER     | performance_schema | %           | NO      | NO    |

| TRIGGER     | information_schema | %           | NO      | NO    |

| TRIGGER     | %                  | %           | YES     | YES   |

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

修改setup_objects表会立时影响监控。

对于setup_objects,object_type代表监察和控制了何等对象类型。假诺未有匹配的object_schema,object_name。那么就不会有目的没监理。

NESTING _EVENT_ID: 116

23.9.2.5 setup_timers表

Setup_times表如下:

mysql> SELECT * FROM setup_timers;

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

| NAME        | TIMER_NAME  |

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

| idle        | MICROSECOND |

| wait        | CYCLE       |

| stage       | NANOSECOND  |

| statement   | NANOSECOND  |

| transaction | NANOSECOND  |

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

Timer_name是,performance_timers中的一行。表示某些事件类型应用了何等定时器

NESTING _EVENT_TYPE: STATEMENT

二三.九.三 质量框架实例表

OPERATION: timed_wait

23.9.3.1 cond_instances表

Cond_instance表列出了富有品质框架能够查阅的原则。条件是同步机制,用来打招呼叁个点名的轩然大波已经发出完结。所以3个线程等待这一个原则的会及时复苏专业。

当2个线程等待的事物已经转移,条件名值表明线程在等待条件名。

NUMBER _OF_BYTES: NULL

23.9.3.2 file_instances表

当钦定文件io记录点的时候,File_instances表列出了拥有质量框架能来看的装有文件。纵然文件在disk可是尚未被张开不会产出在file_instrances中。当文件在次磁盘中被去除,那么file_instances中也会去除。

FLAGS: NULL

23.9.3.3 mutex_instances表

Mutex_instances呈现了富有能够被质量框架查看到的功率信号量。信号量是联合具名机制用来有限支持能源。当3个线程运转供给放问一样的财富,一个线程会相互争用,一个线程获取了mutex上的锁,那么其它一个只好等待上一个做到。

当职责实施获取随机信号量,称为临界区域,区域内施行都以种种的,可能有潜在瓶颈难点。

表中有3个字段:

Name:记录点的名字

OBJECT_INSTANCE_BEGIN:被记录的能量信号量在内部存款和储蓄器中的地址。

LOCKED_BY_THREAD_ID:拥有mutex的线程id,否则为null。

对此各样记录的复信号量,质量框架提供一下音信:

·         Setup_instruments表列出了记录点名,以wait/synch/mutex/为前缀。

·         当有代码创造了能量信号量,那么就有1行被参预到mutex_instrances表中,OBJECT_INSTANCE_BEGIN列是mutex的绝无仅有列。

·         当八个线程视图锁定期域信号量,events_waits_current表为线程展现一行,表明在等候时域信号量,通过object_instance_begin。

·         当线程成功锁定了八个非复信号量:

§  Events_waits_current,彰显等待复信号量就会完结

§  落成的风浪会被增添到历史表中

§  Mutex_instances显示功率信号量以往属于1个thread

·         当thread unlock二个复信号量,mutex_instances展现随机信号量未来平昔不owner,thread_id为null。

·         当复信号量对象被灭绝,对应的行也会被剔除。

查以下1个表,能够会诊瓶颈或然死锁:

§  Events_waits_current,查看线程等待的非实信号量。

§  Mutex_instrances,查看别的线程的全数的实信号量。

1 row in set (0.00 sec)

23.9.3.4 Rwlock_instances表

Rwlock_instances表列出了全数rwlock的实例。PRADOwlock是1块机制用来强制在一定规则下,在给定的风浪之中能访问片段能源。那几个能源被rwlock爱护。访问要不是共享艺术要不是排他方式,借使允许非1致性访问,还足以共享排他格局访问。Sxlock唯有在,mysql 伍.七从此技巧被利用,用来优化并发性。

听别人讲访问的急需,所的呼吁要不是,共享,排他,共享排他或然不授权,等待其余线程达成。

表列如下:

·           NAME:记录点名相关的lock

·           OBJECT_INSTANCE_BEGIN:被记录的锁在内部存款和储蓄器中的地址。

·           WRITE_LOCKED_BY_THREAD_ID:当3个线程有二个rwlock,排他形式,W福睿斯ITE_LOCKED_BY_THREAD_ID,就是锁定线程的thread_id。

·           READ_LOCKED_BY_COUNT:当线程当前有一个rwlock共享方式,那么read_locked_by_count扩张一。只是个计数,所以找不到充裕线程具备了读锁,但是能够用来查阅是或不是有读锁,有多少读是活动的。

因而实施查询一下表,何以知道瓶颈和死锁:

·           Events_waits_current,查看等待哪些rwlock

·           Rwlock_instrances,查看别的线程是不是富有这些锁。

只好知道十一分线程有了write lock可是不知情哪个线程有read lock。

地点的出口结果中,TIME奥迪Q三_WAIT字段即意味着该事件的时光支出,单位是阿秒,在实际上的施用场景中,大家得以行使该字段音信实行倒序排序,以便搜索时间支付最大的等候事件。

23.9.3.5 socket_instance表

Socket_instancees表提供了八个实时的总是活动快速照相。每一种tcp/ip连接有1行,或许每一种unix socket file连接有一行。

mysql> SELECT * FROM socket_instances\G

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

           EVENT_NAME: wait/io/socket/sql/server_unix_socket

OBJECT_INSTANCE_BEGIN: 4316619408

            THREAD_ID: 1

            SOCKET_ID: 16

                   IP:

                 PORT: 0

                STATE: ACTIVE

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

           EVENT_NAME: wait/io/socket/sql/client_connection

OBJECT_INSTANCE_BEGIN: 4316644608

            THREAD_ID: 21

            SOCKET_ID: 39

                   IP: 127.0.0.1

                 PORT: 55233

                STATE: ACTIVE

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

           EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

OBJECT_INSTANCE_BEGIN: 4316699040

            THREAD_ID: 1

            SOCKET_ID: 14

                   IP: 0.0.0.0

                 PORT: 50603

                STATE: ACTIVE

socket记录点名字格式,wait/io/socket/sql/socket_type:

1.劳动有三个监听socket,记录点那么socket_type的值为server_tcpip_socket或者server_unix_socket``。

贰.      当有1个监听socket发现一个连连,那么服务会转化到二个新的socket来治本,server_type类型为client_connection。

三.      当1个接二连三中断,那么行会在socket_instances中删除。

Socket_instances表类如下:

·           EVENT_NAME: wait/io/socket/*,具体的名字来至于setup_instruments表

·           OBJECT_INSTANCE_BEGIN:socket的唯壹标志,值为对象在内部存款和储蓄器中的值。

·           THREAD_ID:内部线程表示。各类socket由线程管理,所以每一种socket被映射到叁个线程。

·           SOCKET_ID:socket内部的分红的文书句柄

·           IP:客户端ip地址

·           PORT:客户端端口地址

·           STATE:socket状态要不是idle要不是active。假若线程等待client的请求,那么情形就是idle。当socket变成idle,表中的STATE也会成为IDLE,socket的记录点中断。当呼吁出现idle中断,形成ACTIVE。Socket的记录点timing复苏。

IP:PORT组合来代表3个使得的连天。组合值被用于events_waits_xxx表的object_name,来标识连接来至于何地:

·           来至于unix域监听socket,端口是0,ip为‘’

·           对于因而unix域监听的socket,端口是0,ip为‘’

·           对于tcp/ip的监听,端口是劳动的端口,默感到3306,ip为0.0.0.0

·           对于通过tcp/ip连接的客户端接口,端口不为0,ip是客户端的ip。

events_waits_current表完整的字段含义如下:

二三.九.四 质量框架事件等待表

事件等待表有三个:

·           Events_waits_current:当前事变等待表

·           Events_waits_history:历史等待历史表,近来的等候事件表

·           Events_waits_history_long:诸多事件等待历史的表。

等候历史配置

为了收集等待事件,运转相应的记录点和消费者。

mysql> SELECT * FROM setup_instruments

    -> WHERE NAME LIKE ‘wait/io/file/innodb%’;

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

| NAME                                 | ENABLED | TIMED |

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

| wait/io/file/innodb/innodb_data_file | YES     | YES   |

| wait/io/file/innodb/innodb_log_file  | YES     | YES   |

| wait/io/file/innodb/innodb_temp_file | YES     | YES   |

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

mysql> SELECT * FROM setup_instruments WHERE

    -> NAME LIKE ‘wait/io/socket/%’;

+—————————————-+———+——-+

| NAME                                   | ENABLED | TIMED |

+—————————————-+———+——-+

| wait/io/socket/sql/server_tcpip_socket | NO      | NO    |

| wait/io/socket/sql/server_unix_socket  | NO      | NO    |

| wait/io/socket/sql/client_connection   | NO      | NO    |

+—————————————-+———+——-+

修改enabled和timing列:

mysql> UPDATE setup_instruments SET ENABLED = ‘YES’, TIMED =
‘YES’

    -> WHERE NAME LIKE ‘wait/io/socket/sql/%’;

Setup_consumers包含消费者对应到刚刚的事件表。这么些消费者用来过滤等待事件的募集,暗许被剥夺:

mysql> SELECT * FROM setup_consumers WHERE NAME LIKE ‘%waits%’;

+—————————+———+

| NAME                      | ENABLED |

+—————————+———+

| events_waits_current      | NO      |

| events_waits_history      | NO      |

| events_waits_history_long | NO      |

+—————————+———+

起步全体的等候事件:

mysql> UPDATE setup_consumers SET ENABLED = ‘YES’

    -> WHERE NAME LIKE ‘%waits%’;

Setup_timers表包括了一行name为wait,表示等待事件的定期的单位,暗中认可是cycle:

mysql> SELECT * FROM setup_timers WHERE NAME = ‘wait’;

+——+————+

| NAME | TIMER_NAME |

+——+————+

| wait | CYCLE      |

+——+————+

修改定时单位时间:

mysql> UPDATE setup_timers SET TIMER_NAME = ‘NANOSECOND’

    -> WHERE NAME = ‘wait’;

THREAD_ID,EVENT_ID:与事件波及的线程ID和目前风浪ID。THREAD_ID和EVENT_ID值构成了该事件音信行的唯壹标记(不会有重新的THREAD_ID+EVENT_ID值)

23.9.4.1 events_waits_current表

Events_waits_current表包罗了近年来的等候时间,各类thread都有壹行显示当前thread的守候时间。Events_waits_current表能够运用truncate table。

Events_waits_current表列:

·         THREAD_ID,EVENT_ID
线程相关的风浪和线程当前事件号。那3个字段产生主键来标示一行。

·         END_EVENT_ID
当事件运维,那么些列为null,要是时光截至分配贰个事件号。

·         EVENT_NAME
转移事件的记录点名。

·         SOURCE
源代码文件名包含产惹事件的记录点代码地点。能够协理用来检查源代码。

·         TIMER_START,TIMER_END,TIMER_WAIT
事件的timing消息。时间单位为微秒。TIME福特Explorer_START,TIMER_END代表事件的发端和了结。TIMEEvoque_WAIT是事件的持续时间。要是事件尚无马到成功TIME中华V_END,TIMER_WAIT为null。要是记录点的timed=no那么那二个列都以null。

·         SPINS
对于能量信号量,是只自旋次数。要是为null,表示代码不应用自旋或许自旋未有被记录。

·        
OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE_OBJECT_INSTANCE_BEGIN
那些列表示对象被运转的岗位,遵照目的类型区别含义不相同:
对此联合对象:(cond,mutex,rwlock)

§  OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE为null

§  OBJECT_INSTANCE_BEGIN为共同对象在内存中的地址。

对于文本io对象

§  OBJECT_SCHEMA为null

§  OBJECT_NAME为文件名

§  OBJECT_TYPE为file

§  OBJECT_INSTANCE_BEGIN为内存地址

对于socket对象

§  OBJECT_NAME为IP:PORT

§  OBJECT_INSTANCE_BEGIN为内部存款和储蓄器地址

对于表io对象

§  OBJECT_SCHEMA是表所在schema的名字

§  OBJECT_NAME表名

§  OBJECT_TYPE为table或者temporary table

§  OBJECT_INSTANCE_BEGIN是内部存款和储蓄器地址

OBJECT_INSTANCE_BEGIN本身是平素不意义的,除非差异的值表示不一样的对象。OBJECT_INSTANCE_BEGIN可以用来调度。比方group by那个字段查看是不是有一千个信号量,产生某个瓶颈。

·         INDEX_NAME
动用的index名字,primary表示表的主键索引,null表示从没索引

·         NESTING_EVENT_ID
event_id表示丰裕event被嵌套

·         NESTING_EVENT_TYPE
嵌套的事件培养和演练,大概是以下一种,TRANSACTION,STATEMENT,STAGE,WAIT

·         OPERATION
实践操作的连串,lock,read,write中3个。

·         NUMBER_OF_BYTES
读写操作的字节个数。对于表io等待,MySQL 5.柒.伍以前值为null,之后为行数。假诺值大于一,是批量io操作。MySQL试行join是nested-loop机制。品质框架能够提供行数和种种表推行join正确的时刻。假若2个join查询,试行如下:

SELECT … FROM t1 JOIN t2 ON … JOIN t3 ON …

在join操作的时候表的表行的加多减弱(扇出)。要是t三的扇出超越1,那么大大多行获得操作就来自于这些表。假诺t1 10行,t二 20行对应到t1壹行,t叁 30行对应t贰 1行。那么一共会有被记录的操作是:

10 + (10 * 20) + (10 * 20 * 30) = 6210

为了减弱被记录操作,能够透过每回扫描落成聚合的艺术(聚合t壹,t二的绝无仅有值)。记录点计数减少为:

10 + (10 * 20) + (10 * 20) = 410

对于地方的意况使用条件:

§  查询访问的表基本上都是inner join的

§  查询推行不须要表内的单个记录

§  查询施行不供给评估子查询访问了表。

·         FLAGS
保留

END_EVENT_ID:当3个风浪正在实践时该列值为NULL,当一个事件施行完结时把该事件的ID更新到该列

23.9.4.2 Events_waits_history表

Events_waits_history表每一个线程包罗了多年来N条数据。表结交涉events_waits_current一行,也能够被truncate table,N是服务运维自动安装的,也足以从参数设置:
performance_schema_events_waits_history_size。

EVENT_NAME:产生事件的instruments名称。该名称来自setup_instruments表的NAME字段值

23.9.4.3 events_waits_history_long 表

Events_waits_history_long表每一个线程包涵了近年N条数据。表结商谈events_waits_current壹行,也能够被truncate table,N是服务运维自动安装的,也得以从参数设置:
performance_schema_events_waits_history_long_size。

SOUBMWX五CE:发生该事件的instruments所在的源文件名称以及检验到该事件发生点的代码行号。您能够查看源代码来规定涉及的代码。比方,假如互斥锁、锁被打断,您能够检查发生那种情况的上下文碰着

2三.九.5 品质框架Stage事件表

品质框架stage记录,是语句施行的等第,比方解析语句,打开表大概实行filesort操作。Stage关联到的了show
processlist中的线程状态。

因为事件品级,等待事件穿插在stage事件,stage事件穿插在语句事件,事务事件。

Stage事件配置

初阶stage事件的征集,运营相应的记录点和买主。

Setup_instruments表包括以stage初始的记录点名。那个记录点除了说话管理的音信,暗许是禁止使用的:

mysql> SELECT * FROM setup_instruments WHERE NAME RLIKE
‘stage/sql/[a-c]’;

+—————————————————-+———+——-+

| NAME                                               | ENABLED | TIMED |

+—————————————————-+———+——-+

| stage/sql/After create                             | NO      | NO    |

| stage/sql/allocating local table                   | NO      | NO    |

| stage/sql/altering table                           | NO      | NO    |

| stage/sql/committing alter table to storage engine | NO      | NO    |

| stage/sql/Changing master                          | NO      | NO    |

| stage/sql/Checking master version                  | NO      | NO    |

| stage/sql/checking permissions                     | NO      | NO    |

| stage/sql/checking privileges on cached query      | NO      | NO    |

| stage/sql/checking query cache for query           | NO      | NO    |

| stage/sql/cleaning up                              | NO      | NO    |

| stage/sql/closing tables                           | NO      | NO    |

| stage/sql/Connecting to master                     | NO      | NO    |

| stage/sql/converting HEAP to MyISAM                | NO      | NO    |

| stage/sql/Copying to group table                   | NO      | NO    |

| stage/sql/Copying to tmp table                     | NO      | NO    |

| stage/sql/copy to tmp table                        | NO      | NO    |

| stage/sql/Creating sort index                      | NO      | NO    |

| stage/sql/creating table                           | NO      | NO    |

| stage/sql/Creating tmp table                       | NO      | NO    |

+—————————————————-+———+——-+

修改stage事件,修改enabled和timing列:

mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'

    -> WHERE NAME = 'stage/sql/altering table';

Setup_consumers表包含消费者只涉及的事件表名。消费者或许用来过滤搜罗器stage事件。Stage消费者暗中同意禁止使用:

mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%stages%';

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

| NAME                       | ENABLED |

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

| events_stages_current      | NO      |

| events_stages_history      | NO      |

| events_stages_history_long | NO      |

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

启航全体的stage事件:

mysql> UPDATE setup_consumers SET ENABLED = 'YES'

    -> WHERE NAME LIKE '%stages%';

Setup_timers包含name=‘stage’,说明stage事件timing:

mysql> SELECT * FROM setup_timers WHERE NAME = 'stage';

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

| NAME  | TIMER_NAME |

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

| stage | NANOSECOND |

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

修改timing值:

mysql> UPDATE setup_timers SET TIMER_NAME = ‘MICROSECOND’

    -> WHERE NAME = ‘stage’;

Stage事件进度音讯

MySQL 5.7.5,性能架构stage事件表包罗贰列,每行提供stage进度标示:

·           WORK_COMPLETED:stage专门的学业单元实现个数。

·           WORK_ESTIMATED:预期的stage工作单元达成个数。

假若未有进程消息,每列都是null。质量框架提供二个器皿来存放那几个进程数据:

·           专门的工作单元,是一个量,随着推行时间的充实变大。

·           WORK_COMPLETED,四个或然多少个单元扩大三遍,重视于被记录代码

·           WORK_ESTIMATED,能够在stage司改,依照,被记录代码。

对此stage事件的快慢的记录能够实现以下任何表现:

·           未有进程记录点
本条是最常出现的,因为从没进程数据被提供,WO奥德赛K_COMPLETED和WORKESTIMATED都为bull

·           未有被绑定记录点
只有WORK_COMPLETED列有意义,WORAV4K_ESTIMATED列未有值,显示为0。
打开events_stages_current表监察和控制回话,监察和控制程序能够告诉有个别许work已经被实践,不过不明白几时能够终结,因为记录点未有提供。

·           绑定进度记录点
WORK_COMPLETED和WORK_ESTIMATED列都以有意义的。
速度标志符的品种适合于已经定义了成功临界的操作,例如表复制记录点。通过查询events_stages_current表来监督会话,监察和控制程序能够监察和控制全数落成比例的stage,通过测算WOHighlanderK_COMPLETED / WORK_ESTIMATED的比率。

stage/sql/copy to tmp table演示,进度标志符怎么着专门的职业。在试行alter table语句,那些记录点就很有用,并且会奉行十分长壹段时间。

TIMER_START,TIMER_END,TIMER_WAIT:事件的时刻新闻。单位微秒(万亿分之一秒)。
TIMERubicon_START和TIMER_END值表示事件开头和告竣作时间间。
TIME奇骏_WAIT是事件经过时间(即事件施行了多久)

23.9.5.1 events_stages_current表

Events_stages_current表包涵当前stage事件,每行2个线程线程当前气象监察和控制到的stage事件。

Events_stages_current表可以truncate
table。

表events_stages_current是events_stages_history和events_stages_history_long的基础。

Events_Stages_current列:

·         THREAD_ID,EVENT_ID
线程相关的风云和线程当前事件号。这二个字段产生主键来标示1行。

·         END_EVENT_ID
当事件运维,那一个列为null,假诺时间结束分配八个事件号。

·         EVENT_NAME
转变事件的笔录点名。

·         SOURCE
源代码文件名包蕴产生事件的记录点代码地点。能够协助用来检查源代码。

·         TIMER_START,TIMER_END,TIMER_WAIT
事件的timing音讯。时间单位为飞秒。TIME福特Explorer_START,TIMER_END表示事件的始发和终止。TIME汉兰达_WAIT是事件的持续时间。假如事件尚未完成TIME昂科雷_END,TIMER_WAIT为null。假若记录点的timed=no那么那二个列都以null。

·         WORK_COMPLETED,WORK_ESTIMATED
这么些列提供了stage进程消息,对于记录点已经用来生成那几个新闻。WO帕杰罗K_COMPLETED表示有微微工作单元已经被成功,WO纳瓦拉K_ESTIMATED表示有稍许办事单元推断的stage。

·         NESTING_EVENT_ID
EVENT_ID nested生成的风云。嵌套的event的stage事件日常是语句事件。

·         NESTING_EVENT_TYPE
嵌套事件类型,TRANSACTION,STATEMENT,STAGE,WAIT在那之中一个。

  • 假设事件未执行到位,则TIMETiguan_END为当前停车计时器时间值(当前些天子),TIMERubicon_WAIT为方今截至所经过的时日(TIME兰德奥迪Q7_END –
    TIMER_START)
  • 万一采撷该事件的instruments配置项TIMED =
    NO,则不会收罗事件的年华新闻,TIMEPRADO_START,TIMER_END和TIMER_WAIT在这种情景下均记录为NULL

23.9.5.2 events_stage_history表

Events_stages_history为每一种线程保留了N个记录,具体能够通过配备参数修改:

performance_schema_events_stages_history_size

SPINS:对于互斥量和自旋次数。如若该列值为NULL,则代表代码中一向不行使自旋也许说自旋没有被监察和控制起来

23.9.5.3 events_stage_history_long表

Events_stages_history_long为各样线程保留了N个记录,具体能够由此配备参数修改:

performance_schema_events_stages_history_long_size

OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE,OBJECT_INSTANCE_BEGIN:这么些列标志了1个正在被施行的对象,所以这一个列记录的音讯意义须求看对象是什么样品种,下边依照差异对象类型分别对那一个列的意思进行认证:

2三.九.陆 品质框架语句事件表

质量框架记录点语句施行。语句事件产生在高档别的事件,等待事件嵌套在stage事件中,stage事件嵌套在言语事件中,语句事件嵌套在作业事件中。

讲话事件配置

Setup_instruments表包涵记录点,以statement前缀的记录点。那几个记录点的默许值能够使用语句:

mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'statement/%';

能够透过以下语句修改:

mysql> UPDATE setup_instruments SET ENABLED = 'NO'

    -> WHERE NAME LIKE 'statement/com/%';

查看和退换timer:

mysql> SELECT * FROM setup_timers WHERE NAME = ‘statement’;

+———–+————+

| NAME      | TIMER_NAME |

+———–+————+

| statement | NANOSECOND |

+———–+————+

修改timer:

mysql> UPDATE setup_timers SET TIMER_NAME = ‘MICROSECOND’

    -> WHERE NAME = ‘statement’;

 

语句监视

语句监视初步于被呼吁的移位到具有移动结束。也正是服务遭逢客户端的第二个包,到变成重返响应。在MySQL
5.柒.贰事先,语句只会是尖端其他,举例在积累进度大概子查询不会被分离出来。

最后记录点名和劳动命令和sql语句关于:

·           关联到COM_xxx定义在mysql_com.h头文件和在sql/sql_parse.cc中处理,比如COM_PING和COM_QUIT,那么记录点名以statement/com开端,举例statement/com/ping和statement/com/ping。

·           SQL语句是用文件表示的。那么相关的命令行以statement/sql开头,举个例子statement/sql/delete和statement/sql/select。

有的记录点名表示万分的错误管理:

·           Statement/com/error,记录了服务收罗到的未绑定的音信。无法断定从客户端发送到服务端的命令。

·           Statement/sql/error,记录了sql语句分析错误。用来检查判断查询发送到客户端的丰裕。一个询问分析错误和查询施行错误差异

伸手能够因而以下水道获得:

·           二个指令只怕语句从客户端获取并发送

·           在replication slave,语句字符串从relay log读取。

·           从event scheduler获取事件。

请求的详细原来是不知情的,并且品质框架从呼吁的顺序获取特定的记录点名。

从客户端搜罗的央浼:

一.        当服务意识1个新的包在socket品级,多少个新的的语句以抽象的记录点名statement/abstract/new_packet开始。

二.        当服务读取包序号,获取接受的请求类型,品质框架获取记录点名。举个例子,请求是COM_PING包,那么记录点名会变成statement/com/ping。假如请求是COM_QUE帕杰罗Y包,知道是3个sql语句,可是不晓得具体的类别。这年会给3个华而不实的记录点名statement/abstract/query。

三.        假使请求的话语,文本早已读入到分析器。分析今后,那么纯粹的口舌类型已经知晓了,假设请求是一个插入语句,质量框架会再度定位记录点名statement/abstract/Query
to statement/sql/insert。

 

对于从复制的relay log上读取语句:

一.        语句在relay log中是以文件存款和储蓄的。未有互联网协议,所以statement/abstract
/new_packet不会被选拔,而是采用statement/abstract/realy_log。

2.        当语句被解析,正确的言辞类型被识破。比如insert语句,那么质量框架会再也搜索记录点名,statement/abstract/Query
to statement/sql/insert。

位置介绍的,只是依据语句的复制,对于基于行的复制,订阅表行处理能够被记录,然而relay
log中的行事件描述语句的并不会并发。

 

对此从事件调节器来的请求:

事件实行的笔录点名字为statement/scheduler/event。

事件体重的轩然大波试行记录点名使用statement/sql/*,不适用其余抽象记录点名。事件是1个囤积进度,并且存款和储蓄进程是预编写翻译在内存中的。那么在执行时就不会有分析,可是项目在试行时就通晓了。

在事变体内的讲话都是子句。举个例子叁个风云实行了三个insert语句,试行的轩然大波是上面。记录点使用statement/scheduler/event,并且insert是下属,使用statement/sql/insert记录点。

如此那般不单单是要开动statement/sql/*记录点,还要运转statement/abstract/*记录点。

在事先的五.7版本的,抽象记录点名用别样记录点替代的:

·           Statement/abstract/new_packet之前为statement/com/

·           Statement/abstract/query之前为statement/com/Query

·           Statement/abstract/relay_log之前为statement/rpl/relay_log

*
对于联合对象(cond,mutex,rwlock):

二三.九.7 质量框架事务表

属性框架事务记录点。在事变品级,等待事件嵌套stage事件,stage事件嵌套语句事件,语句事件嵌套事务事件。

 

业务事件配置

Setup_instruments包括的transaction的记录点:

mysql> SELECT * FROM setup_instruments WHERE NAME =
‘transaction’;

+————-+———+——-+

| NAME        | ENABLED | TIMED |

+————-+———+——-+

| transaction | NO      | NO    |

+————-+———+——-+

开发银行搜聚专业事件:

mysql> UPDATE setup_instruments SET ENABLED = ‘YES’, TIMED =
‘YES’

    -> WHERE NAME = ‘transaction’;

Setup_consumers表包涵transaction的买主:

mysql> SELECT * FROM setup_consumers WHERE NAME LIKE
‘%transactions%’;

+———————————-+———+

| NAME                             | ENABLED |

+———————————-+———+

| events_transactions_current      | NO      |

| events_transactions_history      | NO      |

| events_transactions_history_long | NO      |

+———————————-+———+

启航消费者:

mysql> UPDATE setup_consumers SET ENABLED = ‘YES’

    -> WHERE NAME LIKE ‘%transactions%’;

设置相关记录点:

mysql> SELECT * FROM setup_timers WHERE NAME = ‘transaction’;

+————-+————+

| NAME        | TIMER_NAME |

+————-+————+

| transaction | NANOSECOND |

+————-+————+

修改timer_name的值:

mysql> UPDATE setup_timers SET TIMER_NAME = ‘MICROSECOND’

    -> WHERE NAME = ‘transaction’;

 

作业绑定

在MySQL Server,使用以下语句展现运转专业:

START TRANSACTION | BEGIN | XA START | XA BEGIN

工作也能够隐式运维,当autocommit系统变量运转。当autocommit禁止使用,在起步新业务钱要出示的收尾上边三个业务。

COMMIT | ROLLBACK | XA COMMIT | XA ROLLBACK

实践DDL语句,事务会隐式提交

属性框架定义的作业绑定和劳务的很一般。事务的起步和平化解说也和劳动的业务状态十分:

·           对于显示运维的事情,事务events在start transaction后运维。

·           对于隐式运营的事体,事务事件在率先个语句施行的时候运维。

·           对于其余专门的工作,当推行commit,rollback事务甘休。

神秘的区别点:

·           质量框架中的事务事件,未有完全包括语句事件比如START
TRANSACTION,COMMIT,ROLLBACK语句。

·           语句假若运营在非实物引擎,那么连接的作业状态不会潜移默化。

 

思想政治工作记录点

三个概念的政工属性:

·           访问情势(read only,read write)

·           隔开等第

·           隐式或然展现

为了削减作业记录点并且保险搜集专门的学问数据是马到功成的,有意义的结果,全部事情都有访问情势,隔开分离等第,自动提交方式。

作业事件表使用3列来ACCESS_MODE,ISOLATION_LEVEL,AUTOCOMMIT记录。

思想政治工作记录点消费能够有很四种方法减弱,举个例子依据用户,账号,host,thread运营可能禁止使用事务减了点。

 

线程和嵌套事件

作业事件的顶头上司事件是起始化事务的轩然大波。对于展现事务运维,包涵START_TRANSACTION和commit and china,假诺是隐式事务,第3个语句运转职业。

突显的甘休专门的职业,COMMIT,ROLLBACK,或许DDL语句,隐式的交由业务。

 

作业和仓库储存进度

事务和积攒进程事件涉及如下:

·           存款和储蓄进程
存储进度操作独立的职业,2个囤积进度能够运行八个职业,并且2个专门的学业能够在蕴藏进程中运行和终止。假设在叁个业务中调用,3个积攒进度能够语句强制提交业务并且运行二个新的政工。

·           存款和储蓄函数
存款和储蓄函数可以限制展现可能隐式的事体提交和回滚。

·           触发器
触发器活动是语句的运动访问相关的表,所以触发器事件的上司事件激活它。

·           调治事件
事件体的说话调节事件产生2个新连接。

 

事务和savepoint

Savepoint语句以独立的口舌事件被记录。语句事件包罗SAVEPOINT,ROLLBACK
TO SAVEPOINT和RELEASE SAVEPOINT语句。

 

政工和谬误 业务中的错误和警示被记录在讲话事件中,然而不在相关的作业事件。

*
1)、OBJECT_SCHEMA,OBJECT_NAME和OBJECT_TYPE列值都为NULL

二叁.玖.捌 质量框架连接表

品质框架提供了连年的总结消息。当客户端连接,在三个一定的用户名和host下。品质框架为各样账号追踪连接。

·         Accounts:每个客户端账号的接连总计音信。

·         Hosts:每一种客户端hostname 的连天总计音信。

·         Users:各类客户端用户名的接连总计音信。

账号那里的乐趣是用户增进host。连接表有CUOdysseyRENT_CONNECTIONS和TOTAL_CONNECTIONS列追踪全部的接连。Accounts表有USE卡宴和HOST列追踪用户和host。Users和hosts表有USETiggo和HOST列,追踪用户依然host。

一旦客户端名user一,user二从hosta,hostb连接过来。品质框架追踪连接入选:

·         Accounts会有4条记录,user1/hosta,user1/hostb,user2/hosta,user2/host2.

·         Users表有2条记录,user1,user2

·         Host表有2条记录,hosta,hostb

当客户端连接,连接表中壹旦不设有这么的用户依旧host,那么就充实壹行不然就修改CUMuranoRENT_CONNECTIONS和TOTAL_CONNECTIONS列。

当客户端断开连接,品质框架减弱current_connecitons列。

品质框架也计数内部线程和用户会电话线程验证错误。对应的user和host为null。

各类连接表都能够truncate:

·         行借使是CU哈弗RENT_CONNECTIONS=0的就删除

·         如果>0,TOTAL_CONNECTIONS设置为CURRENT_CONNECTIONS。

·         连接合计表重视于连接表的值会被设为0.

*
2)、OBJECT_INSTANCE_BEGIN列是内部存款和储蓄器中同步对象的地点。OBJECT_INSTANCE_BEGIN除了不一致的值标志不一样的目的之外,其值本身没有趣。但OBJECT_INSTANCE_BEGIN值可用来调节和测试。举个例子,它能够与GROUP BY
OBJECT_INSTANCE_BEGIN子句一同利用来查阅一,000个互斥体(比方:珍视壹,000个页或数据块)上的负载是还是不是是均匀布满如故发生了一些瓶颈。假如在日记文件或任何调节和测试、品质工具中看看与该语句查看的结果中有同样的目的地址,那么,在您分析质量难题时,能够把那个语句查看到的音信与任何工具查看到的音信涉及起来。

23.九.9 质量框架连接属性表

具体看:

* 对于文本I/O对象:

二三.九.10 品质框架用户变量表

具体看:

*
1)、OBJECT_SCHEMA列值为NULL

二3.玖.1一 质量框架复制表

MySQL 5.7.2,质量框架提供了有关复制音信的表。和show slave
status的音讯类似:

·         Show slave status输出可以阅读进行检查,不过不可能用来编程使用。

·         查询结果能够保留到表中,用于分析,设置变量,大概在蕴藏进程上使用。

·         复制表提供了越来越好的确诊消息,对于二十拾贰线程slave操作,show slave status使用last_SQL_Errorno和last_sql_error字段报告拥有的协和器和行事线程的荒唐。所以唯有近来的谬误才具看得出。复制表会为种种线程上的荒谬保存音讯不会丢掉。

·         各个事业线程的摩登的业务在在复制表是可知的。然则show_slave_status。不可见。

·         开采熟知的性格框架接口能够扩大复制表提供更多的新闻。

复制表描述

品质框架提供一下和复制有关的表:

·         关于Slave连接到master的接连消息表:

§  Replication_connection_configuration:配置连接到master的参数。

§  Replication_connection_status:当前连日到master的情事。

·         关于slave事务应用的表

§  replication_applier_configuration:slave青海中华南理工业余大学学学程集团作应用的配置音信。

§  replication_applier_status:当前工作应用的图景。

·         关于钦命线程应用从master获取职业并实施的音信:

§  Replication_applier_status_by_coordinator:applier线程状态,在此之前叫replication_execute_status_by_coordinator。对于有四个work thread的复制有多个work thread和三个调治将养线程,对于单线程的这一个表为空。

§  Replication_applier_status_by_worker:工作线程应用状态。同上单线程复制表为空。

·         包含复制组成员音讯的表:

§  Replication_group_members:提供网络和组成员状态。

§  Replication_group_member_status:提供组成员的总括音讯和到场的作业。

复制表生命周期

属性框架在以下情状下写入复制表:

·           在施行change master to在此之前表为空。

·           在执行change master to之后。配置解说能够在表上开采。假若那一年未有活动的slave
线程,那么thread_id列为null,serivce_state的场合为off。

·           Start slave之后,没有thread_id字段不为空。线程为空闲大概活动service_status状态为on。线程连接到master
server,假使老是建立有个connecting值。

·           Stop slave之后,thread_id为null,并且service_State列值为off。

·           Stop slave恐怕thread碰着错误,表音信会被保留。

·           Replication_applier_Status_by_worker表唯有当slave操作在二十拾贰线程格局下为非空。假若slave_parallel_workers变量大于0,那么start
slave之后,行数和线程个数同样多。

SHOW SLAVE STATUS不再复制表中的音讯

Show slave status的音讯和复制表中的音讯不一致,因为那个表首如若面向GTID的复制。不是依赖文件名和岗位:

·           以下字段关于文件名和岗位的尚未保存:

Master_Log_File

Read_Master_Log_Pos

Relay_Log_File

Relay_Log_Pos

Relay_Master_Log_File

Exec_Master_Log_Pos

Until_Condition

Until_Log_File

Until_Log_Pos

·           Master_info_file字段未有保留。参照master.info文件。

·           以下字段基于server_id,不是server_uuid,未有被封存:

Master_Server_Id

Replicate_Ignore_Server_Ids

·           Skip_counter列依照事件个数,不是gtid未有被保存。

·           错误列是last_sql_errno,last_sql_error的小名,由此不被保留

Last_Errno

Last_Error

在质量框架中,replication_applier_status_by_coodinator和表replication _applier_status_by_worker中的last_error_number和last_error_message列保存了错误信息。

·           命令行过滤操作的音讯不被保存:

Replicate_Do_DB

Replicate_Ignore_DB

Replicate_Do_Table

Replicate_Ignore_Table

Replicate_Wild_Do_Table

Replicate_Wild_Ignore_Table

·           Slave_io_State和slave_sql_running_state列未有保存。要是急需能够由此thread_id关联上perocesslist表获取表中的status值。

·           Executed_gtid_set字段能够显得多量的文字。和总体性框架表中突显已经被slave应用的工作的GTID。已经被实践的GTID能够因此gtid_executed系统变量获取。

·           Seconds_behind_master和relay_log_spae用来将在被决定的状态不保留。

状态变量移动到了复制表

从mysql 5.柒.五,以下意况被挪动到了质量框架复制表:

Slave_retried_transactions

新葡萄京娱乐网站 ,Slave_last_heartbeat

Slave_received_heartbeats

Slave_heartbeat_period

Slave_running

这一个变量用于单源复制,因为只好反映默许源复制。当有四个复制源,能够使用质量复制表,汇报各类复制路子的状态。

多源复制

质量框架表的第二列是channel_name.可以见见各类复制源。

* 2)、OBJECT_NAME列是文本名

23.9.11.1 replication_connection_configure表

表呈现了连接到slave服务的连年配置。参数被封存在表中,在change
master实践的时候会被涂改。

replication_connection_configuration表包涵以下列:

·           CHANNEL_NAME:复制源名。

·           HOST:master的host名。

·           PORT:master的端口

·           USERAV4:连接用户

·           NETWORK_INTERFACE:slave绑定的network接口。

·           AUTO_POSITION:如若自定定位被运用了便是1,不然是0

·           SSL_ALLOWED, SSL_CA_FILE, SSL_CA_PATH,
SSL_CERTIFICATE, SSL_CIPHER, SSL_KEY,
SSL_VERIFY_SERVER_CERTIFICATE, SSL_CRL_FILE, SSL_CRL_PATH
那么些列突显了slave连接到master的SSL的参数SSL_ALLOWED的值如下:

§   Yes,如果SSL连接到master被允许。

§   No,尽管SSL连接到master不被允许。

§   Ignored,如果SSL被允许,但是slave不支持SSL。

Change master to选项还有任何ssl选项:MASTE昂科拉_SSL_CA, MASTER_SSL_CAPATH,
MASTER_SSL_CERT, MASTER_SSL_CIPHER, MASTER_SSL_CRL,
MASTER_SSL_CRLPATH, MASTER_SSL_KEY,
MASTER_SSL_VERIFY_SERVER_CERT。

·           CONNECTION_RETRY_INTE揽胜极光VAL:重试的秒数。

·           CONNECTION_RETRY_COUNT:失误连连之后重试的次数。

·           HEARTBEAT_INTELX570VAL:复制心跳间隔。

* 3)、OBJECT_TYPE列为FILE

23.9.11.2 replication_connection_status

表保存了io线程的状态,io线程连接到master服务获得binary log消息。

Replication_connection_status相关列:

·           CHANNEL_NAME:来源名。

·           GOURP_NAME:保留

·           SOURCE_UUID:master的server_uuid

·           THREAD_ID:io 线程id

·           SERVICE_STATE:服务情况

·           RECEIVED_TRANSACTION_SET:GTID群集反应已经被slave收到的GTID。

·           LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE:错误好和错误信息。

·           LAST_ERROR_TIMESTAMP:错误的风浪格式为YYMMDD HH:MM:SS。

·           LAST_HEARTBEAT_TIMESTAMP:如今三次心跳事件的风云。

·           COUNT_RECEIVED_HEARTBEATS:收到的心跳次数。

*
4)、OBJECT_INSTANCE_BEGIN列是内部存款和储蓄器中的地点,解释同上

23.9.11.3 replication_applier_configure

那个表呈现了震慑专业应用的配置参数。参数保存在表可以透过change
master to修改。

Replication_applier_configure表有以下列:

·           CHANNEL_NAME:复制来源名。

·           DIESIRED_DELAY:master到slave的延迟。

* 对于套接字对象:

23.9.11.4 replication_applier_status

表保存了slave常常事务实行的场地。

replication_aplier_status列名:

·           CHANNEL_NAME:复制来源名。

·           SERVICE_STATE:呈现on表示复制路子活动可能空闲,如若为off表示应用线程未有运动。

·           REMAINING_DELAY:如果slave等待DESIRED_DELAY直到master应用事件。列突显剩下的秒数。

·           COUNT_TRANSACTIONS_RETLX570IES:突显了sql thread应用职业错误,导致重试的次数。

* 1)、OBJECT_NAME列是套接字的IP:PORT值

23.9.11.5 replication_applier_status_by_coordinator

对此二十多线程的slave,slave使用三个办事线程和二个和睦线程,和谐线程用来管理专门的事业线程,表展现了和煦线程的动静。假诺是单线程slave,表为空。

Replication_applier_status_by_coordinator列:

·           CHANNEL_NAME:复制来源名。

·           THREAD_ID:SQL/协调线程id。

·           LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE:最终三次错误号和错误音信。

·           LAST_ERROR_TIMESTRAMP:时间戳格式为YYMMDD HH:MM:SS。

*
2)、OBJECT_INSTANCE_BEGIN列是内部存款和储蓄器中的地址,解释同上

23.9.11.6 replication_applier_statys_by_worker

对此三十二线程的slave,slave使用几个工作线程和3个协和线程,协调线程用来处监护人业线程,表展现了和睦线程的情形。如若是单线程slave,表为空。

Replication_applier_status_by_worker:

·           CHANNEL_NAME:复制来源名。

·           WORKER_ID:worker标志符。Stop
slave之后线程id会变成null,workerid会保留。

·           THREAD_ID:线程id

·           SERVICE_STATE:on,表示活动也许空闲,off代表不设有。

·           表示worker开采的新式的职业,假设gtid_mode=off列的值为ANONYMOUS。倘若为on:

§   借使未有专业被施行,那么正是空。

§   当有三个政工被施行了列设置成gtid_next。

§   GTID会被保留,知道下贰个业务运营成功。

§   当下2个GTID被此外线程获取,从gtid_next上获得。

·           LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE:最终二遍错误号和错误新闻。

·           LAST_ERROR_TIMESTRAMP:时间戳格式为YYMMDD HH:MM:SS。

* 对于表I/O对象:

23.9.11.7 replication_group_members

表保存了互连网和复制成员组的动静新闻。Replication_group_members列:

·           CHANNEL_NAME:复制来源名。

·           MEMBER_ID:member标示,和uuid一样。

·           MEMBER_HOST:host地址只怕主机名。

·           MEMBER_PORT:端口。

·           MEMBER_STATE:

§   OFFLINE:group replication插件已经设置可是并未有运行。

§   RECOVE福特ExplorerING:服务已经进入到一个group,正在获取数据。

§   ONLINE:成员在全职能状态。

* 1)、OBJECT_SCHEMA列是富含该表的库名称

23.9.11.8 replication_group_member_status

表保存了replication group成员的景况,replication_group_member_status:

·           CHANNEL_NAME:复制来源名。

·           VIEW_ID:该group的眼下的view标示符。

·           MEMBER_ID:member标示,和uuid一样。

·           COUNT_TRANSACTIONS_IN_QUEUE:pending事务的个数。

·           COUNT_TRANSACTIONS_CHECKED:已经被成员证实的业务个数。

·           COUNT_CONFLICTS_DETECTED:争辩开掘个数。

·           COUNT_TRANSACTIONS_VALIDATING:事务能够进行检查,可是未有被回收的个数。

·           TRANSACTIONS_COMMITTED_ALL_MEMBEHummerH二S:固化的group事务会集。

·           LAST_CONFLICT_FREE_TRANSACTION:最后2个从未有过争执的被验证的思想政治工作。

* 2)、OBJECT_NAME列是表名

23.9.1二 品质框架锁相关表

*
3)、OBJECT_TYPE列值对于基表或然TEMPORA昂科威Y
TABLE权且表,该值是table,注意:对于在join查询中select_type为DE本田UR-VIVED,subquery等的表恐怕不记录事件消息也不实行总结

23.9.12.1 metadata_locks

性情框架把元数据锁通过metadata_locks展现。展现一下音讯:

·         锁已经被分配

·         锁被呼吁不过并未有被分配。

·         锁请求但是被死锁kill大概锁等待超时而被裁撤。

那一个音信能够掌握元数据锁和对话之间的涉嫌。能够查看等待的锁,也得以查阅已经获取的锁。

Metadata_locks表只读,无法写入。暗许是自动大小的,也足以经过运营参数配置高低:performance_schema_max_metadata_locks。

表暗许是被剥夺的,拖过设置setup_instruments的/locl/metadata/sql/mdl来启动。

品质框架爱慕内容,使用lock_status表示锁的境况:

·         当元数据锁被呼吁并且即刻得到,行的气象的是GRANTED。

·         当元数据锁被呼吁可是未有马上得到,行的景况为pending。

·         当从前请求的元数据锁获取了,行的景况改为granted。

·         当元数据锁被保释,行被删除。

·         当pending的锁请求被死锁开采器撤除,状态改为victim。

·         当pending的锁超时,状态成为pending to timeout。

·         当分配的锁恐怕pending的锁被kill,状态变成killed。

·         当VICTIM,TIMEOUT,KILLED被通报现在行会被删去。

·         PRE_ACQUIRE_NOTIFY,POST_RELEASE_NOTIFY状态,当获得锁大概释放锁时,lock子系统通报所在的蕴藏引擎的情形。

Metadata_locks列:

·         OBJECT_TYPE:能够是那个值的内部二个.
GLOBAL, SCHEMA, TABLE, FUNCTION, PROCEDURE, T福特ExplorerIGGEOdyssey (currently unused),
EVENT, COMMIT, USEHighlander LEVEL LOCK, TABLESPACE, LOCKING SELacrosseVICE。
万1值为USE索罗德 LEVEL LOCK表示从get_lock()获取锁,借使是LOCKING SEQX56VICE表示使用lock service获取说。

·         OBJECT_SCHEMA:对象所在的schema

·         OBJECT_NAME:对象名

·         OBJECT_INSTANCE_BEGIN:记录点对象在内部存款和储蓄器中的地址。

·         LOCK_TYPE:锁的类型,INTENTION_EXCLUSIVE, SHARED,
SHARED_HIGH_PRIO, SHARED_READ, SHARED_WRITE, SHARED_UPGRADABLE,
SHARED_NO_WRITE, SHARED_NO_READ_WRITE, or EXCLUSIVE.

·         LOCK_DURATION:lock持续的年限。能够是那些值STATEMENT, TRANSACTION,
EXPLICIT. STATEMENT 和TRANSACTION从言语也许业务的初叶直到语句恐怕工作的利落。

·         LOCK_STATUS:锁的景况,PENDING,
GRANTED, VICTIM, TIMEOUT, KILLED, PRE_ACQUIRE_NOTIFY,
POST_RELEASE_NOTIFY.

·         SOUCE:源代码文件中的文件名和岗位。

·         OWNER_THREAD_ID:请求元数据的线程。

·         OWNER_EVENT_ID:请求锁的事件id。

*
4)、OBJECT_INSTANCE_BEGIN列是内存中的地点,解释同上

23.9.12.2 table_handles

通过表table_handles重回表锁音讯。Table_handle展现了各样展开表的handle的锁音讯。那么些表被展开了,怎么样被锁定的,是哪位线程锁的。

Table_handles是只读表,无法改改,表列如下:

·         OBJECT_TYPE:被table handle张开的表。

·         OBJECT_SCHEMA:表所在的schema。

·         OBJECT_NAME:记录点对象名。

·         OBJECT_INSTANCE_BEGIN:记录点对象在内部存款和储蓄器中的地址。

·         OWNER_THREAD_ID:请求元数据的线程。

·         OWNER_EVENT_ID:请求锁的轩然大波id。

·         INTERNAL_LOCK:SQL等第使用的表锁。值如下: READ, READ WITH SHARED
LOCKS, READ HIGH PCRUISERIO大切诺基ITY, READ NO INSERT, W奥迪Q5ITE ALLOW W卡宴ITE, WTiguanITE
CONCU纳瓦拉RENT INSERT, W昂科威ITE LOW PBMWX五IOCRUISERITY, WKugaITE。

·         EXTERNAL_LOCK:存款和储蓄引擎等级使用的表锁,READ EXTE福睿斯NAL ,W帕杰罗ITE
EXTE路虎极光NAL

 

INDEX_NAME:表示使用的目录的名号。P本田UR-VIMAENCOREY表示使用到了主键。 NULL代表不曾应用索引

贰3.玖.一3 品质框架种类变量表

MySQL维护了很多系统变量,系统变量在那么些表是可用的:

·           Global_variables:全局系统变量。即便应用程序只要全局值能够利用这一个表。

·           Session_variables:当前对话的种类变量。还有未有session变量部分的global变量

·           Variables_by_thread:每个会话的系统变量。

那一个会话等级的变量只含有了移动会话的变量。这一个表不帮衬truncate
table。

Global_variablees和session_variables表有那么些列:

·           VARIABLES_NAME:变量名

·           VARIABLES_VALUE:变量的值。

Variables_by_thread的列:

·           Thread_id:线程id

·           VARIABLES_NAME:变量名

·           VARIABLES_VALUE:变量的值。

Variables_by_thread表包括了后台线程的种类变量消息。若是还是不是负有的线程记录,那么表内某个行会小时。这年Performance_schema_thread_instance_lost状态变量大于0 。

NESTING_EVENT_ID:表示该行消息中的EVENT_ID事件是嵌套在哪些事件中,即父事件的EVENT_ID

贰三.玖.1四 质量框架种类状态变量表

和体系变量表类似,具体看:

NESTING_EVENT_TYPE:表示该行消息中的EVENT_ID事件嵌套的风云类型。有效值有:TRANSACTION,STATEMENT,STAGE或WAIT,即父事件的事件类型,假若为TRANSACTION则须求到业务事件表中找对应NESTING_EVENT_ID值的风浪,其余体系同理

2三.九.15 品质框架总括表

等候事件总结表:

·           Events_waits_summary_global_by_event_name:等待事件依照每个事件展开斟酌。

·           Events_waits_summary_by_instance:等待事件根据各种instance实行计算。

·           Events_waits_summary_by_thread_by_event_name:依照线程和事件名合计的表。

Stage统计表:

·           Events_stages_summary_by_thread_by_event_name:stage等待和线程id计算的表。

·           Events_stages_summary_global_by_eevnt_name:stage等待中每种事件名的总计表。

语句总结表:

·           Events_statements_summary_by_digest:每种schema和digest后的总结表。

·          
Events_statements_summary_by_thread_by_event_name:语句事件名和线程的计算表。

·           Events_statements_summary_global_by_event_name:每种语句事件名的总计表。

·           Events_statements_summary_by_program:各种存款和储蓄程序的计算(存款和储蓄进程和储存函数)。

·           Prepared_statements_instances:预备的口舌实例和总结音讯。

作业计算表:

·          
Events_transactions_summary_by_account_by_event_name:各样账号发起的风浪总括。

·          
Events_transactions_summary_by_host_by_event_name:每种host发起的政工事件总结。

·          
Events_transactions_summary_by_thread_by_event_name:每个线程发起的业务事件总计。

·          
Events_transactions_summary_by_user_by_event_name:每一种用户发起的事体育赛事件总计。

·           Events_transactions_summary_global_by_event_name:事务事件名总计。

对象等待总计:

·           Objects_summary_global_by_type:对象合计。

文件IO统计:

·           File_summary_by_event_name:合计具有文件io事件名。

·           File_summary_by_instance:每一种文件实例的说道。

表IO和锁等待总结:

·           Table_io_waits_summary_by_index_usage:每种具有的表io等待。

·           Table_io_waits_summary_by_table:每一个表的io等待。

·           Table_io_waits_summary_by_table:每一种表的锁等待。

老是总结:

·           Events_waits_summary_by_account_by_event_name:每一个账号发起的等待事件计算。

·           Events_waits_summary_by_user_by_event_name:每一个用户发起的等候事件总计。

·           Events_waits_summary_by_host_by_event_name:每一种host发起的等候事件合计。

·           Events_stages_summary_by_account_by_event_name:各个账号stage事件总计。

·           Events_stages_summary_by_user_by_event_nam:各类用户发起的stage事件总括。

·           Events_stages_summary_by_ host_by_event_name:各个host发起的stage事件合计。

·           Events_statements_summary_by_digest:各种schema下的装有digest。

·           Events_statements_summary_account_by_event_name:种种账号发起的语句事件。

·           Events_statements_summary_by_user_by_event_name:每一个用户发起的言语事件。

·           Events_statements_summary_host_by_event_name:每一个host发起的讲话事件。

Socket统计:

·           Socket_summary_by_instance:每一种实例的socket等待和io合计。

·           Socket_summary_by_event_name:socket等待和io合计。

内部存款和储蓄器统计:

·           Memory_summary_global_by_event_name:内部存储器操作事件合计。

·           Memory_summary_by_thead_by_event_name:每一种线程内部存款和储蓄器操作合计。

·           Memory_summary_by_account_by_event_name:各个账号内部存款和储蓄器操作合计。

·           Memory_summary_by_user_by_event_name:每一种用户内存操作合计。

·           Memory_summary_by_host_by_event_name:各样host内部存款和储蓄器操作家组织议。

状态变量计算:

·           Status_by_account:状态变量账号合计。

·           Status_by_host:状态变量host合计

·           Status_by_user:状态变量用户协商

OPERATION:实施的操作类型,如:lock、read、write、timed_wait

二三.玖.16 质量框架别的表

除却上边你的表还有三个表:

·           Host_cache:内部host cache信息。

·           Performance_timers:事件可用放大计时器。

·           Threads:服务的线程表。

NUMBER_OF_BYTES:操作读取或写入的字节数或行数。对于文本IO等待,该列值表示字节数;对于表I/O等待(wait/io/table/sql/handler
instruments的轩然大波),该列值表示行数。要是值超过壹,则代表该事件对应一个批量I/O操作。以下分别对单个表IO和批量表IO的分别实行描述:

二3.十 质量框架选项和变量

具体看:

  • MySQL的join查询利用嵌套循环达成。performance_schema
    instruments的作用是在join查询中提供对各类表的扫视行数和施行时间开始展览总括。示例:join查询语句:SELECT
    … FROM t一 JOIN t贰 ON … JOIN t叁 ON …,假使join顺序是t壹,t2,t三
  • 在join查询中,叁个表在询问时与任何表张开联合查询以后,该表的扫视行数大概扩展也可能缩减,比方:假设t三表扇出超乎1,则大多数row
    fetch操作都以针对t三表,假诺join查询从t一表访问十行记录,然后利用t1表驱动查询t2表,t一表的每1行都会扫描t二表的20行记录,然后选取t二表驱动查询t3表,t二表的每一行都会扫描t3表的30行记录,那么,在选取单行输出时,instruments计算操作的轩然大波信息总行数为:10+(10 * 20)+(10 * 20 * 30)= 6210
  • 由此对表中央银行扫描时的instruments总括操作实行联谊(即,每一个t壹和t贰的扫描行数在instruments计算中能够算作贰个批量结缘),那样就足以减小instruments总括操作的多寡。通过批量I/O输出格局,performance_schema每便对最内层表t三的围观减弱为三个风云总结消息而不是每1行扫描都生成一个轩然大波音信,此时对于instruments计算操作的风浪行数量减小到:十+(十 * 20)+(10 * 20)=
    四拾,那样在该join查询中对此performance_schema中的行总计操作就收缩了九三%,批量出口战略通过压缩输骑行数量来显着下降表I/O的performance_schema计算花费。可是相对于每行数据都单身施行统计操作,会损失对时间总结的正确度。在join查询中,批量I/O总结的流年包含用于连接缓冲、聚合和重返行到客户端的操作所消费的岁月(即正是整整join语句的实施时间)

二三.1一 品质框架命令选项

具体看:

 

FLAGS:留作以后接纳

二三.1二 质量框架连串变量

具体看:

PS:events_waits_current表允许行使TRUNCATE TABLE语句

二三.一三 品质框架状态变量

具体看:

events_waits_history 表

23.1肆 品质框架内存分配模型

在mysql 伍.7.陆以前,质量框架使用以下内部存款和储蓄器分配模型:

·         全部的内部存款和储蓄器在运转时分配。

·         服务操作的时候不分配内部存储器。

·         服务操作的时候不自由内部存款和储蓄器。

·         在劳动关闭的时候释放内部存款和储蓄器。

动用这么些模型,性能框架会分配大量的内部存款和储蓄器,除非展现的布署。Mysql
5.7.陆之后的分配模型:

·         能够在劳动运营的时候分配。

·         能够在劳动操作的时候额外分配。

·         在劳务操作的时候不自由。

·         在劳务关闭的时候释放内部存款和储蓄器。

那般能够依据负荷来调动内部存款和储蓄器使用,不是现实性配置。

有一些品质框架配置参数是半自动分配,也得以手动分配:

performance_schema_accounts_size
performance_schema_hosts_size
performance_schema_max_cond_instances
performance_schema_max_file_instances
performance_schema_max_index_stat
performance_schema_max_metadata_locks
performance_schema_max_mutex_instances
performance_schema_max_prepared_statements_instances
performance_schema_max_program_instances
performance_schema_max_rwlock_instances
performance_schema_max_socket_instances
performance_schema_max_table_handles
performance_schema_max_table_instances
performance_schema_max_table_lock_stat
performance_schema_max_thread_instances
performance_schema_users_size

对此电动配置的参数,配置基本如下:

·         假设为-壹,暗中认可,参数是电动配置的。

§  开首对应的中间buffer为空,未有内部存款和储蓄器。

§  当品质框架伊始收罗数据,没存被分配到想要的buffer。buffer大小未有上限,随着负荷上涨回涨。

·         假设设置为0:

§  初阶内部buffer为空,也不会分配内部存储器。

·         倘诺设置的N>0:

§  对象的在那之中buffer为空,并且不分配内部存款和储蓄器。

§  当数据初叶征集,内部存储器初叶分配,直到设置的分寸。

§  1旦buffer大小达到N,内部存款和储蓄器就不再分配。品质框架搜聚的数据会丢掉,对应的状态变量的lost
instance会增加。

为了查看品质框架使用了多少内部存款和储蓄器,检查记录点。质量框架搜罗了各类buffer的内部存款和储蓄器使用音信。那样能够追踪种种buffer的内部存款和储蓄器使用处境。记录点,memory/performance
_schema/。因为那些buffer是大局的,所以只在memory_summary_global_by_event_
name上显得。查询如下:

SELECT * FROM memory_summary_global_by_event_name WHERE
EVENT_NAME LIKE ‘memory/performance_schema/%’;

events_waits_history表包涵各样线程近来的N个等待事件。
在server运维时,N的值会自动调节。
借使要显式设置那一个N大小,能够在server运行在此之前调节系统参数performance_schema_events_waits_history_size的值。
等待事件需要举行达成时才被增加到events_waits_history表中(未有落成时保留在events_waits_current表)。当增多新事件到events_waits_history表时,若是该表已满,则会遗弃每一种线程较旧的风云

二三.1伍 质量框架和

具体看:

events_waits_history与events_waits_current表定义一样

贰三.1陆 使用品质框架检查判断

特性框架能够让dba来做一些性质调治,比方多少个重复出现的属性难点:

一.周转用例

2.使用质量框架表,分析根本的属性难点。分析严重依赖于post过滤。

三.标题区域已经划出,禁用对应的记录点。比如假若条分缕析出和文书io不相关,禁止使用io的记录点。

4.重复 步骤一-3,那样能够削减困扰搜索真正的标题。

伍.显眼了质量瓶颈的来头:

§  调节服务参数

§  调治查询。

§  调节数据库结构

§  调度代码。

六.重复步骤壹,查看对品质的熏陶。

在质量调优的时候,mutex_instances.locked_by_thread_id,rwlock_instances.
write_locked_by_thread_id列非凡根本。比如:

一.线程壹,在守候二个频域信号量。

2.能够应用以下语句查看等待的时域信号量:

SELECT * FROM events_waits_current WHERE THREAD_ID =
thread_1;

三.然后翻看那几个线程持有着这些随机信号量:

SELECT * FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN =
mutex_A;

4.查看线程二在做哪些:

SELECT * FROM events_waits_current WHERE THREAD_ID =
thread_2;

PS:允许实践TRUNCATE TABLE语句

23.17 迁移到品质框架连串和气象变量表

Information_schema有表包蕴了系统和状态变量音讯,MySQL 5.柒.6现在,品质框架也蕴藏了系统变量和状态变量新闻。质量框架的表会替代information_schema上的表。

在mysql 五.陆翻看状态变量和系统变量来自于:

SHOW VARIABLES
SHOW STATUS

 

INFORMATION_SCHEMA.GLOBAL_VARIABLES
INFORMATION_SCHEMA.SESSION_VARIABLES

INFORMATION_SCHEMA.GLOBAL_STATUS
INFORMATION_SCHEMA.SESSION_STATUS

Mysql 5.七.陆,质量框架也含有了系统变量和状态变量:

performance_schema.global_variables
performance_schema.session_variables
performance_schema.variables_by_thread

performance_schema.global_status
performance_schema.session_status
performance_schema.status_by_thread
performance_schema.status_by_account
performance_schema.status_by_host
performance_schema.status_by_user

MySQL 5.7.6增加了show_compatibility_5陆系统变量,假如为on:

·         当从information_schema中输出,会现出警示。

·         在mysql 伍.7.陆,使用show的where语句就会警告。MySQL 5.七.八过后就不会。

当变量为off,不运转包容方式:

·         搜索information_schema表会报错。

·         Show语句输出的数量来至于品质框架表。

·         这些slave_XXX的状态变量不可用:

Slave_heartbeat_period
Slave_last_heartbeat
Slave_received_heartbeats
Slave_retried_transactions
Slave_running

       应该从性质框架的复制相关的表中获取数据。

 

搬迁和权杖

走访品质框架中的系统变量和状态变量要求select权限。如果show_compatibility_5陆为off,那么show
variables和show status也须求select权限,如果包容性关闭,那几个语句输出来至于质量框架的global_variables,session_variables,global_status,
session_status表。

在mysql 五.七.九,这么些表在性质矿建中访问不必要select权限。对应的show variables和show status也不需求权限。

以往的公布,information_schema变量表和show_compatibility_56会被删除,show输出基于品质框架表。

 

 

Reference Manual] 23 Performance
Schema结构,manualschema 二3 MySQL Performance Schema 二三 MySQL
Performance Schema .. 一 23.一 品质框架急速运维 … 3 二叁.2质量框架…

events_waits_history_long 表

events_waits_history_long表包涵近来的N个等待事件(全数线程的风浪)。在server运营时,N的值会自动调解。
假若要显式设置那一个N大小,能够在server运维在此以前调度系统参数

performance_schema_events_waits_history_long_size的值。等待事件供给进行落成时才会被增多到events_waits_history_long表中(未有终结时保留在events_waits_current表),当加多新事件到events_waits_history_long表时,假诺该表已满,则会屏弃该表中较旧的轩然大波。

events_waits_history_long与events_waits_current表结构同样

PS:允许利用TRUNCATE TABLE语句

等第事件表

等第事件记录表与等待事件记录表同样,也有三张表,那么些表记录了脚下与近日在MySQL实例中爆发了什么阶段事件,时间消耗是稍微。阶段指的是语句试行进程中的步骤,举个例子:parsing
、opening tables、filesort操作等。

在既往大家查阅语句施行的品级状态,平日使用SHOW
PROCESSLIST语句或询问INFO奔驰G级MATION_SCHEMA.PROCESSLIST表来获得,但processlist格局能够查询到的音信相比有限且时而即逝,大家常常必要组合profiling成效来一发总结分析语句推行的逐1阶段的付出等,未来,我们不须求那样劳顿,直接行使performance_schema的等第事件就既能够查询到具有的语句实践等第,也得以查询到各样阶段对应的成本,因为是记录在表中,所以更能够动用SQL语句对这个多少开始展览排序、总结等操作

要注意:阶段事件有关安插中,setup_instruments表中stage/开始的大部instruments配置暗中同意未有展开(少数stage/发轫的instruments除了这一个之外,如DDL语句实行进度的stage/innodb/alter*千帆竞发的instruments暗许开启的),setup_consumers表中stages相关的consumers配置暗中认可未有拉开

events_stages_current 表

events_stages_current表包含当前阶段事件的督察音讯,每一种线程一行记录突显线程正在奉行的stage事件的状态

在蕴藏stage事件记录的表中,events_stages_current是基准表,包括stage事件记录的别的表(如:events_stages_history和events_stages_history_long表)的数量在逻辑上都源于events_stages_current表(汇总表除却)

表记录内容示例(以下照旧是1个执行select
sleep(100);语句的线程,但那里是阶段事件新闻)

root@localhost : performance _schema 12:24:40> select * from
events_stages _current where EVENT_NAME=’stage/sql/User sleep’G;

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

THREAD_ID: 46

EVENT_ID: 280

END _EVENT_ID: NULL

EVENT_NAME: stage/sql/User sleep

SOURCE: item_func.cc:6056

TIMER_START: 14645080545642000

TIMER_END: 14698320697396000

TIMER_WAIT: 53240151754000

WORK_COMPLETED: NULL

WORK_ESTIMATED: NULL

NESTING _EVENT_ID: 266

NESTING _EVENT_TYPE: STATEMENT

1 row in set (0.00 sec)

如上的出口结果与话语的等候事件格局类似,那里不再赘述,events_stages_current表完整的字段含义如下

THREAD_ID,EVENT_ID:与事件波及的线程ID和脚下风云ID,能够利用THREAD_ID和EVENT_ID列值来唯壹标志该行,那两行的值作为整合条件时不会油不过生同等的数据行

END_EVENT_ID:当三个风云初始施行时,对应行记录的该列值被设置为NULL,当2个事件施行实现时,对应的行记录的该列值被更新为该事件的ID

EVENT_NAME:产滋事件的instruments的称呼。该列值来自setup_instruments表的NAME值。instruments名称也许拥有多少个部分并产生档案的次序结构,如:”stage/sql/Slave has read all relay log;
waiting for more updates”,在那之中stage是头号名称,sql是二级名称,Slave has read all relay log; waiting for more
updates是第一级称号。详见链接:

SOU猎豹CS6CE:源文件的称号及其用于检查实验该事件的代码位于源文件中的行号

TIMER_START,TIMER_END,TIMER_WAIT:事件的时刻音讯。那个值的单位是皮秒(万亿分之一秒)。TIMELAND_START和TIMER_END值表示事件的开端时间和得了时间。TIME路虎极光_WAIT是事件实施消耗的大运(持续时间)

  • 假诺事件未实行到位,则TIME兰德奔驰G级_END为当下时刻,TIMEEvoque_WAIT为日前了却所经过的日子(TIMEKoleos_END –
    TIMER_START)
  • 如果instruments配置表setup_instruments中对应的instruments
    的TIMED字段棉被服装置为
    NO,则该instruments禁止使用时间采访功用,那么事件采访的音讯记录中,TIMEENVISION_START,TIMER_END和TIMER_WAIT字段值均为NULL

WORK_COMPLETED,WORK_ESTIMATED:这么些列提供了阶段事件进程消息

  • 表中的WORK_COMPLETED和WORK_ESTIMATED两列,它们一齐同盟显示每一行的快慢呈现:

*
1)、WORK_COMPLETED:彰显阶段事件已到位的做事单元数

*
2)、WORK_ESTIMATED:彰显推测阶段事件就要实现的劳作单元数

  • 倘使instruments未有提供进度相关的职能,则该instruments推行事件采访时就不会有速度音讯展现,WO揽胜K_COMPLETED和WORK_ESTIMATED列都会彰显为NULL。如果进程音讯可用,则进程音信怎样体现取决于instruments的推行情况。performance_schema表提供了三个囤积进程数据的器皿,但不会假如你会定义何种衡量单位来选拔这么些进程数据:

*
1)、“专门的学业单元”是在进行进程中随时间扩充而扩大的平头衡量,比方试行进度中的字节数、行数、文件数或表数。对于特定instruments的“职业单元”的概念留给提供数据的instruments代码

*
2)、WORK_COMPLETED值根据检查评定的代码差异,能够3回扩大二个或三个单元

*
3)、WORK_ESTIMATED值依据检验代码,大概在等级事件施行进度中发生变化

  • 品级事件进程提醒器的显现作为有以下两种景况:

*
一)、instruments不支持进程:未有可用进程数据,
WORAV4K_COMPLETED和WORK_ESTIMATED列都呈现为NULL

* 2)
、instruments协理进程但相应的干活负荷总专门的学问量不可预估(Infiniti进度):只有WOPRADOK_COMPLETED列有意义(因为他出示正在试行的速度突显),WO纳瓦拉K_ESTIMATED列此时失效,展现为0,因为尚未可预估的总进程数据。通过查询events_stages_current表来监视会话,监察和控制应用程序到近期甘休施行了不怎么干活,但无能为力告诉对应的职业是还是不是接近完结

*
3)、instruments援助进程,总专业量可预估(有限进程):WOOdysseyK_COMPLETED和WORK_ESTIMATED列值有效。那种类型的快慢显示可用于online
DDL时期的copy表阶段监视。通过查询events_stages_current表,可监察和控制应用程序当前壹度做到了不怎么干活,并且能够通过WO奇骏K_COMPLETED
/ WORK_ESTIMATED总结的比率来预估某些阶段总体形成比例

NESTING_EVENT_ID:事件的嵌套事件EVENT_ID值(父事件ID)

NESTING_EVENT_TYPE:嵌套事件类型。有效值为:TRANSACTION,STATEMENT,STAGE,WAIT。阶段事件的嵌套事件不以为奇是statement

对于events_stages_current表允许使用TRUNCATE
TABLE语句来开始展览清理

PS:stage事件拥有八个速度展现效果,大家能够动用该进度展现效果来领悟一些长日子施行的SQL的进度百分比,举个例子:对于急需运用COPY格局推行的online
ddl,那么必要copy的数据量是自然的,能够明显的,so..那就足以为”stage/sql/copy
to tmp table stage”
instruments提供二个有甘休边界参照的速度数据音信,这么些instruments所使用的做事单元就是索要复制的多少行数,此时WO翼虎K_COMPLETED和WORK_ESTIMATED列值都以立竿见影的可用的,两者的计量比例就表示方今copy表完结copy的行数据百分比。

  • 要查阅copy表阶段事件的正在实施的快慢监视功效,要求张开相关的instruments和consumers,然后查看events_stages_current表,如下:

# 配置相关instruments和consumers

UPDATEsetup_instruments SETENABLED= ‘YES’WHERENAME= ‘stage/sql/copy to
tmp table’;

UPDATEsetup_consumers SETENABLED=
‘YES’WHERENAMELIKE’events_stages_%’;

# 然后在实施ALTEHighlander TABLE语句时期,查看events_stages_current表

events_stages_history 表

events_stages_history表包蕴各类线程最新的N个阶段事件。
在server运维时,N的值会自动调解。
假使要显式设置N值大小,能够在server运转在此之前设置系统变量performance_schema_events_stages_history_size的值。stages事件在实践实现时才加多到events_stages_history表中。
当增加新事件到events_stages_history表时,如果events_stages_history表已满,则会舍弃对应线程较旧的风浪events_stages_history与events_stages_current表结构同样

PS:允许行使TRUNCATE TABLE语句

events_stages_history_long 表

events_stages_history_long表包罗近日的N个阶段事件。
在server运转时,N的值会自动调治。
假若要显式设置N值大小,能够在server运营在此之前设置系统变量performance_schema_events_stages_history_long_size的值。stages事件推行完成时才会增添到events_stages_history_long表中,当增添新事件到events_stages_history_long表时,如果events_stages_history_long表已满,则会屏弃该表中较旧的风云events_stages_history_long与events_stages_current表结构一样

PS:允许使用TRUNCATE TABLE语句

言辞事件表

话语事件记录表与等待事件记录表一样,也有三张表,这么些表记录了当前与近期在MySQL实例中生出了何等语句事件,时间费用是多少。记录了精彩纷呈的话语实行发生的话语事件音讯。

要留意:语句事件有关布署中,setup_instruments表中statement/*始于的有着instruments配置暗中认可开启,setup_consumers表中statements相关的consumers配置默许开启了events_statements_current、events_statements_history、statements_digest(对应events_statements_summary_by_digest表,详见后续章节)但从没开启events_statements_history_long。

events_statements_current 表

events_statements_current表包蕴当前说话事件,种种线程只显示一行近来被监视语句事件的目前事态。

在蕴捷克语句事件行的表中,events_statements_current当前风云表是基础表。其余包罗语句事件表中的数目在逻辑上源于当前事变表(汇总表除却)。例如:events_statements_history和events_statements_history_long表是近年的语句事件历史的汇集,events_statements_history表中各类线程私下认可保留十行事件历史消息,events_statements_history_long表中暗许全数线程保留一千0行事件历史新闻

表记录内容示例(以下音信依然来自select
sleep(十0);语句的说话事件消息)

root@localhost : performance_schema 12: 36: 35> select * from
events_statements_current where SQL_TEXT= ‘select sleep(100)’G;

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

THREAD_ID: 46

EVENT_ID: 334

END_EVENT_ID: NULL

EVENT_NAME: statement/sql/select

SOURCE: socket_connection.cc: 101

TIMER_START: 15354770719802000

TIMER_END: 15396587017809000

TIMER_WAIT: 41816298007000

LOCK_TIME: 0

发表评论

电子邮件地址不会被公开。 必填项已用*标注