| EVENT |% | % |YES | YES |

MySQL Performance-Schema(一) 配置表,performanceschema

      performance-schema最早在MYSQL
5.5中现身,而近日5.6,5.7中performance-Schema又增添了越来越多的监察项,总计消息也更丰硕,越来越有ORACLE-AW揽胜极光计算新闻的赶脚,真乃DBA童鞋举行品质检查判断分析的福音。本文首要讲Performance-Schema中的配置表,通过安排表能大致驾驭performance-schema的全貌,为一而再使用和深深明白做准备。

配置表

Performance-Schema中重大有六个布局表,具体如下:

[email protected]_schema
06:03:09>show tables like ‘%setup%’;
+—————————————-+
| Tables_in_performance_schema (%setup%) |
+—————————————-+
| setup_actors |
| setup_consumers |
| setup_instruments |
| setup_objects |
| setup_timers |
+—————————————-+

1.setup_actors用于配置user维度的监督,暗许景况下监察和控制全部用户线程。
[email protected]_schema
05:47:27>select * from setup_actors;
+——+——+——+
| HOST | USER | ROLE |
+——+——+——+
| % | % | % |
+——+——+——+

2.setup_consumers表用于配置事件的消费者类型,即搜集的事件结尾会写入到哪些总括表中。
[email protected]_schema
05:48:16>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 | NO |
| events_statements_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 |
+——————————–+———+
能够观望有十二个consumer,借使不想关心有个别consumer,能够将ENABLED设置为NO,比如events_statements_history_long设置为NO,
则收罗事件不会写入到对应的表events_statements_history_long中。13个consumer不是平级的,存在多种层次关系。具体如下表:
global_instrumentation
 |– thread_instrumentation
   |– events_waits_current
     |– events_waits_history
     |– events_waits_history_long
   |– events_stages_current
     |– events_stages_history
     |– events_stages_history_long
   |– events_statements_current
     |– events_statements_history
     |– events_statements_history_long
 |– statements_digest

多层次的consumer遵从3个骨干标准,只有上1层次的为YES,才会持续检查该本层为YES
or
NO。global_instrumentation是最高档别consumer,假设它设置为NO,则有所的consumer都会忽视。纵然只开垦global_instrumentation,而停业全体别的子consumer(设置为NO),则只收罗全局维度的总计消息,比如xxx_instance表,而不会征集用户维度,语句维度的音讯。第1层次的是thread_instrumentation,用户线程维度的总计音信,比如xxx_by_thread表,此外三个是statements_digest,这几个用于全局总括SQL-digest的音讯。第3层次是语句维度,包罗events_waits_current,events_stages_current和events_statements_current,分别用于计算wait,stages和statement音讯,第四层次是历史表新闻,首要回顾xxx_history和xxx_history_long。

3.setup_instruments表用于配置一条条具体的instrument,主要含有4大类:idle,stage/xxx,statement/xxx,wait/xxx.
[email protected]_schema
06:25:50>select name,count(*) from setup_instruments group by
LEFT(name,5);
+———————————+———-+
| name | count(*) |
+———————————+———-+
| idle | 1 |
| stage/sql/After create | 111 |
| statement/sql/select | 170 |
| wait/synch/mutex/sql/PAGE::lock | 296 |
+———————————+———-+
idle表示socket空闲的小时,stage类表示语句的每一个执行阶段的总括,statement类总括语句维度的音讯,wait类总计种种等待事件,比如IO,mutux,spin_lock,condition等。从上表计算结果来看,能够基本看到每类的instrument数目,stage包涵1十一个,statement包括一67个,wait蕴涵2玖八个。

4.setup_objects表用于配置监察和控制对象,私下认可情状下具备mysql,performance_schema和information_schema中的表都不监察和控制。而别的DB的有着表都监察和控制。

[email protected]_schema
06:25:55>select * from setup_objects;
+————-+——————–+————-+———+——-+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |
+————-+——————–+————-+———+——-+
| TABLE | mysql | % | NO | NO |
| TABLE | performance_schema | % | NO | NO |
| TABLE | information_schema | % | NO | NO |
| TABLE | % | % | YES | YES |
+————-+——————–+————-+———+——-+

5.setup_timers表用于配置每连串型指令的总计时间单位。MICROSECOND表示总结单位是神秘,CYCLE表示总括单位是挂钟周期,时间衡量与CPU的主频有关,NANOSECOND表示总计单位是皮秒,关于每类别型的现实性意思,能够参照performance_timer那么些表。由于wait类包罗的皆以伺机事件,单个SQL调用次数相比多,因而选用代价最小的胸襟单位cycle。但不论是使用哪类衡量单位,最后总计表中执会调查总结局计的时光都会装换成阿秒。

[email protected]_schema
06:29:50>select \
from setup_timers;
+———–+————-+
| NAME | TIMER_NAME |
+———–+————-+
| idle | MICROSECOND |
| wait | CYCLE |
| stage | NANOSECOND |
| statement | NANOSECOND |
+———–+————-+*

配置方式

**     
暗中同意情形下,setup_instruments表只开垦了statement和wait/io部分的命令,setup_consumer表中许多consumer也并未有张开。为了开荒须要的选项,能够透过update语句直接修改配置表,并且修改后方可及时生效,但那种方法必需得运维服务器后才得以修改,并且不只怕持久化,重启后,又得重置2遍。从伍.陆.四始发提供了my.cnf的布局方式,格式如下:

一.安装搜罗的instrument
performance_schema_instrument=’instrument_name=value’
(一)展开wait类型的指令
performance_schema_instrument=’wait/%’
(2)张开装有指令
performance_schema_instrument=’%=on’

2.设置consumer
performance_schema_consumer_xxx=value
(1)打开 events_waits_history consumer

performance_schema_consumer_events_waits_current=on

performance_schema_consumer_events_waits_history=on

那里要留意consumer的层次关系, events_waits_history处于第陆层,由此设置它时,要保管events_statements_current,thread_instrumentation和global_instrumentation的ENABLED状态都为YES,技艺见效。由于私下认可thread_instrumentation和global_instrumentation都以YES,由此只供给呈现设置events_waits_current和events_waits_current即可。

三.装置计算表大小
所有的performance_schema表均采取PETiggoFO奥迪Q三MANCE_SCHEMA存款和储蓄引擎,表中的具备数据只存在内部存款和储蓄器,表的高低在系统初阶化时曾经
确定地点好,因而据有的内部存款和储蓄器是迟早的。能够透过计划来定制具体每一个表的记录数。
performance_schema_events_waits_history_size=20
performance_schema_events_waits_history_long_size=15000

 

Performance-Schema(一)
配置表,performanceschema performance-schema最早在MYSQL
5.第55中学出现,而近日5.六,5.柒中performance-Schema又增加了越多的督察项,统…

MySQL Performance-Schema(一) 配置表

performance-schema最早在MYSQL
5.5中出现,最近后5.陆,五.七中performance-Schema又增加了越来越多的监察项,总结新闻也更丰硕,越来越有ORACLE-AWXC90总结音信的赶脚,真乃DBA童鞋进行质量检查判断分析的佛法。本文首要讲Performance-Schema中的配置表,通过布置表能大约领会performance-schema的全貌,为承继使用和深深领会做准备。

 

配置表

 

Performance-Schema中最主要有八个布局表,具体如下:

 

[email protected]_schema
06:03:09>show tables like ‘%setup%’;

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

| Tables_in_performance_schema (%setup%) |

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

| setup_actors |

| setup_consumers |

| setup_instruments |

| setup_objects |

| setup_timers |

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

 

1.setup_actors用于配置user维度的督察,默许景况下监察和控制全体用户线程。

[email protected]_schema
05:47:27>select * from setup_actors;

+——+——+——+

| HOST | USER | ROLE |

+——+——+——+

| % | % | % |

+——+——+——+

 

2.setup_consumers表用于配置事件的主顾类型,即搜集的事件结尾会写入到哪些总计表中。

[email protected]_schema
05:48:16>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 | NO |

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

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

能够看看有11个consumer,要是不想关怀有些consumer,可以将ENABLED设置为NO,比如events_statements_history_long设置为NO,

则搜聚事件不会写入到相应的表events_statements_history_long中。拾2个consumer不是平级的,存在多种层次关系。具体如下表:

global_instrumentation 

 |– thread_instrumentation

   |– events_waits_current

     |– events_waits_history

     |– events_waits_history_long

   |– events_stages_current

     |– events_stages_history

     |– events_stages_history_long

   |– events_statements_current

     |– events_statements_history

     |– events_statements_history_long

 |– statements_digest

 

多层次的consumer遵守一个基本标准,只有上1层次的为YES,才会一连检查该本层为YES
or
NO。global_instrumentation是最高等别consumer,若是它设置为NO,则装有的consumer都会忽略。如若只开采global_instrumentation,而关门大吉全数别的子consumer(设置为NO),则只搜聚全局维度的总括消息,比如xxx_instance表,而不会搜罗用户维度,语句维度的音信。第三层次的是thread_instrumentation,用户线程维度的总括消息,比如xxx_by_thread表,其它三个是statements_digest,这么些用于全局总计SQL-digest的音信。第一层次是语句维度,包涵events_waits_current,events_stages_current和events_statements_current,分别用于总计wait,stages和statement消息,第四层次是历史表新闻,首要包含xxx_history和xxx_history_long。

 

3.setup_instruments表用于配置一条条实际的instrument,主要含有四大类:idle,stage/xxx,statement/xxx,wait/xxx.

[email protected]_schema
06:25:50>select name,count(*) from setup_instruments group by
LEFT(name,5);

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

| name | count(*) |

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

| idle | 1 |

| stage/sql/After create | 111 |

| statement/sql/select | 170 |

| wait/synch/mutex/sql/PAGE::lock | 296 |

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

 

idle表示socket空闲的时间,stage类表示语句的种种推行阶段的总括,statement类总计语句维度的新闻,wait类总计各类等待事件,比如IO,mutux,spin_lock,condition等。从上表总括结果来看,能够着力看到每类的instrument数目,stage包罗1十二个,statement包涵17十三个,wait包罗29陆个。

 

4.setup_objects表用于配置监察和控制指标,私下认可意况下有所mysql,performance_schema和information_schema中的表都不监察和控制。而其余DB的装有表都监控。

 

[email protected]_schema
06:25:55>select * from setup_objects;

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

| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |

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

| TABLE | mysql | % | NO | NO |

| TABLE | performance_schema | % | NO | NO |

| TABLE | information_schema | % | NO | NO |

| TABLE | % | % | YES | YES |

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

 

5.setup_timers表用于配置每连串型指令的总计时间单位。MICROSECOND表示总括单位是微妙,CYCLE表示总计单位是石英钟周期,时间衡量与CPU的主频有关,NANOSECOND表示总计单位是皮秒,关于每连串型的实际意思,能够参照performance_timer这些表。由于wait类包罗的都以伺机事件,单个SQL调用次数比较多,因此挑选代价最小的襟怀单位cycle。但随便选用哪一种度量单位,最终总结表中执会考察总计局计的时刻都会装换来纳秒。

 

[email protected]_schema
06:29:50>select * from setup_timers;

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

| NAME | TIMER_NAME |

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

| idle | MICROSECOND |

| wait | CYCLE |

| stage | NANOSECOND |

| statement | NANOSECOND |

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

 

布局格局

 

默许意况下,setup_instruments表只开垦了statement和wait/io部分的通令,setup_consumer表中多数consumer也一向不打开。为了展开须要的选项,能够经过update语句直接修改配置表,并且修改后能够即时生效,但那种措施必需得运维服务器后才方可修改,并且无法持久化,重启后,又得重新安装一回。从5.六.肆方始提供了my.cnf的布署格局,格式如下:

 

一.装置收罗的instrument

performance_schema_instrument=’instrument_name=value’

(壹)展开wait类型的一声令下

performance_schema_instrument=’wait/%’

(二)张开装有指令

performance_schema_instrument=’%=on’

 

2.设置consumer

performance_schema_consumer_xxx=value

(1)打开 events_waits_history consumer

 

performance_schema_consumer_events_waits_current=on

 

performance_schema_consumer_events_waits_history=on

 

此处要专注consumer的层系关系,
events_waits_history处于第六层,由此设置它时,要力保events_statements_current,thread_instrumentation和global_instrumentation的ENABLED状态都为YES,技艺奏效。由于默许thread_instrumentation和global_instrumentation都是YES,因而只必要呈现设置events_waits_current和events_waits_current即可。

 

叁.设置总括表大小

所有的performance_schema表均采纳PEGL450FO奥迪Q3MANCE_SCHEMA存款和储蓄引擎,表中的拥有数据只设有内部存款和储蓄器,表的轻重缓急在系统发轫化时1度

一向好,由此占领的内部存款和储蓄器是毫无疑问的。能够因此安插来定制具体每一个表的记录数。

performance_schema_events_waits_history_size=20

performance_schema_events_waits_history_long_size=15000

Performance-Schema(一) 配置表
performance-schema最早在MYSQL
伍.5中出现,而现行5.6,5.7中performance-Schema又增多了越多的督察项,总结音信也更充足…

Performance-Schema中驷不比舌有多少个布局表,具体如下:

上面,大家将对那么些system
variables(以下称为变量)中多少个供给关注的拓展简短表达(当中绝大繁多变量是-一值,代表会自动调节,无需太多关心,此外,大于-一值的变量在大部时候也够用,若是无尤其须要,不建议调节,调控那几个参数会大增内部存款和储蓄器使用量)

一.安装搜集的instrument
performance_schema_instrument=’instrument_name=value’
(1)展开wait类型的吩咐
performance_schema_instrument=’wait/%’
(贰)展开装有指令
performance_schema_instrument=’%=on’

三).
wait/synch/rwlock:三个线程使用二个读写锁对象对某些特定变量进行锁定,以免止其余线程同时做客,对于利用共享读锁锁定的能源,四个线程能够而且做客,对于利用独占写锁锁定的财富,唯有3个线程能同时做客,该instruments用于搜集发生读写锁锁按期的轩然大波新闻

 

–performance_schema_events_waits_history_long_size= #

root@performance_schema
06:29:50>select \
from setup_timers;
+———–+————-+
| NAME | TIMER_NAME |
+———–+————-+
| idle | MICROSECOND |
| wait | CYCLE |
| stage | NANOSECOND |
| statement | NANOSECOND |
+———–+————-+*

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

      performance-schema最早在MYSQL
5.5中冒出,而明日伍.6,5.七中performance-Schema又增添了更加多的监察和控制项,总括新闻也更丰盛,越来越有ORACLE-AW昂科拉总结新闻的赶脚,真乃DBA童鞋进行质量会诊分析的福音。本文首要讲Performance-Schema中的配置表,通过配备表能大约通晓performance-schema的全貌,为承继使用和深切理解做准备。

在上1篇 《初相识 |
performance_schema全方位介绍》
中简易介绍了何等安顿与应用performance_schema,相信大家对performance_schema可认为我们提供哪些的个性数据现已有3个发端的认识,明天将指导大家一齐踏上层层第3篇的道路(全系共8个篇章),在那壹期里,大家将为我们无微不至授课performance_schema配置方式以及各种配置表的效果。下边,请跟随大家1道开头performance_schema系统的读书之旅吧。

4.setup_objects表用于配置监察和控制对象,暗中认可景况下具有mysql,performance_schema和information_schema中的表都不监察和控制。而其余DB的享有表都监控。

(6)setup_objects表

多层次的consumer遵守贰个为主条件,唯有上壹层次的为YES,才会一连检查该本层为YES
or NO。global_instrumentation是最高端别consumer,借使它设置为NO,则装有的consumer都会忽略。如若只开荒global_instrumentation,而关门大吉全部别的子consumer(设置为NO),则只搜罗全局维度的总计消息,比如xxx_instance表,而不会搜聚用户维度,语句维度的新闻。第二层次的是thread_instrumentation,用户线程维度的总计音讯,比如xxx_by_thread表,别的一个是statements_digest,那一个用于全局计算SQL-digest的音讯。第二层次是语句维度,包含events_waits_current,events_stages_current和events_statements_current,分别用于总计wait,stages和statement消息,第伍层次是历史表新闻,主要不外乎xxx_history和xxx_history_long。

root@performance_schema
06:25:55>select * from setup_objects;
+————-+——————–+————-+———+——-+
| OBJECT_TYPE | OBJECT_SCHEMA |
OBJECT_NAME | ENABLED | TIMED |
+————-+——————–+————-+———+——-+
| TABLE | mysql | % | NO | NO |
| TABLE | performance_schema | % | NO |
NO |
| TABLE | information_schema | % | NO |
NO |
| TABLE | % | % | YES | YES |
+————-+——————–+————-+———+——-+

performance-schema-consumer-events-statements-current TRUE

performance_schema_consumer_events_waits_current=on

–performance_schema

root@performance_schema 06:03:09>show
tables like ‘%setup%’;
+—————————————-+
| Tables_in_performance_schema (%setup%) |
+—————————————-+
| setup_actors |
| setup_consumers |
| setup_instruments |
| setup_objects |
| setup_timers |
+—————————————-+

与performance_schema_consumer_events_statements_current选项类似,但该选用是用以配置是或不是记录语句事件短历史音讯,默以为TRUE

2.setup_consumers表用于配置事件的主顾类型,即搜聚的轩然大波结尾会写入到何以计算表中。
root@performance_schema
05:48:16>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 | NO
|
| events_statements_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 |
+——————————–+———+
能够看来有10个consumer,假如不想关切有些consumer,能够将ENABLED设置为NO,比如events_statements_history_long设置为NO,
则收罗事件不会写入到对应的表events_statements_history_long中。十一个consumer不是平级的,存在壹种类层次关系。具体如下表:
global_instrumentation
 |– thread_instrumentation
   |– events_waits_current
     |– events_waits_history
     |–
events_waits_history_long
   |– events_stages_current
     |– events_stages_history
     |–
events_stages_history_long
   |–
events_statements_current
     |–
events_statements_history
     |–
events_statements_history_long
 |– statements_digest

| PROCEDURE |information_schema | % |NO | NO |

5.setup_timers表用于配置每类别型指令的总计时间单位。MICROSECOND表示总结单位是微妙,CYCLE表示总计单位是时钟周期,时间衡量与CPU的主频有关,NANOSECOND表示总计单位是阿秒,关于每系列型的切实可行意思,能够参考performance_timer那些表。由于wait类包涵的都是等待事件,单个SQL调用次数相比多,由此挑选代价最小的胸怀单位cycle。但无论采用哪一类衡量单位,最终计算表中执会调查总结局计的时刻都会装换成飞秒。

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

1.setup_actors用于配置user维度的监察,暗中同意意况下监察和控制全体用户线程。
root@performance_schema
05:47:27>select * from setup_actors;
+——+——+——+
| HOST | USER | ROLE |
+——+——+——+
| % | % | % |
+——+——+——+

  • performance_schema_instrument[=name]

计划方式

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

那边要留意consumer的层系关系, events_waits_history处于第五层,由此设置它时,要保管events_statements_current,thread_instrumentation和global_instrumentation的ENABLED状态都为YES,工夫见效。由于暗许thread_instrumentation和global_instrumentation都以YES,因而只供给显示设置events_waits_current和events_waits_current即可。

PROCESSLIST_STATE: Suspending

三.安装总结表大小
所有的performance_schema表均接纳PELX570FO福睿斯MANCE_SCHEMA存款和储蓄引擎,表中的全部数据只存在内部存款和储蓄器,表的大大小小在系统起初化时一度
定点好,由此占领的内部存款和储蓄器是毫无疑问的。可以因而布署来定制具体种种表的记录数。
performance_schema_events_waits_history_size=20
performance_schema_events_waits_history_long_size=15000

  • 示例,假如setup_actors表中有如下HOST和USE瑞鹰值: * USER =’literal’
    and HOST =’literal’ * USER =’literal’ and HOST =’%’ * USER =’%’
    and HOST =’literal’ * USER =’%’ and HOST =’%’
  • 格外顺序很重要,因为分化的协作行也许具有不一样的USELacrosse和HOST值(mysql中对于用户帐号是利用user@host举行区分的),依照相称行的ENABLED和HISTO揽胜Y列值来决定对各样HOST,USE凯雷德或ACCOUNT(USE冠道和HOST组合,如:user@host)对应的线程在threads表中变化对应的相称行的ENABLED和HISTO本田CR-VY列值
    ,以便调整是或不是启用相应的instruments和历史事件记录,类似如下: *
    当在setup_actors表中的最好相称行的ENABLED =
    YES时,threads表中对应线程的配置行中INSTRUMENTED列值将变为YES,HISTOENVISIONY
    列同理 * 当在setup_actors表中的最棒相称行的ENABLED =
    NO时,threads表中对应线程的安插行中INSTRUMENTED列值将产生NO,HISTO路虎极光Y
    列同理 *
    当在setup_actors表中找不到至极时,threads表中对应线程的布局行中INSTRUMENTED和HISTO途达Y值值将造成NO *
    setup_actors表配置行中的ENABLED和HISTOPAJEROY列值可以互相独立设置为YES或NO,互不影响,1个是是不是启用线程对应的instruments,二个是是还是不是启用线程相关的野史事件记录的consumers
  • 私下认可情形下,全体新的前台线程启用instruments和历史事件采访,因为setup_actors表中的预设值是host=’%’,user=’%’,ENABLED=’YES’,HISTOOdysseyY=’YES’的。若是要实施更精细的十分(例如仅对少数前台线程进行蹲点),这就务供给对该表中的私下认可值举行修改,如下:

配置表

(2) system variables

2.设置consumer
performance_schema_consumer_xxx=value
(1)打开 events_waits_history
consumer

纵然用户对该表具备INSERT和DELETE权限,则能够对该表中的配置行开始展览删减和插入新的配置行。对于已经存在的计划行,假若用户对该表具备UPDATE权限,则足以修改ENABLED和TIMED列,有效值为:YES和NO

performance_schema_consumer_events_waits_history=on

performance_schema_events_statements_history_size=10

3.setup_instruments表用于配置一条条实际的instrument,主要含有④大类:idle,stage/xxx,statement/xxx,wait/xxx.
root@performance_schema
06:25:50>select name,count(*) from setup_instruments group by
LEFT(name,5);
+———————————+———-+
| name | count(*) |
+———————————+———-+
| idle | 1 |
| stage/sql/After create | 111 |
| statement/sql/select | 170 |
| wait/synch/mutex/sql/PAGE::lock | 296
|
+———————————+———-+
idle表示socket空闲的日子,stage类表示语句的各种试行阶段的总结,statement类总计语句维度的音讯,wait类总结各类等待事件,比如IO,mutux,spin_lock,condition等。从上表计算结果来看,能够主导看到每类的instrument数目,stage包蕴1十一个,statement包涵17八个,wait包罗2玖四个。

| PROCEDURE |mysql | % |NO | NO |

**     
暗中同意情状下,setup_instruments表只开拓了statement和wait/io部分的吩咐,setup_consumer表中有的是consumer也未曾张开。为了张开须求的选项,可以通过update语句直接修改配置表,并且修改后得以即时生效,但那种措施必需得运维服务器后才足以修改,并且不可能持久化,重启后,又得重新安装二回。从伍.陆.4开端提供了my.cnf的安顿方式,格式如下:

| statement |NANOSECOND |

| wait/synch/rwlock/sql/LOCK_grant |YES | YES |

setup_consumers表中的consumers配置项具有层级关系,具有从较高等别到较低等其他层次结构,遵照事先级依次,可列举为如下层次结构(你能够依照这几个层次结构,关闭你只怕不必要的较低等其他consumers,那样有助于节省质量费用,且持续查看搜集的轩然大波消息时也有利于实行筛选):

(3) setup_consumers表

对此内部存款和储蓄器instruments,setup_instruments中的TIMED列将被忽略(使用update语句对那么些内部存款和储蓄器instruments设置timed列为YES时得以实施成功,然而你会意识施行update之后select那么些instruments的timed列依旧NO),因为内部存款和储蓄器操作没有定期器音讯

performance-schema-consumer-events-waits-history FALSE

| wait/synch/mutex/sql/LOCK_lock_db |YES | YES |

| EVENT |mysql | % |NO | NO |

对setup_timers表的改换会立刻影响监察和控制。正在推行的轩然大波也许会采用修改在此之前的计时器作为初始时间,但或然会使用修改今后的新的计时器作为完成时间,为了防止计时器改换后或许爆发时间音信采集到不得预测的结果,请在修改以往接纳TRUNCATE TABLE语句来复位performance_schema中相关表中的计算消息。

| TABLE |% | % |YES | YES |

友谊提示:以下内容阅读起来大概比较烧脑,内容也较长,提出我们端好板凳,坐下来,点上一支烟,细细品读,那也是上学performance_schema路上只好过的火焰山,坚韧不拔下去,”翻过那座山,你就足以见到一片海!”

澳门新葡亰 1

mysql>UPDATE setup_instruments SET TIMED = ‘NO’;

setup_instruments表字段详解如下:

  • 控制events_statements_summary_by_digest表中的最大行数。要是发生的说话摘抄新闻当先此最大值,便不能继续存入该表,此时performance_schema会增加状态变量

TYPE: FOREGROUND

setup_actors表的始发内容是万分任何用户和主机,由此对于具有前台线程,暗中同意情状下启用监视和野史事件采访作用,如下:

setup_timers表字段含义如下:

performance-schema-consumer-events-stages-history- longFALSE

名称中给定组件的疏解取决于其左手的组件。例如,myisam显示在偏下五个称呼:

–performance-schema-instrument= ‘wait/synch/cond/%=COUNTED’

……

本篇内容到此处就如尾声了,假使阅读了本章内容之后,认为对performance_schema仍旧比较迷糊,那么建议根据如下步骤动入手、看一看:

setup_objects表控制performance_schema是还是不是监视特定对象。暗中同意景况下,此表的最大行数为100行。要改成表行数高低,能够在server运转之前修改系统变量performance_schema_setup_objects_size的值。

一).
wait/lock/table:表锁操作相关的instruments

| wait |CYCLE |

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

| % |% | % |YES | YES |

|CYCLE | 2389029850 |1| 72 |

NAME: thread/sql/compress_gtid_table

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

当有些线程截至时,会从threads表中去除对应行。对于与客户端会话关联的线程,当会话结束时会删除threads表中与客户端会话关联的线程配置新闻行。借使客户端自动重新连接,则也一定于断开1回(会删除断开连接的配置行)再重复成立新的总是,五遍一而再成立的PROCESSLIST_ID值差异。新线程伊始INSTRUMENTED和HISTO本田UR-VY值大概与断开此前的线程初步INSTRUMENTED和HISTOPAJEROY值区别:setup_actors表在此期间大概已转移,并且只要3个线程在创设之后,后续再修改了setup_actors表中的INSTRUMENTED或HISTOPRADOY列值,那么继续修改的值不会潜移默化到threads表中曾经成立好的线程的INSTRUMENTED或HISTOEnclaveY列值

9 rows in set (0.00 sec)

| PROCEDURE |performance_schema | % |NO | NO |

| FUNCTION |information_schema | % |NO | NO |

root@localhost : performance_schema 05:47:08> update threads
setINSTRUMENTED= ‘YES’whereTYPE= ‘BACKGROUND’;

# Support列值为YES表示数据库协理,不然你恐怕必要进级mysql版本:

mysql>UPDATE setup_instruments SET ENABLED = IF(NAME LIKE
‘wait/io/file/%’, ‘NO’, ‘YES’);

PROCESSLIST_COMMAND: Daemon

对setup_consumers表的改动会应声影响监察和控制,setup_consumers字段含义如下:

| NAME |ENABLED | TIMED |

|events_statements_history | YES |

  • performance_schema_consumer_events_stages_history_long=FALSE

| FUNCTION |mysql | % |NO | NO |

  • 控制performance_schema作用的按钮,要选拔MySQL的performance_schema,要求在mysqld运行时启用,以启用事件采访成效
  • 该参数在伍.七.x事先援助performance_schema的本子中暗中认可关闭,五.7.x版本初阶私下认可开启
  • 专注:假若mysqld在初步化performance_schema时发现不能够分配任何有关的中间缓冲区,则performance_schema将机关禁止使用,并将performance_schema设置为OFF

在setup_instruments表中的instruments一流instruments
组件分类如下:

  • NAME:instruments名称,instruments名称也许具备两个部分并产生层次结构(详见下文)。当instruments被施行时,产生的事件名称就取自instruments的名目,事件尚未真正的名号,直接选用instruments来作为事件的称号,能够将instruments与发生的风浪开始展览关联
  • ENABLED:instrumetns是不是启用,有效值为YES或NO,此列能够使用UPDATE语句修改。如若设置为NO,则这一个instruments不会被施行,不会时有爆发别的的事件消息
  • TIMED:instruments是或不是搜集时间新闻,有效值为YES或NO,此列能够运用UPDATE语句修改,假使设置为NO,则那么些instruments不会搜聚时间消息

| wait/io/table/sql/handler |YES | YES |

setup_instruments 表列出了instruments
列表配置项,即表示了哪些事件扶助被采访:

(2)**setup_timers**表

是或不是在MySQL
Server运行时就启用有个别搜罗器,由于instruments配置项多达数千个,所以该配置项帮衬key-value格局,还协理%号举办通配等,如下:

[root@localhost ~] # mysqld –verbose –help |grep performance-schema
|grep -v ‘–‘ |sed ‘1d’ |sed ‘/[0-9]+/d’

3rows inset ( 0. 00sec)

| NANOSECOND |1000000000| 1 |112|

| events_waits_history_long |NO |

  • 对于各个新的前台server线程,perfromance_schema会合营该表中的User,Host列举行般配,借使协作到某些配置行,则连续合营该行的ENABLED和HISTO哈弗Y列值,ENABLED和HISTO兰德安德拉Y列值也会用来生成threads配置表中的行INSTRUMENTED和HISTO福特ExplorerY列。假如用户线程在创立时在该表中未有相配到User,Host列,则该线程的INSTRUMENTED和HISTO奇骏Y列将安装为NO,表示不对这一个线程实行监督检查,不记录该线程的历史事件音讯。
  • 对于后台线程(如IO线程,日志线程,主线程,purged线程等),未有关联的用户,
    INSTRUMENTED和HISTO奥迪Q5Y列值默以为YES,并且后台线程在成立时,不会翻动setup_actors表的计划,因为该表只好调控前台线程,后台线程也不富有用户、主机属性

consumers:消费者,对应的消费者表用于储存来自instruments搜聚的数码,对应配置表中的布局项大家得以叫做消费存款和储蓄配置项,以下谈到消费者均统称为consumers

*metadata
locks监察和控制供给开采’wait/lock/metadata/sql/mdl’
instruments本事监督,开启那一个instruments之后在表performance_schema.metadata_locks表中可以查询到MDL锁信息

mysql> SELECT * FROM setup_timers;

UPDATEsetup_actors SETENABLED = ‘NO’, HISTORY = ‘NO’WHEREHOST =
‘%’ANDUSER= ‘%’;

performance-schema-consumer-events-waits-history- longFALSE

#剥夺钦点的某三个instruments:

setup_actors用于配置是或不是为新的前台server线程(与客户端连接相关联的线程)启用监视和野史事件日志记录。暗中认可情状下,此表的最大行数为100。能够运用系统变量performance_schema_setup_actors_size在server运营在此以前改动此表的最大布局行数

| wait/synch/rwlock/sql/LOGGER::LOCK_logger |YES | YES |

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

PROCESSLIST_DB: NULL

root@localhost : performance_schema 05:46:17> update threads
setINSTRUMENTED= ‘NO’whereTYPE= ‘BACKGROUND’;

  • NAME:consumers配置名称
  • ENABLED:consumers是或不是启用,有效值为YES或NO,此列能够应用UPDATE语句修改。倘若必要禁止使用consumers就安装为NO,设置为NO时,server不会维护那几个consumers表的内容新增删,且也会倒闭consumers对应的instruments(假如未有instruments发现搜罗数据未有别的consumers消费的话)
  • PS:对于setup_consumers表,不容许选拔TRUNCATE TABLE语句

|idle | MICROSECOND |

对setup_actors表的改换仅影响修改之后新制造的前台线程,对于修改此前已经创办的前台线程未有影响,假如要修改已经创办的前台线程的监督检查和野史事件记录成效,能够修改threads表行的INSTRUMENTED和HISTO奥迪Q五Y列值:

还是能登录到MySQL实例中应用SQL命令查看是还是不是帮忙performance_schema:

wait/synch/cond/myisam/MI_SORT_INFO::cond

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

| wait/synch/rwlock/sql/LOCK_sys_init_connect |YES | YES |

留神:固然大家得以经过cmake的编写翻译选项关闭掉有个别performance_schema的作用模块,可是,日常大家不提议如此做,除非您可怜明白后续不容许利用到这么些作用模块,不然继续想要使用被编写翻译时关闭的模块,还供给重新编译。

| NAME |TIMER_NAME |

mysql>UPDATE setup_instruments SET ENABLED = IF(ENABLED = ‘YES’,
‘NO’, ‘YES’) WHERE NAME = ‘wait/synch/mutex/mysys/TMPDIR_mutex’;

##
假诺把UPDATE语句改成DELETE,让未显著内定的用户在setup_actors表中找不到其余相配行,则threads表中对应配置行的INSTRUMENTED和HISTOLX570Y列值变为NO

THREAD_ID: 43

instruments的命名格式组成:performance_schema实现的三个前缀结构(如:wait/io/file/myisam/log中的wait+由开垦人士达成的instruments代码定义的1个后缀名称组成(如:wait/io/file/myisam/log中的io/file/myisam/log)

instruments具备树形结构的命名空间,从setup_instruments表中的NAME字段上得以见见,instruments名称的构成从左到右,最左边的是顶层instruments类型命名,最右侧是多个现实的instruments名称,有局地顶层instruments未有别的层级的组件(如:transaction和idle,那么那么些顶层类型既是类别又是有血有肉的instruments),有1些顶层instruments具备下层instruments(如:wait/io/file/myisam/log),三个层级的instruments名称对应的组件数量取决于instruments的连串。

# 开启全数后台线程的事件采访

*************************** 6. row
***************************

相关文章