盡管Performance Schema（以下簡(jiǎn)稱(chēng)PS）在5.5中已經(jīng)出現(xiàn)，但一直沒(méi)有使用過(guò)，并且相比5.6，5.5的PS表要少很多。 以下從一個(gè)初學(xué)者的角度，閱讀PS的官方文檔，做一些簡(jiǎn)單的筆記
官方文檔見(jiàn)：http://dev.mysql.com/doc/refman/5.6/en/performance-schema.html 目錄：?

1.開(kāi)啟PS

2.配置PS

2.1?setup_timers表決定了不同的instrument使用的timer類(lèi)型

2.2setup_instruments?

2.3?setup_consumers表 列出了事件信息的消費(fèi)者類(lèi)型

2.4.setup_objects

2.5.setup_actors

1.開(kāi)啟PS

首先需要強(qiáng)調(diào)一點(diǎn)，開(kāi)啟PS是有性能開(kāi)銷(xiāo)的，在一個(gè)性能測(cè)試場(chǎng)景上，我對(duì)比了阿里內(nèi)部版本的Percona Server 5.5.18與官方MySQL5.6.10,發(fā)現(xiàn)在同等壓力下，5.6版本有明顯的更高的CPU開(kāi)銷(xiāo)（大約高了10~20%）
確認(rèn)是否開(kāi)啟： 編譯階段：-DWITH_PERFSCHEMA_STORAGE_ENGINE:BOOL=ON ? ? 默認(rèn)是ON，可以設(shè)為OFF來(lái)在編譯階段關(guān)閉Performance Schema
也可以在啟動(dòng)mysqld時(shí)，關(guān)閉選項(xiàng)performance_schema
如果你在error log中看到類(lèi)似錯(cuò)誤的PS表結(jié)構(gòu)或者PS表找不到之類(lèi)的錯(cuò)誤，在開(kāi)啟實(shí)例后，可以執(zhí)行一下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?

2.配置PS

Performance Schema可以通過(guò)配置setup表來(lái)在運(yùn)行時(shí)配置PS，包括以下幾個(gè)表：

mysql> show tables like ‘%setup%';

+—————————————-+ | Tables_in_performance_schema (%setup%) | +—————————————-+ | setup_actors?????????????????????????? | | setup_consumers??????????????????????? | | setup_instruments????????????????????? | | setup_objects????????????????????????? | | setup_timers?????????????????????????? | +—————————————-+ 5 rows in set (0.00 sec)?

事件的計(jì)數(shù)設(shè)置有兩個(gè)相關(guān)的表： performance_timers?列出了可用的時(shí)間計(jì)數(shù)器(timer)及其特征?

mysql> SELECT * FROM performance_timers;

+————-+—————–+——————+—————-+ | TIMER_NAME? | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD | +————-+—————–+——————+—————-+ | CYCLE?????? |????? 2490706467 |??????????????? 1 |???????????? 38 | | NANOSECOND? |????? 1000000000 |??????????????? 1 |??????????? 128 | | MICROSECOND |???????? 1000000 |??????????????? 1 |??????????? 135 | | MILLISECOND |??????????? 1036 |??????????????? 1 |??????????? 150 | | TICK??????? |???????????? 103 |??????????????? 1 |??????????? 450 | +————-+—————–+——————+—————-+?

其中CYCLE由CPU??cycle counter 來(lái)決定timer TIMER_FREQUENCY表示每秒內(nèi)的計(jì)數(shù)次數(shù)，對(duì)于CYCLE類(lèi)型和CPU的速度相關(guān)。 TICK取決于不同的平臺(tái)，例如，在我的機(jī)器上，每秒103個(gè)tick,tick表示每發(fā)生一次timer interrupt的時(shí)間間隔，tick的一些概念可以參考網(wǎng)上找到的這篇文章：http://www.360doc.com/content/11/1201/09/1317564_168810003.shtml TIMER_RESOLUTION表示每次增加計(jì)數(shù)的單元，如果為10的話(huà)，就表示每次值加10 TIMER_OVERHEAD:the minimal number of cycles of overhead to obtain one timing with the given timer

2.1?setup_timers表決定了不同的instrument使用的timer類(lèi)型

mysql> SELECT * FROM setup_timers;

+———–+————-+ | NAME????? | TIMER_NAME? | +———–+————-+ | idle????? | MICROSECOND | | wait????? | CYCLE?????? | | stage???? | NANOSECOND? |? | statement | NANOSECOND? | +———–+————-+ setup_timers?可以配置每種instrument 使用哪種timer, timer必須是performance_timers表中的某一列,可以通過(guò)update語(yǔ)句來(lái)進(jìn)行更新?

對(duì)于wait類(lèi)型，最重要的是減少OVERHEAD,所以選擇CYCLE類(lèi)型，相應(yīng)的代價(jià)是損失計(jì)時(shí)精度 statement或者stage的執(zhí)行時(shí)間總的來(lái)說(shuō)，相比wait要高一個(gè)數(shù)量級(jí)。為了給statement計(jì)時(shí)，最重要的是原則是要有一個(gè)精確的衡量，并且不受處理器頻率影響，因此默認(rèn)的為NANOSECOND，其額外的‘OVERHEAD’相比CYCLE TIMER并不明顯，因?yàn)檎{(diào)用一個(gè)timer兩次的開(kāi)銷(xiāo)（一次是statement開(kāi)始，一次是statement結(jié)束）相比statement執(zhí)行本身的CPU時(shí)間要小很多個(gè)數(shù)量級(jí)。如果使用CYCLE，只有壞處，沒(méi)有好處。 cycle計(jì)數(shù)器的精度依賴(lài)于CPU的速度，使用CYCLE 計(jì)數(shù)器實(shí)際上比使用標(biāo)準(zhǔn)gettimeofday的開(kāi)銷(xiāo)要小，后者的一次調(diào)用可能產(chǎn)生上百次cycle。
修改?setup_timers?表會(huì)立刻生效，所以可能一個(gè)事件的開(kāi)頭和結(jié)束使用了兩個(gè)不同的timer

2.2setup_instruments?

setup_instruments?表中包含了上述四種類(lèi)型(idle,wait, stage,statement)對(duì)應(yīng)的的instrument，對(duì)象可以通過(guò)更新ENABLED和TIMED列來(lái)決定是否收集對(duì)應(yīng)事件的信息?

mysql> select count(*) from? setup_instruments;

+———-+ | count(*) | +———-+ |????? 545 | +———-+ 1 row in set (0.00 sec)

mysql> desc setup_instruments;

+———+——————+——+—–+———+——-+ | Field?? | Type???????????? | Null | Key | Default | Extra | +———+——————+——+—–+———+——-+ | NAME??? | varchar(128)???? | NO?? |???? | NULL??? |?????? | | ENABLED | enum(‘YES’,’NO’) | NO?? |???? | NULL??? |?????? | | TIMED?? | enum(‘YES’,’NO’) | NO?? |???? | NULL??? |?????? | +———+——————+——+—–+———+——-+?

目前5.6.10的版本有545個(gè)instrument可以來(lái)做配置。其中ENABLED列表示是否為該instrument收集事件，TIMED列表示是否為該instrument計(jì)時(shí)；如果TIMED列的值被關(guān)閉，就不會(huì)去為對(duì)應(yīng)的事件生成TIMER_START,?TIMER_END, 以及?TIMER_WAIT的值
事件的事件被轉(zhuǎn)換為納秒來(lái)統(tǒng)計(jì)，不管是使用哪種timer；這主要是為了使用一個(gè)統(tǒng)一的時(shí)間單位。

2.3?setup_consumers表 列出了事件信息的消費(fèi)者類(lèi)型

mysql> SELECT * FROM setup_consumers;

+——————————–+———+ | NAME?????????????????????????? | ENABLED | +——————————–+———+ | events_stages_current????????? | YES???? | | events_stages_history????????? | YES???? | | events_stages_history_long???? | YES???? | | events_statements_current????? | YES???? | | events_statements_history????? | YES???? | | events_statements_history_long | YES???? | | events_waits_current?????????? | YES???? | | events_waits_history?????????? | YES???? | | events_waits_history_long????? | YES???? | | global_instrumentation???????? | YES???? | | thread_instrumentation???????? | YES???? | | statements_digest????????????? | YES???? | +——————————–+———+ 12 rows in set (0.00 sec)?

如果你不關(guān)注某個(gè)consumer，可以關(guān)閉掉，這樣服務(wù)器就不會(huì)去花費(fèi)時(shí)間來(lái)維護(hù)。例如，如果你不想使用歷史事件統(tǒng)計(jì)，就可以把幾個(gè)history事件關(guān)閉。主要包括以下幾種consumer：
Global and Thread Consumers a.global_instrumentation是最高層次的consumer,如果將其設(shè)置為NO，就會(huì)關(guān)閉全局instrumentation，其他的consumer都會(huì)被忽略掉，不管他們被設(shè)置成YSE或者NO。 當(dāng)global_instrumentation被設(shè)置為YES時(shí)，就會(huì)去維護(hù)全局狀態(tài)，同樣也會(huì)去檢查thread_instrumentation
如果只打開(kāi)了global_instrumentation而關(guān)閉其他consumer，維護(hù)的全局狀態(tài)表包括：

• mutex_instances

• rwlock_instances

• cond_instances

• file_instances

• file_summary_by_instance

• file_summary_by_event_name

• objects_summary_global_by_type

• table_lock_waits_summary_by_table

• table_io_waits_summary_by_index_usage

• table_io_waits_summary_by_table

• events_waits_summary_by_instance

• events_waits_summary_global_by_event_name

b.只有global_instrumentation為YES時(shí)才會(huì)去檢查thread_instrumentation。 如果thread_instrumentation為NO，他會(huì)禁止線(xiàn)程級(jí)別或者獨(dú)立事件收集信息。如果設(shè)置為YES，則會(huì)維護(hù)線(xiàn)程級(jí)別的信息，同時(shí)也會(huì)檢查?events_xxx_current?consumer?

線(xiàn)程級(jí)別的信息所對(duì)應(yīng)的表包括： events_waits_summary_by_thread_by_event_name
Statement Digest Consumer 需要將global_instrumentation設(shè)置為YES,否則statements_digest會(huì)被忽略掉。它不依賴(lài)于?Statement Event consumer，這意味著你可以在每個(gè)digest中獲得統(tǒng)計(jì)信息而無(wú)需在?events_statements_current中收集信息，這有利于減少開(kāi)銷(xiāo)
Wait Event Consumers 這些consumer需要global_instrumentation和thread_instrumentation同時(shí)設(shè)置為YES.包括以下幾個(gè)： a.events_waits_current,如果設(shè)置為NO，則不為?events_waits_current表收集獨(dú)立的等待事件。如果為YES，就會(huì)開(kāi)啟?events_waits_current表的信息收集，同時(shí)檢查events_waits_history和events_waits_history_long這兩個(gè)consumer。 b.events_waits_history,前提是打開(kāi)events_waits_current，該consumer用于控制表events_waits_history中是否收集信息。 c.events_waits_history_long，前提是打開(kāi)events_waits_current，該consumer用于控制表events_waits_history_long中是否收集信息。
Stage Event Consumers 這些consumer需要global_instrumentation和thread_instrumentation同時(shí)設(shè)置為YES.包括以下幾個(gè)：?

層次關(guān)系和Wait Event Consumer類(lèi)似 events_stages_current ， 對(duì)應(yīng)?events_stages_current表 events_stages_history， 對(duì)應(yīng)events_stages_history表 events_stages_history_long，對(duì)應(yīng)events_stages_history_long表?
Statement Event Consumers events_statements_current,對(duì)應(yīng)events_statements_current等
events_statements_history， 對(duì)應(yīng)events_statements_history
events_statements_history_long，對(duì)應(yīng)events_statements_history_long?

綜上，consumer級(jí)別為： 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 其中高級(jí)別的consumer決定是否去檢查低級(jí)別的consumer

2.4.setup_objects

setup_objects用于決定哪些對(duì)象可以被監(jiān)控，當(dāng)前只能控制表對(duì)象，該表默認(rèn)最大可以插入100行記錄，但可以通過(guò)參數(shù)performance_schema_setup_objects_size來(lái)調(diào)整其大小?

默認(rèn)狀態(tài)下，該表的數(shù)據(jù)包括：

mysql> 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?? | +————-+——————–+————-+———+——-+?

默認(rèn)情況下，監(jiān)控的表對(duì)象排除mysql/PS/IS庫(kù)下的表，其中IS庫(kù)下的表，不管是否開(kāi)啟，都不會(huì)去監(jiān)控。PS會(huì)根據(jù)?setup_objects?和setup_instruments來(lái)決定是否開(kāi)啟一個(gè)instrument并為其計(jì)時(shí)。對(duì)于在setup_objects中的表對(duì)象，必須在兩個(gè)表中都ENABLED才會(huì)收集事件信息，如果需要計(jì)時(shí)，則兩者的TIEMD列都必須為YES。

2.5.setup_actors

setup_actors?用于決定新的前臺(tái)線(xiàn)程的初始監(jiān)控狀態(tài)，默認(rèn)情況下包括所有用戶(hù)：

mysql> select * from? setup_actors;

+——+——+——+ | HOST | USER | ROLE | +——+——+——+ | %??? | %??? | %??? | +——+——+——+ 1 row in set (0.00 sec)
該表中的記錄可以決定需要對(duì)哪些用戶(hù)線(xiàn)程進(jìn)行監(jiān)控，在threads?表中記錄了所有的前臺(tái)/后臺(tái)線(xiàn)程狀態(tài)（有點(diǎn)跟PROCESSLIST表類(lèi)似），并記錄其是否被監(jiān)控。為了讓threads生效，需要打開(kāi)?setup_consumers表中的thread_instrumentation。

總結(jié)

以上是生活随笔為你收集整理的[MySQL 5.6] Performance Schema 之 PS配置项（1）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。