菜单

performance_schema全方位介绍,Mysql主从同步错误

2019年4月25日 - 美高梅手机版游戏
performance_schema全方位介绍,Mysql主从同步错误

原标题:复制状态与变量记录表 | performance_schema全方位介绍(6)

Coordinator stopped because there were error(s) in the worker(s). The
most recent failure being: Worker 2 failed executing transaction
‘ANONYMOUS’ at master log mysql-bin.005656, end_log_pos 4529152. See
error log and/or
performance_schema.replication_applier_status_by_worker table for
more details about this failure or others, if any.

23 MySQL Performance Schema

23 MySQL Performance Schema..
1

二三.1 质量框架急忙运行…

二3.二 质量框架配置…

2三.二.壹 品质框架编写翻译时配置…

23.二.二 质量框架运营配置…
6

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

二三.二.三.壹 质量框架结构事件定期…

23.二.三.2 质量框架事件过滤…

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

二3.二.3.肆命名记录点也许消费者的过滤…
12

2三.二.叁.5 识别哪些已经被记录…
12

23.3 品质框架查询…
一三

二3.肆 品质框架记录点命名约定…
1叁

二3.5 质量框架和情形监察和控制…
一伍

2三.陆 品质框架和成员原子性事件…
1柒

二三.柒 质量框架statement digests壹⑦

二三.八 品质框架常用表个性…
1玖

二叁.玖 质量框架表描述…
1玖

二3.九.一 品质框架表索引…
1九

贰3.玖.二 质量框架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

二3.九.3 质量框架实例表…
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

二叁.九.4 品质框架事件等待表…
二五

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

2叁.玖.5 品质框架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一

二叁.玖.7 质量框架事务表…
3贰

2三.玖.8 品质框架连接表…
35

二3.九.9 品质框架连接属性表…
35

贰3.玖.十 品质框架用户变量表…
35

23.9.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

二3.玖.12 质量框架锁相关表…
4一

23.9.12.1 metadata_locks41

23.9.12.2 table_handles42

二三.玖.一三 品质框架种类变量表…
4二

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

二叁.9.壹五 品质框架总计表…
四三

23.玖.16 质量框架其余表…
4四

二3.10 品质框架选项和变量…
四五

二三.11 质量框架命令选项…
45

二三.1二 品质框架种类变量…
四五

二三.一三 质量框架状态变量…
四伍

二三.1四 质量框架内部存款和储蓄器分配模型…
四5

二叁.1伍 质量框架和…
4陆

二三.16 使用质量框架检查判断…
四柒

2三.一7 迁移到质量框架种类和状态变量表…
四7

 

MySQL Performance Schema用来监督MySQL
Server的运维运营在底层。品质框架有那些特色:

·         质量框架提供了1种艺术检查当中的劳动运维。通过PE汉兰达FO奥迪Q五MANCE_SCHEMA存款和储蓄引擎和performance_schema落成。质量框架首要关怀于数据质量。和INFO卡宴MANCE_SCHEMA不同,INFORMACE_SCHEMA主要检查元数据。

·         性能框架监察和控制服务事件,事件是劳动须要花时间的别的交事务物,并且一度被记录如此时间消息能够被采撷。经常一个事件能够是一个函数调用,一个操作系统等待,SQL语句试行的阶段比方解析或然排序,也许全部讲话恐怕一组语句。时间采访提供。时间采撷提供了一同调用文件和表IO,表锁等新闻。

·         品质框架事件的风云和binlog的轩然大波,事件调整的轩然大波不一样。

·         质量框架事件被内定到有些MySQL服务。品质框架表外人本身是地点服务,他们的修改不会被写入到binary
log,也不会被复制。

·         当前事件,历史事件和事件下结论是可用的,那么就足以鲜明记录被运营了有点次,用了某些日子。事件新闻方可查看钦赐线程的移位大概内定对象的移动,比如文件和时限信号量。

·        
PERFORMANCE_SCHEMA存款和储蓄引擎使用代码中的记录点来搜聚新闻。

·         搜罗的音信被封存在performance_schema数据库中。能够用select查询。

·         品质框架配置能够动态的被涂改,通过退换performance_schema数据库配置数据收罗。

·        
Performance_schema上的表是视图或然暂时表,不会保留到磁盘中。

·         MySQL帮助具有平台的监察和控制。

·         通过在源代码中投入记录点落成数量搜聚。未有一定线程使用相关的质量框架。

图片 1

在从库中查看表performance_schema.replication_applier_status_by_worker
select * from
performance_schema.replication_applier_status_by_worker\G

2三.一 品质框架赶快运维

对于质量框架要启用,必要求在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本田CR-VFO君越MANCE_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查看当前劳动在做哪些。每种线程都有一行。

历史表,表结商谈脚下事件一样,event_waits_history和event_waits_history_long表包括了各类线程近来13个event和各样线程近年来一千0个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 |

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

如,上边结果THLacrosse_LOCK时域信号量是热点,3个语句分别表示实践的热度和等待事件长度。

实例表,记录了目的类型被记录了。当服务使用了三个笔录对象,那么会发生贰个事变。那些表提供了事件名,解释性的表明或然状态。比如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表列出了可用的顾客。

操纵是或不是质量框架珍惜1个顾客作为事件音信的靶子。可以设置为enabled值。

出品 沃趣科学技术

*************************** 2. row
***************************
CHANNEL_NAME:
WORKER_ID: 2
THREAD_ID: NULL
SERVICE_STATE: OFF
LAST_SEEN_TRANSACTION: ANONYMOUS
LAST_ERROR_NUMBER: 1168
LAST_ERROR_MESSAGE: Worker 2 failed executing transaction ‘ANONYMOUS’
at master log mysql-bin.005656, end_log_pos 4529152; Error executing
row event: ‘Uerlying table which is differently defined or of non-MyISAM
type or doesn’t exist’
LAST_ERROR_TIMESTAMP: 2017-12-01 08:57:55

二三.二 品质框架配置

IT从业多年,历任运营程序猿,高端运转技术员,运行首席营业官,数据库工程师,曾参加版本公布种类,轻量级监察和控制种类,运营管理平台,数据库管理平台的设计与编写制定,熟练MySQL的类别布局时,InnoDB存款和储蓄引擎,喜好专研开源才具,追求左右逢源。

去主库查找binlog日志,看看产生了怎么样业务(日志定位情势有点挫)
mysqlbinlog –start-position=4529152 –stop-position=4539152
mysql-bin.005656 | more
那条命令是从452915贰职位上马,可是我们失误的地点(end_log_pos)是这几个职位甘休,所以刚刚错开,再往前一点就好
了。
通过那条命令看到日志时间是2017-1二-0壹 0一:四7:4壹,所以自个儿用了其余一条命令
mysqlbinlog –start-datetime=2017-12-01 01:47:41
–stop-datetime=2017-12-01 01:47:50 mysql-bin.005656 | more
找到日志:

二三.2.1 品质框架编写翻译时安插

为了让质量框架启用必须在编写翻译时被安插,由官方提供的MySQL是支撑质量框架的,纵然是其它公布方发表的,那么要先反省是还是不是补助。

假固然从源代码发布的,那么在昭示的时候要先安装:

shell>
cmake
. -DWITH_PERFSCHEMA_STORAGE_ENGINE=1

在MySQL 5.7.3之后,也得以支撑运维品质框架,可是不含有全部的记录点,比如:

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途乐FOCR-VMANCE_SCHEMA存款和储蓄引擎。固然在build的时候没有被布署那么show engines不会来得PECR-VFO福睿斯MANCE_SCHEMA存款和储蓄引擎。

不知不觉中,performance_schema类别快要接近尾声了,昨天将带领大家一同踏上密密麻麻第肆篇的道路(全系共四个篇章),在那一期里,大家将为我们无微不至授课performance_schema中的复制状态与变量总计表。下边,请随行我们一齐起先performance_schema系统的读书之旅吧~

图片 2

23.二.二 质量框架运营配置

要是质量框架是可用的,那么默许是开发银行的也得以在配备文件中配备:

[mysqld]
performance_schema=ON

若是服务不能够在伊始化性能框架的时候分配内部缓存,那么质量框架本人关闭并且安装performance_schema为off,服务在未曾记录点境况下运作。

天性框架能够以命令行参数形式配置。

–performance-schema-instrument=’instrument_name=value

关闭全体记录点:

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

比较长的笔录点名会比短的集合点名要先行于短的情势名,不管顺序。

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

1个无法别识其余记录点名会被忽略。为了垄断消费者,能够选取以下选项:

–performance-schema-consumer-consumer_name=value

consumer_name是八个买主名比方events_waits_history,value是以下叁个值:

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

一旦未有点名值,那么私下认可这几个变量会有二个暗许值。在MySQL
伍.7.陆,品质框架分配内部存款和储蓄器会依据服务符合扩展伙子收缩,而不是在劳务运行的时候1回性分配完了。所以众多参数并不须求在起步的时候都分配好,越来越多内容能够看二3.1二质量框架系列变量。

各样机关分配的参数不是在运行时设置或许安装为-一,品质框架决定怎样依照以下的参数来设置这一个值:

max_connections

open_files_limit

table_definition_cache

table_open_cache

若果要覆盖机关安装的值大概电动范围的值,就在起步的时候设置二个加以的值而不是给-壹如此质量框架就会安装1个加以的值。

在运转时,show variables会彰显自动安装的值,自动范围设置的会给-1.举个例子品质框架被禁止使用,自动安装和机动范围参数都会棉被服装置为-一,并且显示为-一.

01

image.png

二三.2.三 运行时品质框架配置

复制消息计算表

查看那几个ID为33二的那张表,开采那张表是全自动创造的,创造的时候从不点名存储引擎,所以基本都出错了

2三.贰.3.壹 质量框架结构事件定期

事件被搜聚也便是说记录点被加到了服务源代码中。记录点时间事件,是性质框架怎么样提供2个事件不断多长时间的方案。也能够布置记录点收罗定期新闻。

天性框架反应计时器

三个属性框架表提供了电磁打点计时器音讯:


Performance_timers,保存了可用的timers和它们的特点。


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:钦命周期获取1个定期需求的细小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要大,不过不重大,因为调用一回计数器的数量级远远比实行语句作者的cpu时间要小。

Cycle提供的精度和cpu有关,假如管理器是一Gh恐怕越来越高,cycle能够提供比飞秒还小的快慢。使用cycle计数器比获得一个一天的实际事件支出小。

Cycle的缺点:

l  从cycles转化为时间单位是相比较艰苦的。为了更加快,那一个转化操作知识非常粗大劣的乘法总括。

l  管理器cycle,大概会遍,比方台式机进入省电形式,那么cpu
cycle会下落假诺cpu cycle有骚动,那么转化就会出错。

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

l  一些Computer,乱序施行只怕多处理器同步,可能会招致计数器忽高忽低。

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

仓库储存在性质框架表的脚下事变,有三个列表示事件,TIME福睿斯_START,TIMER_END代表事件运转和终止,TIMETucson_WAIT代表事件的岁月。

Set_instruments表有ENABLED字段来代表,事件是或不是要搜集。TIMED字段表示记录点是还是不是被时间标志。要是记录点没有运转,那么就不会扭转事件。借使不是timed,那么生成的风浪,中TIME途乐_START,TIME_END,TIMER_WAIT是null。那么在总结表计算最大时间,最小时间的时候会被忽略。

当中,事件运行的时候,timer以给定的单位保存在事件之中,当要呈现的时候,timers被出示为规范的事件单位,不管选了什么timer都会来得为,飞秒。

Setup_timers的改换会立刻见效。已经在管理的会动用老的timer。为了不造成无法预想的结果出现,最佳先把计算表使用truncate
table实行重新载入参数。

Timer的基线,在劳动运行的时候被开端化。TIME奥迪Q3_START,TIMER_END表示从基线以来的微秒数。TIMEXC60_WAIT表示占用的阿秒。

普普通通,DBA或有关数据库运行职员在查阅从库的复制相关的音信,都习贯性的采取show
slave
status语句查看。可能你会说,笔者也会用performance_schema下的表查看有个别复制报错音讯什么的。可是,你领悟show
slave
status语句、mysql系统库下的复制消息记录表、performance_schema系统库下的复制新闻记录表之间有哪些不一致吗?不掌握?别急,本文将要为您详细介绍show
slave
status语句与performance_schema系统库下的复制新闻记录表的界别(mysql系统库下的复制表分化详见后续
“mysql系统库全方位介绍”类别)。

二3.二.三.二 品质框架事件过滤

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

l  记录点代码是事件的源,产生事件被用来收罗,setup_instruments表列出了足以被采访的记录点。Setup_instruments表提供了重重event的发出。

l  品质框架表示事件的目标地。Setup_consumers,列出了富有顾客类型。

预过滤,通过改造品质框架配置达成,能够透过启用或许剥夺记录点和买主完结。使用预过滤的目标:

n  减弱负荷。质量框架运转需求开支能源,即使很少。

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

n  幸免维护多少个门类的轩然大波表。

·           事后过滤,能够接纳where语句在查询质量框架的时候过滤。

在起来详细介绍每一张复制新闻表以前,我们先耗费一些篇幅来完全认知一下那一个表。

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

预过滤有总体性框架形成而且会全局的熏陶全部用户。预过滤能够在劳动者也许消费者的管理阶段上:

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

§  
Setup_instruments表明哪个记录点是可用的,假诺那一个表上1个记录点被禁止使用,不管别的表怎么布署,都不会再产惹事件。

§  
Setup_objects调节了品质框架特定表和仓库储存进程对象。

§   Threads表示是还是不是各样服务线程都有监督

§  
Setup_actors新的后台进度的伊始监察和控制状态

·           要布局预过滤在顾客阶段,那么要修改setup_comsumers表。setup_comsumers也会潜移默化事件的爆发。如若内定的轩然大波不会发送给任啥地方方,那么质量框架不会发出

修改任性表都会应声影响监察和控制,可是多少不一致:

·         修改有个别setup_instruments表只有的劳动运行的时候生效。在运营时修改不会收效。

·         修改setup_actors表,只会潜移默化后台线程。

当修改监控配置,质量框架不会刷新历史表。历史表和脚下表的轩然大波不会被轮换,除非又新的事件。要是禁止使用3个记录点的时候,需求静观其变1段时间,来替换老的轩然大波。也足以用truncate
table清空。

在退换完记录点之后,恐怕下尤其药伤处summary表清理总计新闻对于events_statements_summary_by_digest可能内部存储器计算表。Truncate table只会复位值为0,并不会删除行。

performance_schema
系统库下提供了之类多少个与复制状态相关的表(表含义详见本文后续小节):

二叁.2.三.三.1 记录点预过滤

支配记录点的过滤,是过滤setup_instruments表设置enables字段。修改setup_instruments大好些个会立刻见效。对于一些记录点,修改只会在服务器运转才会立竿见影。setup_instruments提供了最基本的记录点调控。

2三.二.三.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外全体的的数据库对象。

那一个复制表中著录的讯息生命周期如下(生命周期即指的是那个表中的新闻曾几何时写入,何时会被改造,几时会被清理等):

二三.2.三.叁.三 线程预过滤

threads表为各类线程保存了壹行数据。每行数据都含有了线程的新闻并且注解是还是不是被监督。对于质量框架监察和控制三个线程必须知足一下他条件:

·         表sestup_consumers表中的thread_instrumentation必须为yes

·        
Threads.instrumented列必须为yes

·         只监控setup_instruments表中的记录点

threads表也认证了每一个服务线程是或不是进行历史事件记录。要是要记录历史事件以下规则都不能够不为真:

·         对应的顾客配置,setup_consumers表必须为yes。

·        
Threads.HISTOPRADOY列必须为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 5.7.陆 在此以前,未有enabled字段,只要有极度,那么instrumented=yes

在mysql五.7.八,此前,未有history字段,线程要不全体方可进来history要不都无法,取决于setup_consumer的配置。

私下认可,后台的兼具线程都以会被记录的,因为setup_actors有一行都以‘%’。

二三.二.三.3.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和地点类似。

performance_schema
系统库中保存的复制消息与SHOW SLAVE
STATUS输出的新闻有所不一样(performance_schema 中著录的1部分复制音信是show
slave status语句输出新闻中尚无的,然而也照例有部分show slave
status语句输出的复制音信是performance_schema
中从未的),因为这么些外部向全局工作标志符(GTID)使用,而不是基于binlog
pos地方,所以那一个回想录server UUID值,而不是server ID值。show slave
status语句输出的音信在performance_schema 中不够的剧情如下:

二三.二.3.四命名记录点也许消费者的过滤

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

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’;

内定1组记录点恐怕消费者:

mysql>
UPDATE
setup_instruments

   
-> SET
ENABLED = ‘NO’

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

 

mysql>
UPDATE
setup_consumers

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

用以引用binlog file、pos和relay log
file、pos等信息选项,在performance_schema表中不记录 。

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

由此检查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   |

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

PS1:正如系统状态变量被活动到了这一个复制状态表中举办记录(MySQL
伍.七.5版从前使用以下状态变量查看):

二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 |

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

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

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

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

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

头等记录点组件

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

·          
Memory:memory事件记录点

·          
Stage:阶段事件记录点

·          
Statement:语句事件记录点

·          
Transaction:事务事件记录点

·          
Wait:等待事件记录点

Idle记录点组件

Idle记录点用于idle事件,具体看:23.9.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。服务有2个监听socket用来帮忙每一种网络协议。这么些记录点援救监听socket是tcpip大概unix
socket文件。socket_type的值为server_tcpip_socket或者server_unix_socket。当监听socket发掘一个延续,服务把那几个接二连三转产生独门的线程。那么新的一而再线程的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,条件被用来一个线程公告别的2个线程,有个别它们等待的事物已经到位。如果一个线程等待3个规格,那么会醒来并且管理。假若三个线程等待那么会都新来并且做到它们等待的能源。

§  
Wait/synch/mutex,多排他对象用来做客七个能源,制止其余线程访问财富。

§  
Wait/synch/rwlock,多少个读写锁对象用来锁定特定的变量,防止其余线程使用。贰个共享读所能够多少个线程同时得到。多个排他写锁只可以由一个线程获取。

§  
Wait/synch/sxlock,共享排他锁是读写锁的rwlock的①种,提供当一个线程写时,其余线程能够非1致性读。Sxlock在mysql ⑤.7中央银行使为了优化rwlock的或展现。

PS2:对此组复制架构,组复制的监督检查音讯散播在如下几张表中

二3.五 质量框架和意况监察和控制

能够动用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。不过复信号量还是以用于对象同步。可是品质数据就不能被采访,要是记录点被分配,用来开始化记录点连续信号量实体。对于单身的时域信号量比方全局时限信号量,唯有一个实例。有个别确定性信号量的实例个数会转移,比如每一种连接的非确定性信号量。假设服务无法成立3个钦命记录点复信号量实体,就会增加,performance_schema_mutex_instance_lost。

若是有以下规范:

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

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

·           插件plugin_a有三十几个确定性信号量

·           插件plugin_b有十7个时域信号量

劳务为插件,分配功率信号量记录点注重于已经分配了稍稍,比如以下语句:

INSTALL
PLUGIN plugin_a

那便是说服务已经有了150+37个功率信号量。

UNINSTALL
PLUGIN plugin_a;

即便插件已经卸载,不过照旧有1九十几个数字信号量。全体插件代码生成的历史数据可能有效。然而新的记录点事件不会被分配。

INSTALL
PLUGIN plugin_a;

劳动意识37个记录点已经被分配,因而新的记录点不会被创立,并且从前分配的个中buffer会被另行利用,非复信号量依然1捌拾陆个。

INSTALL
PLUGIN plugin_b;

其1利用可用信号量已经唯有1贰个了,新的插件要十多少个记录点。1一个曾经被加载,10个会被打消也许丢失。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公布。然则部分插件借使不加载恐怕会少一些。例如您能够不加载默写存款和储蓄引擎。

·           你加载2个第三方插件,是性质框架的记录点,可是在劳动运行的时候,不容许插件记录点内部存款和储蓄器获取。因为来自第一方,那一个引擎的记录点内部存款和储蓄器并不会被记录在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,那么久不会把内部存款和储蓄器分配到和文件有关的类,对象实例大概句柄中。

23.陆 品质框架和成员原子性事件

对此一个表的io事件,常常有2行在events_waits_current,不是3个如:

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事件司空眼惯有二行:

·           一行是时下表io等待事件

·           壹行是任何任何类型的守候事件。

一般来讲,其余项目标等候事件不是表io事件。当副事件做到,会从events_waits_current中消失。

由此以上内容,大家从总体上能够大要领会了performance_schema中的复制音信表记录了什么样新闻,下边依次详细介绍这一个复制音讯表。

二3.7 质量框架statement digests

MySQL服务有力量保险statement digest音信。Digest进度把一个sql语句转化为规范的格式并且计算七个hash结果。标准化允许相似的言辞分组并且总括揭破一些话语的花色和爆发的功用。

在性质框架,语句digest涉及这么些零件:

·          
Setup_comsumers的statement_digset调整了,质量框架怎样维护digest音信。

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

§  
DIGEST_TEXT,规范化的言辞。

§   DIGEST,是digest MD5 hash值。

Digest计算,最大的可用空间拾二肆B。MySQL 伍.7.8后那些值可以因此参数,performance_schema_max_digest_length修改。之前运用max_digest_length。

·           语句事件表也有sql_text列包罗了本来的sql语句。语句呈现的最大为十二四B,能够经过performance_schema_max_sql_text_length字段修改。

·          
events_statements_summary_by_digest,提供综合的语句digset消息。

基准2个讲话转化,会保留语句结构,删除不须求的新闻:

·           对象标记符,比如表只怕数据库名会被保留。

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

·           注释会被删去,空格会被调度。

诸如如下一个语句:

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和DIGEST三个hash值。语句Digest总计表,提供了话语的profile消息,突显语句运转功效运转次数等。

events_statements_summary_by_digest大小固定的,所以1旦满了,借使在表上未有相称的,那么富有的言辞都会被总计在schema_name和digest为null的笔录里面,当然可以增添digest大小,performance_schema_digests_size,假设未有点名,那么品质框架会协调评估2个值。

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,但是增添了讲话的相似度,被当成同1个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      |

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

1.replication_applier_configuration表

二三.八 质量框架常用表本性

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

过多表在performance_schema数据库是只读的无法被修改。一些setup表的一点列能够被改造。一些也得以被插入和删除。事务能够被允许清理收集的事件,所以truncate
table能够用来清理音讯。

Truncate table能够在计算表上应用,不过不能够再events_statements_summary_by_digest和内部存款和储蓄器计算表上运用,效果只是把一同列清理为0.

该表中记录从库线程延迟复制的配置参数(延迟复制的线程被称之为普通线程,举个例子CHANNEL_NAME和DESIRED_DELAY字段记录有些复制通道是不是供给实践延迟复制,假设是名爵Rubicon集群,则记录组复制从节点的延期复制配置参数),该表中的记录在Server运转时方可运用CHANGE
MASTER
TO语句进行更改,大家先来探望表中著录的总括新闻是哪些体统的。

2三.玖 质量框架表描述

# 倘若是单主或多主复制,则该表中会为各类复制通道记录一条看似如下音讯

贰三.玖.1 品质框架表索引

具体看:

admin@localhost : performance_schema 02:49:12> select * from
replication_applier_configuration;

二3.九.2 品质框架setup表

Setup表提供有关当前搜集点启用音讯。使用表而不是全局变量提供了越来越高等别的属性框架配置。比方您可以采用2个sql语句配置七个记录点。

这么些setup表示可用的:

·          
Setup_actors:如何早先化后台线程

·          
Setup_consumers:决定怎么着消息会被发送和积存。

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

·          
Setup_objects:哪些对象要被监察和控制

·          
Setup_timers:当前事变电火花计时器。

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

23.9.2.1 setup_actors表

setup_actors表包涵了新闻决定是还是不是监察和控制可能对新的后台线程实行历史数据记录。那几个表暗许最多拾0行,能够透过修改参数performance_schema_setup_actors_size修改尺寸。

对于新的后台线程,在setup_actors中,品质框架满足的用户和host。假若二个行负荷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列。

| CHANNEL_NAME |DESIRED_DELAY |

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设置产生从高到低的品级。产生正视,假设高档其他设置了低档别才会有机遇被检查。

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

23.9.2.3 setup_instruments表

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

mysql> SELECT * FROM setup_instruments;

种种记录点被扩大到源代码中,都会在这几个表上有一行,固然记录点代码未有被钦赐。当三个记录点运转了只怕推行了,记录点实例就会被创立会议及展览示在*_instrances表。

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

|| 0 |

23.9.2.4 setup_objects表

Setup_objects表调整了如何对象的性格框架会被监督。那些目的默感觉100行能够由此退换变量来支配,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。那么就不会有目的没监察和控制。

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

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中的1行。表示某些事件类型应用了什么样电火花计时器

1row inset ( 0. 00sec)

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

# 若是是MG驭胜集群,则该表中会记录类似如下MG福睿斯集群消息

23.9.3.1 cond_instances表

Cond_instance表列出了装有质量框架能够查阅的口径。条件是一道机制,用来打招呼一个钦赐的事件早已发生达成。所以叁个线程等待那几个规格的会马上回复职业。

当多个线程等待的东西已经改变,条件名值表明线程在等待条件名。

root@localhost : performance_schema 10:56:49> select * from
replication_applier_configuration;

23.9.3.2 file_instances表

当钦赐文件io记录点的时候,File_instances表列出了具有品质框架能看出的富有文件。如若文件在disk不过从未被展开不会并发在file_instrances中。当文件在次磁盘中被剔除,那么file_instances中也会删除。

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

23.9.3.3 mutex_instances表

Mutex_instances呈现了有着能够被质量框架查看到的时限信号量。功率信号量是3头机制用来保卫安全能源。当3个线程运维需求放问一样的财富,一个线程会互相争用,3个线程获取了mutex上的锁,那么其余贰个不得不等待上三个完了。

当职分执行获取实信号量,称为临界区域,区域内实践都以各类的,可能有神秘瓶颈难点。

表中有3个字段:

Name:记录点的名字

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

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

对此每一种记录的实信号量,质量框架提供一下音讯:

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

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

·         当2个线程视图锁定功率信号量,events_waits_current表为线程显示1行,表明在等待功率信号量,通过object_instance_begin。

·         当线程成功锁定了1个随机信号量:

§ 
Events_waits_current,显示等待数字信号量就会做到

§  完结的风云会被增多到历史表中

§ 
Mutex_instances显示功率信号量将来属于1个thread

·         当thread unlock八个能量信号量,mutex_instances显示复信号量今后尚无owner,thread_id为null。

·         当时限信号量对象被销毁,对应的行也会被去除。

查以下二个表,能够检查判断瓶颈或许死锁:

§ 
Events_waits_current,查看线程等待的数字信号量。

§ 
Mutex_instrances,查看其余线程的保有的复信号量。

| CHANNEL_NAME |DESIRED_DELAY |

23.9.3.4 Rwlock_instances表

Rwlock_instances表列出了有着rwlock的实例。景逸SUVwlock是联合机制用来强制在自然规则下,在给定的风云之中能访问片段能源。那几个能源被rwlock尊崇。访问要不是共享艺术要不是排他格局,假如允许非1致性访问,还足以共享排他方式访问。Sxlock唯有在,mysql 5.柒后头才干被使用,用来优化并发性。

依靠访问的必要,所的央浼要不是,共享,排他,共享排他大概不授权,等待其余线程完毕。

表列如下:

·          
NAME:记录点名相关的lock

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

·          
WRITE_LOCKED_BY_THREAD_ID:当1个线程有2个rwlock,排他方式,W大切诺基ITE_LOCKED_BY_THREAD_ID,正是锁定线程的thread_id。

·          
READ_LOCKED_BY_COUNT:当线程当前有2个rwlock共享格局,那么read_locked_by_count扩展一。只是个计数,所以找不到越发线程具有了读锁,然则能够用来查看是或不是有读锁,有多少读是运动的。

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

·          
Events_waits_current,查看等待哪些rwlock

·          
Rwlock_instrances,查看别的线程是还是不是具有那么些锁。

唯其如此知道分外线程有了write lock不过不知道哪些线程有read lock。

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

23.9.3.5 socket_instance表

Socket_instancees表提供了3个实时的接连活动快照。每一种tcp/ip连接有一行,也许每种unix socket file连接有1行。

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

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

  1. 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

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

  1. 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``。

2.      当有2个监听socket开采三个接二连三,那么服务会转化到二个新的socket来管理,server_type类型为client_connection。

3.      当一个连接中断,那么行会在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组合来表示一个立见成效的连年。组合值被用来events_waits_xxx表的object_name,来标识连接来至于哪儿:

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

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

·           对于tcp/ip的监听,端口是劳动的端口,默感觉330陆,ip为0.0.0.0

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

|group_replication_applier | 0 |

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

事件等待表有三个:

·          
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’;

| group_replication_recovery |0|

23.9.4.1 events_waits_current表

Events_waits_current表包罗了当下的守候时间,各样thread都有壹行显示当前thread的等候时间。伊芙nts_waits_current表能够运用truncate table。

Events_waits_current表列:

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

·        
END_EVENT_ID
当事件运行,这么些列为null,假若时光甘休分配1个事件号。

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

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

·        
TIMER_START,TIMER_END,TIMER_WAIT
事件的timing音讯。时间单位为皮秒。TIME奇骏_START,TIMER_END代表事件的始发和终止。TIMEOdyssey_WAIT是事件的持续时间。假设事件尚未做到TIMEXC90_END,TIMER_WAIT为null。若是记录点的timed=no那么这2个列都是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这些字段查看是或不是有1000个非功率信号量,形成某个瓶颈。

·        
INDEX_NAME
选择的index名字,primary表示表的主键索引,null表示不曾索引

·        
NESTING_EVENT_ID
event_id表示11分event被嵌套

·        
NESTING_EVENT_TYPE
嵌套的风云培养和演练,恐怕是以下一种,TRANSACTION,STATEMENT,STAGE,WAIT

·        
OPERATION
施行操作的门类,lock,read,write中一个。

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

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

在join操作的时候表的表行的增添减少(扇出)。倘使t三的扇出当先1,那么大大多行赚取操作就源于于这么些表。假诺t1 十行,t二 20行对应到t11行,t三 30行对应t2 一行。那么1共会有被记录的操作是:

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

为了削减被记录操作,能够因而每一遍扫描达成聚合的法子(聚合t一,t2的唯一值)。记录点计数减弱为:

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

对于地点的事态采取条件:

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

§  查询推行不需求表内的单个记录

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

·         FLAGS
保留

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

23.9.4.2 Events_waits_history表

Events_waits_history表种种线程包括了近年N条数据。表结构和events_waits_current一行,也得以被truncate table,N是服务运转自动安装的,也足以从参数设置:
performance_schema_events_waits_history_size。

2 rows inset (0.00 sec)

23.9.4.3 events_waits_history_long 表

Events_waits_history_long表各类线程包蕴了不久前N条数据。表结会谈events_waits_current1行,也得以被truncate table,N是服务运维自动安装的,也能够从参数设置:
performance_schema_events_waits_history_long_size。

表中各字段含义及与show slave
status输出字段对应关系如下:

二叁.玖.伍 质量框架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 伍.7.5,质量架构stage事件表包罗2列,每行提供stage进程标示:

·          
WORK_COMPLETED:stage职业单元完毕个数。

·          
WORK_ESTIMATED:预期的stage专门的工作单元完毕个数。

借使未有进程消息,每列都以null。质量框架提供三个器皿来存放在那一个进程数据:

·           工作单元,是三个量,随着施行时间的充实变大。

·          
WORK_COMPLETED,1个照旧多少个单元扩大1次,正视于被记录代码

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

对此stage事件的进度的记录能够落成以下任何表现:

·           未有进度记录点
本条是最常现身的,因为从没进程数据被提供,WORK_COMPLETED和WORKESTIMATED都为bull

·           未有被绑定记录点
只有WORK_COMPLETED列有含义,WO卡宴K_ESTIMATED列未有值,展现为0。
打开events_stages_current表监察和控制回话,监察和控制程序能够告知有多少work已经被实行,不过不明白如哪天候能够甘休,因为记录点未有提供。

·           绑定进程记录点
WORK_COMPLETED和WORK_ESTIMATED列都以有含义的。
进程标记符的类型适合于已经定义了成就临界的操作,举个例子表复制记录点。通过查询events_stages_current表来监督会话,监察和控制程序能够监察和控制全数落成比例的stage,通过测算WO奥迪Q5K_COMPLETED / WORK_ESTIMATED的比率。

stage/sql/copy to tmp table演示,进度标记符如何是好事。在实施alter table语句,那一个记录点就很有用,并且会举办十分短壹段时间。

图片 3

23.9.5.1 events_stages_current表

Events_stages_current表包括当前stage事件,每行三个线程线程当前情形监察和控制到的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,要是时光甘休分配3个事件号。

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

·         SOURCE
源代码文件名包括产惹祸件的记录点代码地点。能够帮忙用来检查源代码。

·        
TIMER_START,TIMER_END,TIMER_WAIT
事件的timing消息。时间单位为阿秒。TIME福特Explorer_START,TIMER_END表示事件的初叶和竣事。TIME揽胜_WAIT是事件的持续时间。如若事件未有到位TIME昂Cora_END,TIMER_WAIT为null。倘使记录点的timed=no那么那个列都是null。

·        
WORK_COMPLETED,WORK_ESTIMATED
那个列提供了stage进度音信,对于记录点已经用来生成这一个新闻。WO昂科威K_COMPLETED表示有个别许办事单元已经被成功,WOENCOREK_ESTIMATED代表有微微办事单元推测的stage。

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

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

对于replication_applier_configuration表,不容许试行TRUNCATE
TABLE语句。

23.9.5.2 events_stage_history表

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

performance_schema_events_stages_history_size

2. replication_applier_status表

23.9.5.3 events_stage_history_long表

Events_stages_history_long为各样线程保留了N个记录,具体可以经过布署参数修改:

performance_schema_events_stages_history_long_size

该表中记录的是从库当前的形似职业执市场价格况(该表也记录组复制框架结构中的复制状态音讯)

2叁.9.六 质量框架语句事件表

属性框架记录点语句推行。语句事件发生在高档别的轩然大波,等待事件嵌套在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.7.2此前,语句只会是高端其他,比如在存款和储蓄进程可能子查询不会被分离出来。

末尾记录点名和服务命令和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获取事件。

恳请的详尽原来是不精通的,并且质量框架从呼吁的各样获取一定的笔录点名。

从客户端搜罗的乞求:

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

2.        当服务读取包序号,获取接受的伸手类型,品质框架获取记录点名。比方,请求是COM_PING包,那么记录点名会形成statement/com/ping。假诺请求是COM_QUE凯雷德Y包,知道是1个sql语句,可是不清楚具体的品种。那年会给八个抽象的笔录点名statement/abstract/query。

三.        借使请求的讲话,文本早已读入到分析器。分析未来,那么标准的话语类型已经知道了,借使请求是一个插入语句,品质框架会重复定位记录点名statement/abstract/Query
to statement/sql/insert。

 

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

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

二.        当语句被分析,精确的语句类型被搜查缉获。比方insert语句,那么品质框架会再一次寻觅记录点名,statement/abstract/Query
to statement/sql/insert。

上边介绍的,只是依据语句的复制,对于基于行的复制,订阅表行管理可以被记录,不过relay
log中的行事件描述语句的并不会现出。

 

对此从事件调整器来的呼吁:

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

事件体重的轩然大波施行记录点名使用statement/sql/*,不适用别的抽象记录点名。事件是一个囤积进度,并且存款和储蓄进程是预编写翻译在内部存款和储蓄器中的。那么在实行时就不会有分析,然而项目在实践时就理解了。

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

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

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

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

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

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

二叁.9.七 质量框架事务表

天性框架事务记录点。在事变等级,等待事件嵌套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)

·           隔开品级

·           隐式也许显示

为了削减职业记录点并且保险搜罗工作数据是到位的,有含义的结果,全部事务都有访问形式,隔开等级,自动提交格局。

业务事件表使用三列来ACCESS_MODE,ISOLATION_LEVEL,AUTOCOMMIT记录。

政工记录点消费能够有很八种方法减弱,例如根据用户,账号,host,thread运行可能禁止使用事务减了点。

 

线程和嵌套事件

专门的工作事件的上级事件是起先化事务的风浪。对于展现事务运维,包罗START_TRANSACTION和commit and china,借使是隐式事务,第四个语句启动职业。

展现的了断工作,COMMIT,ROLLBACK,大概DDL语句,隐式的提交业务。

 

专门的工作和仓库储存进程

事务和储存进度事件涉及如下:

·           存款和储蓄进度
仓库储存进度操作独立的事务,一个存款和储蓄进程能够运维一个政工,并且2个专业可以在积攒进程中运转和终止。尽管在八个作业中调用,三个仓储进程能够语句强制提交业务并且运维多个新的事务。

·           存款和储蓄函数
积存函数能够限制突显只怕隐式的专门的学问提交和回滚。

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

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

 

事务和savepoint

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

 

业务和错误 政工中的错误和警告被记录在讲话事件中,不过不在相关的事务事件。

我们先来看望表中著录的总括音讯是什么样子的。

贰3.玖.8 品质框架连接表

属性框架提供了一而再的总结新闻。当客户端连接,在2个特定的用户名和host下。性能框架为每种账号追踪连接。

·        
Accounts:种种客户端账号的一而再总计音信。

·         Hosts:各类客户端hostname 的总是总结新闻。

·         Users:各个客户端用户名的连天总结新闻。

账号那里的意趣是用户拉长host。连接表有CUPRADORENT_CONNECTIONS和TOTAL_CONNECTIONS列追踪全体的延续。Accounts表有USEKoleos和HOST列追踪用户和host。Users和hosts表有USEENCORE和HOST列,追踪用户依旧host。

假如客户端名user一,user2从hosta,hostb连接过来。质量框架追踪连接入选:

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

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

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

当客户端连接,连接表中如若不设有这么的用户还是host,那么就扩大一行不然就修改CUCRUISERRENT_CONNECTIONS和TOTAL_CONNECTIONS列。

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

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

各样连接表都能够truncate:

·         行假设是CU卡宴RENT_CONNECTIONS=0的就删除

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

·         连接合计表依赖于连接表的值会被设为0.

#
单线程复制和二十四线程复制时表中的记录同1,如若是多主复制,则每一个复制通道记录1行音信

2三.九.九 质量框架连接属性表

具体看:

admin@localhost : performance_schema 02:49:28> select * from
replication_applier_status;

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

具体看:

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

贰三.玖.11 质量框架复制表

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

·         Show slave
status输出能够翻阅进行反省,可是不能够用来编程使用。

·         查询结果能够保存到表中,用于分析,设置变量,或许在蕴藏进度上行使。

·         复制表提供了更加好的确诊音讯,对于102线程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.能够看看各种复制源。

| CHANNEL_NAME |SERVICE_STATE | REMAINING_DELAY
|COUNT_TRANSACTIONS_RETRIES |

23.9.11.1 replication_connection_configure表

表显示了连年到slave服务的连接配置。参数被保存在表中,在change
master实施的时候会被改换。

replication_connection_configuration表包含以下列:

·          
CHANNEL_NAME:复制源名。

·          
HOST:master的host名。

·          
PORT:master的端口

·          
USE福睿斯:连接用户

·          
NETWORK_INTERFACE:slave绑定的network接口。

·          
AUTO_POSITION:即使自定定位被采取了正是一,不然是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_INTECR-VVAL:重试的秒数。

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

·          
HEARTBEAT_INTETiguanVAL:复制心跳间隔。

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

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:收到的心跳次数。

|| ON |NULL | 0 |

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_RET本田UR-VIES:展现了sql thread应用工作错误,导致重试的次数。

1row inset ( 0. 00sec)

23.9.11.5 replication_applier_status_by_coordinator

对于四线程的slave,slave使用四个办事线程和3个和煦线程,协和线程用来管理职业线程,表展现了谐和线程的地方。假若是单线程slave,表为空。

Replication_applier_status_by_coordinator列:

·          
CHANNEL_NAME:复制来源名。

·          
THREAD_ID:SQL/和煦线程id。

·          
LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE:最后3回错误号和错误音讯。

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

# 就算是MG奥德赛集群,则该表会记录如下MGPAJERO集群音信

23.9.11.6 replication_applier_statys_by_worker

对于拾贰线程的slave,slave使用多少个干活线程和四个调匀线程,和睦线程用来管理专门的学业线程,表显示了和睦线程的情事。假如是单线程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会被保留,知道下一个业务运维成功。

§   当下3个GTID被别的线程获取,从gtid_next上获得。

·          
LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE:最终一次错误号和错误新闻。

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

root@localhost : performance_schema 10:58:33> select * from
replication_applier_status;

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揽胜ING:服务已经进入到1个group,正在获取数据。

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

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

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_MEMBE途乐S:固化的group事务集结。

·          
LAST_CONFLICT_FREE_TRANSACTION:最终1个并未有冲突的被证实的专门的学问。

| CHANNEL_NAME |SERVICE_STATE | REMAINING_DELAY
|COUNT_TRANSACTIONS_RETRIES |

贰三.九.1二 质量框架锁相关表

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

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:能够是那一个值的内部3个. GLOBAL, SCHEMA, TABLE,
FUNCTION, PROCEDURE, T大切诺基IGGEXC90 (currently unused), EVENT, COMMIT, USE逍客LEVEL LOCK, TABLESPACE, LOCKING SE汉兰达VICE。
假若值为USEEvoque LEVEL LOCK表示从get_lock()获取锁,假若是LOCKING SE奥迪Q7VICE表示使用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。

|group_replication_applier | ON |NULL | 0 |

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 P昂科雷IO汉兰达ITY, READ NO INSERT, WCRUISERITE ALLOW WRubiconITE, W中华VITE
CONCU兰德途乐RENT INSERT, WPRADOITE LOW PTiguanIORAV4ITY, W福特ExplorerITE。

·        
EXTERNAL_LOCK:存款和储蓄引擎等第使用的表锁,READ EXTETucsonNAL ,WPAJEROITE
EXTETucsonNAL

 

| group_replication_recovery |OFF | NULL |0|

二三.九.一三 品质框架类别变量表

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 。

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

2三.玖.1肆 质量框架连串状态变量表

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

2 rows inset (0.00 sec)

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:状态变量用户协议

表中各字段含义及与show slave
status输出字段对应关系如下:

2三.九.1陆 品质框架别的表

而外上边你的表还有3个表:

·          
Host_cache:内部host cache信息。

·          
Performance_timers:事件可用电磁照管计时器。

·          
Threads:服务的线程表。

图片 4

2叁.10 质量框架选项和变量

具体看:

对于replication_applier_status表,不容许实行TRUNCATE
TABLE语句。

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

具体看:

 

3. replication_applier_status_by_coordinator表

二三.1二 品质框架体系变量

具体看:

该表中记录的是从库使用多线程复制时,从库的谐和器事业处境记录,当从库使用二十三四线程复制时,每一个通道下将创造二个协和器和多少个职业线程,使用和煦器线程来保管这一个专门的工作线程。假诺从库使用单线程,则此表为空(对应的笔录转移到replication_applier_status_by_worker表中著录),大家先来探视表中记录的总计消息是怎样体统的。

2三.壹三 质量框架状态变量

具体看:

#
单线程主从复制时,该表为空,为四线程主从复制时表中著录谐和者线程状态音信,多主复制时每一种复制通过记录壹行新闻

二叁.1四 质量框架内部存款和储蓄器分配模型

在mysql 伍.柒.陆以前,质量框架使用以下内部存款和储蓄器分配模型:

·         全部的内设有运转时分配。

·         服务操作的时候不分配内部存款和储蓄器。

·         服务操作的时候不自由内部存款和储蓄器。

·         在劳动关闭的时候释放内部存款和储蓄器。

应用那一个模型,品质框架会分配多量的内部存款和储蓄器,除非呈现的安插。Mysql
5.七.陆过后的分配模型:

·         能够在劳务运行的时候分配。

·         能够在劳务操作的时候额外分配。

·         在劳务操作的时候不自由。

·         在劳务关闭的时候释放内部存储器。

如此能够根据负荷来调度内部存款和储蓄器使用,不是现实配置。

有一些属性框架配置参数是自行分配,也得以手动分配:

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/%’;

admin@localhost : performance_schema 02:49:50> select * from
replication_applier_status_by_coordinator;

二叁.一伍 质量框架和

具体看:

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

二3.1六 使用质量框架检查判断

属性框架能够让dba来做一些属性调节,比方1个重新出现的属性难点:

一.运转用例

二.使用质量框架表,分析根本的属性难题。分析严重正视于post过滤。

三.难点区域已经划出,禁止使用对应的记录点。举个例子要是条分缕析出和文书io不相关,禁止使用io的记录点。

四.重复 步骤一-3,这样能够削减干扰寻找真正的主题材料。

5.分明了品质瓶颈的原因:

§  调度服务参数

§  调解查询。

§  调治数据库结构

§  调度代码。

6.双重步骤一,查看对品质的影响。

在性质调优的时候,mutex_instances.locked_by_thread_id,rwlock_instances.
write_locked_by_thread_id列分外重视。比方:

1.线程壹,在守候贰个功率信号量。

贰.足以动用以下语句查看等待的功率信号量:

SELECT
* FROM events_waits_current WHERE THREAD_ID = thread_1;

3.然后翻看这些线程持有着那一个实信号量:

SELECT
* FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN = mutex_A;

四.查看线程贰在做怎样:

SELECT
* FROM events_waits_current WHERE THREAD_ID = thread_2;

| CHANNEL_NAME |THREAD_ID | SERVICE_STATE |LAST_ERROR_NUMBER |
LAST_ERROR_MESSAGE |LAST_ERROR_TIMESTAMP |

贰三.一7 迁移到质量框架种类和气象变量表

Information_schema有表包涵了系统和状态变量音讯,MySQL 5.柒.陆随后,质量框架也饱含了系统变量和状态变量新闻。质量框架的表会替代information_schema上的表。

在mysql 五.陆查看状态变量和种类变量来自于:

SHOW
VARIABLES
SHOW STATUS

 

INFORMATION_SCHEMA.GLOBAL_VARIABLES
INFORMATION_SCHEMA.SESSION_VARIABLES

INFORMATION_SCHEMA.GLOBAL_STATUS
INFORMATION_SCHEMA.SESSION_STATUS

Mysql 五.7.陆,品质框架也蕴涵了系统变量和状态变量:

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输出基于质量框架表。

 

 

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

|| 43 |ON | 0 || 0000-00-00 00:00:00 |

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

1row inset ( 0. 00sec)

# 如若是MGLAND集群,则该表中会记录类似如下MG奥迪Q5集群音信

root@localhost : performance_schema 11:00:11> select * from
replication_applier_status_by_coordinator;

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

| CHANNEL_NAME |THREAD_ID | SERVICE_STATE |LAST_ERROR_NUMBER |
LAST_ERROR_MESSAGE |LAST_ERROR_TIMESTAMP |

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

|group_replication_applier | 91 |ON | 0 || 0000-00-00 00:00:00 |

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

1row inset ( 0. 00sec)

表中各字段含义及与show slave
status输出字段对应关系如下:

图片 5

对于replication_applier_status_by_coordinator表,分裂意实施TRUNCATE
TABLE语句。

4. replication_applier_status_by_worker表

举例从库是单线程,则该表记录一条WOXC60KE帕杰罗_ID=0的SQL线程的事态。假若从库是二十四线程,则该表记录系统参数slave_parallel_workers钦定个数的职业线程状态(WORubiconKE哈弗_ID从1早先编号),此时协和器/SQL线程状态记录在replication_applier_status_by_coordinator表,每二个坦途都有自个儿单身的干活线程和和煦器线程(每一种通道的职业线程个数由slave_parallel_workers参数变量钦点,借使是MGQashqai集群时,则该表中著录的干活线程记录为slave_parallel_workers个group_replication_applier线程+1个group_replication_recovery线程),我们先来看望表中著录的计算新闻是怎样子的。

# 单线程主从复制时表中著录的故事情节如下

root@localhost : performance_schema 12:46:10> select * from
replication_applier_status_by_worker;

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

| CHANNEL_NAME |WORKER_ID | THREAD_ID |SERVICE_STATE |
LAST_SEEN_TRANSACTION |LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE
|LAST_ERROR_TIMESTAMP |

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

|| 0 |82| ON || 0 || 0000-00-00 00:00:00 |

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

1row inset ( 0. 00sec)

#
10二线程主从复制时表中的记录内容如下(假设是多主复制,则每一种复制通道记录slave_parallel_workers参数钦点个数的worker线程音信)

admin@localhost : performance_schema 02:50:18> select * from
replication_applier_status_by_worker;

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

| CHANNEL_NAME |WORKER_ID | THREAD_ID |SERVICE_STATE |
LAST_SEEN_TRANSACTION |LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE
|LAST_ERROR_TIMESTAMP |

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

|| 1 |44| ON || 0 || 0000-00-00 00:00:00 |

| |2| 45 |ON | |0| |0000- 00- 0000:00:00|

|| 3 |46| ON || 0 || 0000-00-00 00:00:00 |

| |4| 47 |ON | |0| |0000- 00- 0000:00:00|

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

4 rows inset (0.00 sec)

# 借使是MG普拉多集群,则该表中会记录类似如下MG路虎极光集群音信

root@localhost : performance_schema 11:00:16> select * from
replication_applier_status_by_worker;

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

|CHANNEL_NAME | WORKER_ID |THREAD_ID | SERVICE_STATE
|LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER |LAST_ERROR_MESSAGE |
LAST_ERROR_TIMESTAMP |

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

| group_replication_recovery |0| NULL |OFF | |0| |0000- 00-
0000:00:00|

|group_replication_applier | 1 |92| ON |aaaaaaaa-aaaa-aaaa-aaaa-
aaaaaaaaaaaa:104099082| 0 || 0000-00-00 00:00:00 |

| group_replication_applier |2| 93 |ON | |0| |0000- 00- 0000:00:00|

……

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

17 rows inset (0.00 sec)

表中各字段含义及与show slave
status输出字段对应关系如下:

图片 6

图片 7

图片 8

图片 9

图片 10

对于replication_applier_status_by_worker表,不容许施行TRUNCATE
TABLE语句。

5. replication_connection_configuration表

该表中著录从库用于连接到主库的安排参数,该表中存款和储蓄的安排音信在施行change
master语句时会被修改

咱俩先来看看表中著录的总计新闻是怎么着子的。

#
单线程、多线程主从复制时表中著录的始末壹致,假如是多主复制,则每一种复制通道分别有壹行记录消息

admin@localhost : performance _schema 02:51:00> select * from
replication_connection_configurationG;

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

CHANNEL_NAME:

HOST: 10.10.20.14

PORT: 3306

USER: qfsys

NETWORK_INTERFACE:

AUTO_POSITION: 1

SSL_ALLOWED: NO

SSL _CA_FILE:

SSL _CA_PATH:

SSL_CERTIFICATE:

SSL_CIPHER:

SSL_KEY:

SSL _VERIFY_SERVER_CERTIFICATE: NO

SSL _CRL_FILE:

SSL _CRL_PATH:

CONNECTION _RETRY_INTERVAL: 60

CONNECTION _RETRY_COUNT: 86400

HEARTBEAT_INTERVAL: 5.000

TLS_VERSION:

1 row in set (0.00 sec)

# 假使是MG奥德赛集群,则该表中会记录类似如下MG索罗德集群音讯

root@localhost : performance _schema 11:02:03> select * from
replication_connection_configurationG

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

CHANNEL _NAME: group_replication_applier

HOST: <NULL>

……

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

CHANNEL _NAME: group_replication_recovery

HOST: <NULL>

……

2 rows in set (0.00 sec)

表中各字段含义以及与change master
to语句的选拔对应关系如下:

图片 11

图片 12

注意:对于replication_connection_configuration表,不容许实践TRUNCATE
TABLE语句。

6. replication_connection_status表

该表中记录的是从库IO线程的连日景况音信(也记录组复制架构中此外节点的连年消息,组复制架构中二个节点参加集群此前的数据须求运用异步复制通道实行数量同步,组复制的异步复制通道音讯在show
slave
status中不可知),大家先来看望表中著录的总计消息是何等样子的。

#
二10拾2线程和单线程主从复制时表中著录壹致,假设是多主复制,则每一种复制通道在表中个记录一行音信

root@localhost : performance _schema 12:55:26> select * from
replication_connection_statusG

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

CHANNEL_NAME:

GROUP_NAME:

SOURCE_UUID: ec123678-5e26-11e7-9d38-000c295e08a0

THREAD_ID: 101

SERVICE_STATE: ON

COUNT _RECEIVED_HEARTBEATS: 136

LAST _HEARTBEAT_TIMESTAMP: 2018-06-12 00:55:22

RECEIVED _TRANSACTION_SET:

LAST _ERROR_NUMBER: 0

LAST _ERROR_MESSAGE:

LAST _ERROR_TIMESTAMP: 0000-00-00 00:00:00

1 row in set (0.00 sec)

# 要是是MGCR-V集群,则该表中会记录类似如下MG陆风X8集群消息

root@localhost : performance _schema 10:56:40> select * from
replication_connection_statusG

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

CHANNEL _NAME: group_replication_applier

GROUP_NAME: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa

SOURCE_UUID: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa

THREAD_ID: NULL

SERVICE_STATE: ON

COUNT _RECEIVED_HEARTBEATS: 0

LAST _HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00

RECEIVED _TRANSACTION_SET:
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:104099082

LAST _ERROR_NUMBER: 0

LAST _ERROR_MESSAGE:

LAST _ERROR_TIMESTAMP: 0000-00-00 00:00:00

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

CHANNEL _NAME: group_replication_recovery

……

2 rows in set (0.00 sec)

表中各字段含义及与show slave
status输出字段对应关系如下:

图片 13

对于replication_connection_status表,不容许施行TRUNCATE
TABLE语句。

7. replication_group_member_stats表

该表中著录了MySQL组复制成员的总括音讯。仅在组复制组件运维时表中才会有记录,我们先来看看表中记录的总结音信是哪些样子的。

root@localhost : performance _schema 11:02:10> select * from
replication_group _member_statsG

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

CHANNEL _NAME: group_replication_applier

VIEW_ID: 15287289928409067:1

MEMBER_ID: 5d78a458-30d2-11e8-a66f-5254002a54f2

COUNT _TRANSACTIONS_IN_QUEUE: 0

COUNT _TRANSACTIONS_CHECKED: 0

COUNT _CONFLICTS_DETECTED: 0

COUNT _TRANSACTIONS_ROWS_VALIDATING: 0

TRANSACTIONS _COMMITTED_ALL_MEMBERS:
0a1e8349-2e87-11e8-8c9f-525400bdd1f2:1-148826,

2d623f55-2111-11e8-9cc3-0025905b06da:1-2,

aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-104099082

LAST _CONFLICT_FREE_TRANSACTION:

1 row in set (0.00 sec)

表中各字段含义如下:

对于replication_group_member_stats表,不容许实施TRUNCATE
TABLE语句。

8. replication_group_members表

该表记录组复制架构中,组成员的网络和景色新闻。仅在组复制组件运营时表中才会有记录,大家先来看看表中著录的总结新闻是什么样子的。

root@localhost : performance_schema 11:03:38> select * from
replication_group_members;

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

| CHANNEL_NAME |MEMBER_ID | MEMBER_HOST |MEMBER_PORT | MEMBER_STATE
|

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

| group_replication_applier |5d78a458- 30d2- 11e8-a66f- 5254002a54f2 |
node1 |3306| ONLINE |

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

1row inset ( 0. 00sec)

表中各字段含义如下:

对于replication_group_members表,不允许实践TRUNCATE
TABLE语句。

02

用户自定义变量记录表

performance_schema提供了三个封存用户定义变量的user_variables_by_thread表(该表也保留由mysql内部连接线程创造的变量)。那几个变量是在特定会话中定义的变量,变量名由@字符开端。

咱俩先来探望表中记录的总计新闻是怎么样体统的。

admin@localhost : performance_schema 01:50:16> select * from
user_variables_by_thread;

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

| THREAD_ID |VARIABLE_NAME | VARIABLE_VALUE |

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

| 45 |slave_uuid | 4b0027eb-6223-11e7-94ad-525400950aac |

| 45 |master_heartbeat_period | 5000000000 |

| 45 |master_binlog_checksum | CRC32 |

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

3rows inset ( 0. 01sec)

表中各字段含义如下:

user_variables_by_thread表不一致意使用TRUNCATE
TABLE语句

03

system variables记录表

MySQL
server维护着广大系统变量,在performance_schema中提供了对全局、当前对话、以及依照线程分组的连串变量新闻记录表:

大家先来看望表中记录的总括消息是怎么体统的。

# global_variables表

admin@localhost : performance_schema 09 :50:31> select * from
global_variables limit 5;

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

| VARIABLE_NAME |VARIABLE_VALUE |

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

|auto_increment_increment | 2 |

| auto_increment_offset |2|

……

5 rows inset (0.01 sec)

# session_variables表(查询结果与global_variables 表类似)

admin@localhost : performance_schema 09:50:40> select * from
session_variables limit 5;

………….

# variables_by_thread表

admin@localhost : performance_schema 09:50:52> select * from
variables_by_thread limit 5; # 能够见到比前边两张表多了个THREAD_ID
字段来记录线程ID

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

|THREAD_ID | VARIABLE_NAME |VARIABLE_VALUE |

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

|45| auto_increment_increment |2|

|45| auto_increment_offset |2|

……

5 rows inset (0.00 sec)

global_variables和session_variables表字段含义如下:

variables_by_thread表字段含义如下:

performance_schema记录系统变量的那个表不帮助TRUNCATE
TABLE语句

PS:

04

status variables统计表

MySQL
server维护着累累状态变量,提供有关其内部有关操作的音信。如下一些performance_schema表中记录着状态变量新闻:

我们先来探视表中著录的计算新闻是怎样体统的。

# global_status表

admin@localhost : performance_schema 11:01:51> select * from
global_status limit 5;

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

| VARIABLE_NAME |VARIABLE_VALUE |

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

|Aborted_clients | 0 |

| Aborted_connects |0|

……

5 rows inset (0.00 sec)

# session_status表(记录内容与global_status 表类似)

admin@localhost : performance_schema 11:02:21> select * from
session_status limit 5;

…………

# status_by_thread 表

admin@localhost : performance_schema 11:02:49> select * from
status_by_thread limit 5;

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

|THREAD_ID | VARIABLE_NAME |VARIABLE_VALUE |

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

|45| Bytes_received |0|

|45| Bytes_sent |2901|

……

5 rows inset (0.00 sec)

global_status和session_status表字段含义如下:

status_by_thread表包罗每一种活跃线程的事态。字段含义如下:

performance_schema允许对那些状态变量消息总计表试行TRUNCATE
TABLE语句:

FLUSH
STATUS语句会把全数活跃会话的场地变量值聚合到全局状态变量值中,然后重新载入参数全数活跃会话的状态变量值,并在account,host和user状态变量对应的总结表中重新恢复设置已断开连接的状态变量聚合值。

PS:

05

依照帐号、主机、用户总括的状态变量总括表

依据帐号、主机名、用户名叫分组对状态变量举办归类数据,举个例子:根据帐号表计算的表分组列为host和user列,聚合列当然正是状态变量本身(该意义是MySQL
5.柒版本新添的),有如下几张表:

大家先来看望表中著录的总括消息是什么体统的。

# status_by_account表

admin@localhost : performance_schema 04:08 :36> select * from
status_by_account where USER is notnull limit 5;

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

| USER |HOST | VARIABLE_NAME |VARIABLE_VALUE |

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

|admin | localhost |Bytes_received | 6049 |

| admin |localhost | Bytes_sent |305705|

…….

5 rows inset (0.00 sec)

# status_by_host表

admin@localhost : performance_schema 04:08:43> select * from
status_by_host where HOST is notnull limit 5;

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

|HOST | VARIABLE_NAME |VARIABLE_VALUE |

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

|localhost | Bytes_received |6113|

|localhost | Bytes_sent |306310|

……

5 rows inset (0.00 sec)

# status_by_user表

admin@localhost : performance_schema 04:08:58> select * from
status_by_user where USER is notnull limit 5;

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

|USER | VARIABLE_NAME |VARIABLE_VALUE |

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

|admin | Bytes_received |6177|

|admin | Bytes_sent |306781|

……

5 rows inset (0.00 sec)

表中各字段含义

状态变量摘要表允许推行TRUNCATE
TABLE语句,试行truncate语句时活动会话的状态变量不受影响:

FLUSH
STATUS将会话状态从全部活动会话增多到全局状态变量,然后重新载入参数全部移动会话的状态变量值,并在遵从account、host、user分类聚合表中重新恢复设置已断开连接的景观变量值。

PS:

06

host_cache表

host_cache表保存连接到server的主机相关音讯缓存,当中含有客户机主机名和IP地址消息,能够用来制止DNS查找。该表能够动用SELECT语句实行询问,但要求在server运行此前开启performance_schema参数,不然表记录为空。

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

root@ localhost: performance_schema 10: 35: 47> select * from
host_cacheG;

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

IP: 192 .168.2.122

HOST: NULL

HOST_VALIDATED: YES

SUM_CONNECT_ERRORS: 0

COUNT_HOST_BLOCKED_ERRORS: 0

COUNT_NAMEINFO_TRANSIENT_ERRORS: 0

COUNT_NAMEINFO_PERMANENT_ERRORS: 1

COUNT_FORMAT_ERRORS: 0

COUNT_ADDRINFO_TRANSIENT_ERRORS: 0

COUNT_ADDRINFO_PERMANENT_ERRORS: 0

COUNT_FCRDNS_ERRORS: 0

COUNT_HOST_ACL_ERRORS: 0

COUNT_NO_AUTH_PLUGIN_ERRORS: 0

COUNT_AUTH_PLUGIN_ERRORS: 0

COUNT_HANDSHAKE_ERRORS: 0

COUNT_PROXY_USER_ERRORS: 0

COUNT_PROXY_USER_ACL_ERRORS: 0

COUNT_AUTHENTICATION_ERRORS: 0

COUNT_SSL_ERRORS: 0

COUNT_MAX_USER_CONNECTIONS_ERRORS: 0

COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS: 0

COUNT_DEFAULT_DATABASE_ERRORS: 0

COUNT_INIT_CONNECT_ERRORS: 0

COUNT_LOCAL_ERRORS: 0

COUNT_UNKNOWN_ERRORS: 0

FIRST_SEEN: 2017 -12-3022 :34:51

LAST_SEEN: 2017 -12-3022 :35:29

FIRST_ERROR_SEEN: 2017 -12-3022 :34:51

LAST_ERROR_SEEN: 2017 -12-3022 :34:51

1 rowinset(0 .00sec)

表中各字段含义如下:

FLUSH HOSTS和TRUNCATE TABLE
host_cache具备同等的功能:它们清除主机缓存。host_cache表被清空并化解阻塞任何因为漏洞百出记录数据超越限制而被堵塞的主机连接。FLUSH
HOSTS必要RELOAD权限。 TRUNCATE TABLE需求host_cache表的DROP权限。

PS:万壹开发银行选项 skip_name_resolve
设置为ON,则该表不记录任何音信,因为该表的功力就是用来幸免、加快域名解析用于,跳过域名解析效能时则该表记录的新闻用途相当小。

– END –重临腾讯网,查看越来越多

主要编辑:

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图