[MySQL Reference Manual] 23 Performance Schema結構

時間 2020-09-14

標籤 mysql reference manual performance schema 結構欄目 MySQL 简体版

原文原文鏈接

23 MySQL Performance Schema

23 MySQL Performance Schema.. 1html

23.1 性能框架快速啓動... 3mysql

23.2 性能框架配置... 5sql

23.2.1 性能框架編譯時配置... 5shell

23.2.2 性能框架啓動配置... 6數據庫

23.2.3 啓動時性能框架配置... 8編程

23.2.3.1 性能架構事件定時... 8緩存

23.2.3.2 性能框架事件過濾... 9服務器

23.2.3.3 事件預過濾... 10網絡

23.2.3.4命名記錄點或者消費者的過濾... 12session

23.2.3.5 識別哪些已經被記錄... 12

23.3 性能框架查詢... 13

23.4 性能框架記錄點命名約定... 13

23.5 性能框架和狀態監控... 15

23.6 性能框架和分子原子性事件... 17

23.7 性能框架statement digests17

23.8 性能框架經常使用表特性... 19

23.9 性能框架表描述... 19

23.9.1 性能框架表索引... 19

23.9.2 性能框架setup表... 19

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

23.9.3 性能框架實例表... 22

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

23.9.4 性能框架事件等待表... 25

23.9.4.1 events_waits_current表... 26

23.9.4.2 Events_waits_history表... 28

23.9.4.3 events_waits_history_long 表... 28

23.9.5 性能框架Stage事件表... 28

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

23.9.6 性能框架語句事件表... 31

23.9.7 性能框架事務表... 32

23.9.8 性能框架鏈接表... 35

23.9.9 性能框架鏈接屬性表... 35

23.9.10 性能框架用戶變量表... 35

23.9.11 性能框架複製表... 36

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

23.9.12 性能框架鎖相關表... 41

23.9.12.1 metadata_locks41

23.9.12.2 table_handles42

23.9.13 性能框架系統變量表... 42

23.9.14 性能框架系統狀態變量表... 43

23.9.15 性能框架統計表... 43

23.9.16 性能框架其餘表... 44

23.10 性能框架選項和變量... 45

23.11 性能框架命令選項... 45

23.12 性能框架系統變量... 45

23.13 性能框架狀態變量... 45

23.14 性能框架內存分配模型... 45

23.15 性能框架和... 46

23.16 使用性能框架診斷... 47

23.17 遷移到性能框架系統和狀態變量表... 47

MySQL Performance Schema用來監控MySQL Server的運行運行在底層。性能框架有這些特性：

· 性能框架提供了一種方法檢查內部的服務運行。經過PERFORMANCE_SCHEMA存儲引擎和performance_schema實現。性能框架主要關注於數據性能。和INFORMANCE_SCHEMA不一樣，INFORMACE_SCHEMA主要檢查元數據。

· 性能框架監控服務事件，事件是服務須要花時間的任何東西，而且已經被記錄這樣時間信息能夠被收集。一般一個事件能夠是一個函數調用，一個操做系統等待，SQL語句執行的階段好比解析或者排序，或者整個語句或者一組語句。時間收集提供。時間收集提供了同步調用文件和表IO,表鎖等信息。

· 性能框架事件的事件和binlog的事件，事件調度的事件不一樣。

· 性能框架事件被指定到某個MySQL服務。性能框架表別人我是本地服務，他們的修改不會被寫入到binary log，也不會被複制。

· 當前事件，歷史事件和事件總結是可用的，那麼就能夠肯定記錄被啓動了多少次，用了多少時間。事件信息能夠查看指定線程的活動或者指定對象的活動，好比文件和信號量。

· PERFORMANCE_SCHEMA存儲引擎使用代碼中的記錄點來收集信息。

· 收集的信息被保存在performance_schema數據庫中。能夠用select查詢。

· 性能框架配置能夠動態的被修改，經過修改performance_schema數據庫配置數據收集。

· Performance_schema上的表是視圖或者臨時表，不會保存到磁盤中。

· MySQL支持全部平臺的監控。

· 經過在源代碼中加入記錄點實現數據收集。沒有特定線程使用相關的性能框架。

23.1 性能框架快速啓動

對於性能框架要啓用，必需要在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查看是否支持PERFORMANCE_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表包含了每一個線程最近10個event和每一個線程最近10000個events。

一個新的事件被加入，老的事件就會刪除。

總結表提供了全部事件的聚合的信息。這個表經過分組一不一樣方式計算事件數據。爲了查看那個記錄點唄執行的次數最多或者等待事件最長，經過對錶上的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 |

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

如，上面結果THR_LOCK信號量是熱點，2個語句分別表示執行的熱度和等待事件長度。

實例表，記錄了對象類型被記錄了。當服務使用了一個記錄對象，那麼會產生一個事件。這些表提供了事件名，解釋性的註釋或者狀態。好比file_instances表，記錄了文件io操做和他們對應的文件。

mysql> SELECT * FROM file_instances\G

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

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

EVENT_NAME: wait/io/file/sql/binlog

OPEN_COUNT: 0

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

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

EVENT_NAME: wait/io/file/myisam/kfile

OPEN_COUNT: 1

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

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

EVENT_NAME: wait/io/file/myisam/kfile

OPEN_COUNT: 1

...

Setup表用來配置和監控特色的，好比setup_timers表：

mysql> SELECT * FROM setup_timers;

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

| NAME        | TIMER_NAME  |

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

| idle        | MICROSECOND |

| wait        | CYCLE       |

| stage       | NANOSECOND  |

| statement   | NANOSECOND  |

| transaction | NANOSECOND  |

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

Setup_instruments列了哪些能夠被記錄的事件。而後經過修改這個表開控制是否啓動這個記錄。

mysql> UPDATE setup_instruments SET ENABLED = 'NO'

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

性能框架使用，收集來的事件來更新到performance_schema數據庫，數據庫做爲事件信息的消費者。Setup_consumers表列出了可用的消費者。

控制是否性能框架維護一個消費者做爲事件信息的目標。能夠設置爲enabled值。

23.2 性能框架配置

23.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查看是否存在PERFORMANCE_SCHEMA存儲引擎。若是在build的時候沒有被配置那麼show engines不會顯示PERFORMANCE_SCHEMA存儲引擎。

23.2.2 性能框架啓動配置

假設性能框架是可用的，那麼默認是啓動的也能夠在配置文件中配置：

[mysqld]
performance_schema=ON

若是服務不能在初始化性能框架的時候分配內部緩存，那麼性能框架本身關閉而且設置performance_schema爲off，服務在沒有記錄點情況下運行。

性能框架能夠以命令行參數方式配置。

--performance-schema-instrument='instrument_name=value'

關閉全部記錄點：

--performance-schema-instrument='%=OFF'

比較長的記錄點名會比短的積累點名要優先於短的模式名，無論順序。

具體能夠看後面章節：23.2.3.4命名記錄點或者消費者的過濾

一個沒法別識別的記錄點名會被忽略。爲了控制消費者，可使用如下選項：

--performance-schema-consumer-consumer_name=value

consumer_name是一個消費者名好比events_waits_history，value是如下一個值：

l OFF，False或者0：不收集這個消費者的事件

l ON,True或者1：收集消費者的事件

好比消費者名是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 5.7.6，性能框架分配內存會根據服務符合增長夥子減小，而不是在服務啓動的時候一次性分配完成。因此不少參數並不須要在啓動的時候都分配好，更多內容能夠看23.12 性能框架系統變量。

每一個自動分配的參數不是在啓動時設置或者設置爲-1，性能框架決定如何根據如下的參數來設置這些值：

max_connections

open_files_limit

table_definition_cache

table_open_cache

若是要覆蓋自動設置的值或者自動範圍的值，就在啓動的時候設置一個給定的值而不是給-1這樣性能框架就會設置一個給定的值。

在運行時，show variables會顯示自動設置的值，自動範圍設置的會給-1.若是性能框架被禁用，自動設置和自動範圍參數都會被設置爲-1，而且顯示爲-1.

23.2.3 啓動時性能框架配置

23.2.3.1 性能架構事件定時

事件被收集也就是說記錄點被加到了服務源代碼中。記錄點時間事件，是性能框架如何提供一個事件持續多久的方案。也能夠配置記錄點收集定時信息。

性能框架定時器

2個性能框架表提供了定時器信息：

l Performance_timers，保存了可用的timers和它們的特色。

l Setup_timers，代表了哪些記錄點使用了哪一個timers。

每一個setup_timers使用的計時器躲在performance_timers表中。

mysql> SELECT * FROM performance_timers;

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

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

| 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_OVERHEAD:指定週期獲取一個定時須要的最小cycles個數。每一個事件都會在開始和結束的時候調用timer，所以是顯示的負荷的2倍。

修改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要大，可是不重要，由於調用2次計數器的數量級遠遠比執行語句自己的cpu時間要小。

Cycle提供的精度和cpu有關，若是處理器是1Gh或者更高，cycle能夠提供比納秒還小的進度。使用cycle計數器比獲取一個一天的實際事件開銷小。

Cycle的缺點：

l 從cycles轉化爲時間單位是比較費事的。爲了更快，這個轉化操做知識很粗糙的乘法計算。

l 處理器cycle，可能會遍，好比筆記本進入省電模式，那麼cpu cycle會降低若是cpu cycle有波動，那麼轉化就會出錯。

l Cycle 計數器多是不靠譜的或者不可用的，和處理器或者操做系統有關。

l 一些處理器，亂序執行或者多處理器同步，可能會致使計數器忽高忽低。

性能框架計數器在事件中的表現

存儲在性能框架表的當前事件，有3個列表示事件，TIMER_START,TIMER_END表示事件啓動和結束，TIMER_WAIT表示事件的時間。

Set_instruments表有ENABLED字段來表示，事件是否要收集。TIMED字段表示記錄點是否被時間標記。若是記錄點沒有啓動，那麼就不會生成事件。若是不是timed,那麼生成的事件，中TIMER_START,TIME_END,TIMER_WAIT是null。那麼在統計表計算最大時間，最小時間的時候會被忽略。

內部，事件啓動的時候，timer以給定的單位保存在事件裏面，當要顯示的時候，timers被顯示爲標準的事件單位，無論選了什麼timer都會顯示爲，皮秒。

Setup_timers的修改會立刻生效。已經在處理的會使用老的timer。爲了避免致使沒法預期的結果出現，最好先把統計表使用truncate table進行重置。

Timer的基線，在服務啓動的時候被初始化。TIMER_START,TIMER_END表示從基線以來的皮秒數。TIMER_WAIT表示佔用的皮秒。

23.2.3.2 性能框架事件過濾

事件是以生產者消費者模式處理的：

l 記錄點代碼是事件的源，產生事件被用來收集，setup_instruments表列出了能夠被收集的記錄點。Setup_instruments表提供了不少event的產生。

l 性能框架表示事件的目的地。Setup_consumers，列出了全部消費者類型。

l 預過濾，經過修改性能框架配置完成，能夠經過啓用或者禁用記錄點和消費者完成。使用預過濾的目的：

n 減小負荷。性能框架運行須要消耗資源，雖然不多。

n 不關心的事件能夠不寫入消費者中。

n 避免維護多個類型的事件表。

· 過後過濾，可使用where語句在查詢性能框架的時候過濾。

23.2.3.3 事件預過濾

預過濾有性能框架完成而且會全局的影響全部用戶。預過濾能夠在生產者或者消費者的處理階段上：

· 幾個表能夠用來配置生產者的預過濾：

§ Setup_instruments說明哪一個記錄點是可用的，若是這個表上一個記錄點被禁用，無論其餘表怎麼配置，都不會再產生事件。

§ Setup_objects控制了性能框架特定表和存儲過程對象。

§ Threads表示是否是每一個服務線程都有監控

§ Setup_actors新的後臺進程的初始監控狀態

· 要配置預過濾在消費者階段，那麼要修改setup_comsumers表。setup_comsumers也會影響事件的產生。若是指定的事件不會發送給任何地方，那麼性能框架不會產生

修改任意表都會立刻影響監控，可是有些例外：

· 修改某些setup_instruments表只有的服務啓動的時候生效。在運行時修改不會生效。

· 修改setup_actors表，只會影響後臺線程。

當修改監控配置，性能框架不會刷新歷史表。歷史表和當前表的事件不會被替換，除非又新的事件。若是禁用一個記錄點的時候，須要等待一段時間，來替換老的事件。也能夠用truncate table清空。

在修改完記錄點以後，可能下那個藥傷處summary表清理統計信息對於events_statements_summary_by_digest或者內存統計表。Truncate table只會重置值爲0，並不會刪除行。

23.2.3.3.1 記錄點預過濾

控制記錄點的過濾，是過濾setup_instruments表設置enables字段。修改setup_instruments大多數會立刻生效。對於某些記錄點，修改只會在服務器啓動纔會生效。setup_instruments提供了最基本的記錄點控制。

23.2.3.3.2 對象預過濾

Setup_objects表控制了性能框架部分表和存儲過程。修改Setup_objects會立刻相應。

mysql> SELECT * FROM setup_objects;

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

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

OBJECT_TYPE:表示對象類型，好比表或者事件，存儲過程等。

OBJECT_SCHEMA和OBJECT_NAME包含了schema或者對象名的字符串，也能夠是通配符

ENABLED列表示對象是否被監控，TIMED列表示是否收集timing信息。

默認會收集除了mysql,information_schema，performance_schema外全部的的數據庫對象。

23.2.3.3.3 線程預過濾

threads表爲每一個線程保存了一行數據。每行數據都包含了線程的信息而且代表是否被監控。對於性能框架監控一個線程必須知足一下他條件：

· 表sestup_consumers表中的thread_instrumentation必須爲yes

· Threads.instrumented列必須爲yes

· 只監控setup_instruments表中的記錄點

threads表也說明了每一個服務線程是否執行歷史事件記錄。若是要記錄歷史事件如下條件都必須爲真：

· 對應的消費者配置，setup_consumers表必須爲yes。

· Threads.HISTORY列必須爲yes。

· 只監控setup_instruments表中的記錄點

對於後臺線程，instrumented和history的初始數據，取決於setup_action中的配置。

mysql> SELECT * FROM setup_actors;

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

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

| % | % | % | 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.6 以前，沒有enabled字段，只要有匹配，那麼instrumented=yes

在mysql5.7.8,以前，沒有history字段，線程要不所有能夠進入history要不都不能，取決於setup_consumer的配置。

默認，後臺的全部線程都是會被記錄的，由於setup_actors有一行都是‘%’。

23.2.3.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和上面相似。

23.2.3.4命名記錄點或者消費者的過濾

能夠對指定記錄名或者消費者進行過濾：

mysql> UPDATE setup_instruments

-> SET ENABLED = 'NO'

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

mysql> UPDATE setup_consumers

-> SET ENABLED = 'NO' WHERE NAME = 'events_waits_current';

指定一組記錄點或者消費者：

mysql> UPDATE setup_instruments

-> SET ENABLED = 'NO'

-> WHERE NAME LIKE 'wait/synch/mutex/%';

mysql> UPDATE setup_consumers

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

23.2.3.5 識別哪些已經被記錄

經過檢查setup_instruments表，你能夠得知包含了哪些記錄點被記錄：

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

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

| NAME | ENABLED | TIMED |

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

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

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

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

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

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

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

23.4 性能框架記錄點命名約定

記錄點命名是一串組件而後用‘/’分割：

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

記錄點命名相似於樹形結構。從左到右愈來愈詳細，組件的名稱以來與計數器類型。

名字由2部分組成：

· 組件名，好比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。服務有一個監聽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中對於行的等待可能有2行。

· Wait/lock ,鎖操做的記錄點

§ Wait/lock/table,表鎖記錄點操做

§ Wait/lock/metadata/sql/mdl,元數據所操做

· Wait/synch,同步對象記錄點

§ Wait/synch/cond,條件被用來一個線程通知另一個線程，某些它們等待的東西已經完成。若是一個線程等待一個條件，那麼會醒來而且處理。若是多個線程等待那麼會都新來而且完成它們等待的資源。

§ Wait/synch/mutex,多排他對象用來訪問一個資源，防止其餘線程訪問資源。

§ Wait/synch/rwlock,一個讀寫鎖對象用來鎖定特定的變量，防止其餘線程使用。一個共享讀所能夠多個線程同時獲取。一個排他寫鎖只能由一個線程獲取。

§ Wait/synch/sxlock,共享排他鎖是讀寫鎖的rwlock的一種，提供當一個線程寫時，其餘線程能夠非一致性讀。Sxlock在mysql 5.7中使用爲了優化rwlock的或展示。

23.5 性能框架和狀態監控

可使用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。可是信號量仍是以用於對象同步。可是性能數據就沒法被收集，若是記錄點被分配，用來初始化記錄點信號量實體。對於單獨的信號量好比全局信號量，只有一個實例。有些信號量的實例個數會變化，好比每一個鏈接的信號量。若是服務不能建立一個指定記錄點信號量實體，就會增長，performance_schema_mutex_instance_lost。

假設有如下條件：

· 服務啓動參數，--performance_schema_max_mutex_classes=200，所以有200個信號量空間。

· 150信號量已經被加載

· 插件plugin_a有40個信號量

· 插件plugin_b有20個信號量

服務爲插件，分配信號量記錄點依賴於已經分配了多少，好比如下語句：

INSTALL PLUGIN plugin_a

那麼服務已經有了150+40個信號量。

UNINSTALL PLUGIN plugin_a;

雖然插件已經卸載，可是仍是有190個信號量。全部插件代碼生成的歷史數據仍是有效。可是新的記錄點事件不會被分配。

INSTALL PLUGIN plugin_a;

服務發現40個記錄點已經被分配，所以新的記錄點不會被建立，而且以前分配的內部buffer會被從新使用，信號量仍是190個。

INSTALL PLUGIN plugin_b;

這個使用可用信號量已經只有10個了，新的插件要20個記錄點。10個已經被加載，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發佈。可是一些插件若是不加載可能會少一點。好比你能夠不加載默寫存儲引擎。

· 你加載一個第三方插件，是性能框架的記錄點，可是在服務啓動的時候，不容許插件記錄點內存獲取。由於來自第三方，這個引擎的記錄點內存並不會被記錄在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信號量記錄點實例。

若是服務沒有空間存放全部1000個信號量記錄點實體，一些信號量會被建立記錄點，一些就不會被建立。若是服務職能建立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.6 性能框架和分子原子性事件

對於一個表的io事件，一般有2行在events_waits_current，不是一個如：

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

行獲取會致使文件讀取。好比，表io獲取事件在文件io事件以前，可是尚未完成。那麼文件io嵌入在表io事件。

和其餘原子性等待事件不一樣，表io事件是分子，包含其餘事件。Events_waits_current中，表io事件一般有2行：

· 一行是當前表io等待事件

· 一行是其餘任何類型的等待事件。

一般，其餘類型的等待事件不是表io事件。當副事件完成，會從events_waits_current中消失。

23.7 性能框架statement digests

MySQL服務有能力維護statement digest信息。Digest進程把一個sql語句轉化爲標準的格式而且計算一個hash結果。標準化容許類似的語句分組而且總結暴露一些語句的類型和發生的頻率。

在性能框架，語句digest涉及這些組件：

· Setup_comsumers的statement_digset控制了，性能框架如何維護digest信息。

· 語句事件表有列包含digest和相關的值的列：

§ DIGEST_TEXT，標準化的語句。

§ DIGEST,是digest MD5 hash值。

Digest計算，最大的可用空間1024B。MySQL 5.7.8後這個值能夠經過參數，performance_schema_max_digest_length修改。以前使用max_digest_length。

· 語句事件表也有sql_text列包含了原始的sql語句。語句顯示的最大爲1024B，能夠經過performance_schema_max_sql_text_length字段修改。

· events_statements_summary_by_digest，提供綜合的語句digset信息。

標準化一個語句轉化，會保留語句結構，刪除沒必要要的信息：

· 對象標識符，好比表或者數據庫名會被保留。

· 文本值會被替換成變量。

· 註釋會被刪除，空格會被調整。

好比以下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大小固定的，因此若是滿了，若是在表上沒有匹配的，那麼全部的語句都會被計算在schema_name和digest爲null的記錄裏面，固然能夠增長digest大小，performance_schema_digests_size，若是沒有指定，那麼性能框架會本身評估一個值。

performance_schema_max_digest_length系統變量決定digest buffer最大可用字節。可是現實的語句digest的長度每每比buffer長，那是由於關鍵字和文本值的關係。也就是說digest_text的長度可能超過performance_schema_max_digest_length。

對於應用程序生成了很長的語句，只有結尾不一樣，增長performance_schema_max_digest_length可讓digest得以計算，識別語句。反過來減小performance_schema_max_digest_length會致使服務犧牲不多的內存來保存語句的digest，可是增長了語句的類似度，被當成同一個digest。若是長度要求長，那麼保存的也要更多。

能夠經過show engine performance_schema status語句，或者監控如下語句查看sql語句保存使用的內存量。

mysql> SELECT NAME FROM setup_instruments

    -> WHERE NAME LIKE '%.sqltext';

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

| NAME                                                             |

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

| memory/performance_schema/events_statements_history.sqltext      |

| memory/performance_schema/events_statements_current.sqltext      |

| memory/performance_schema/events_statements_history_long.sqltext |

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

mysql> SELECT NAME FROM setup_instruments

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

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

| NAME                                                                 |

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

| memory/performance_schema/events_statements_history.tokens           |

| memory/performance_schema/events_statements_current.tokens           |

| memory/performance_schema/events_statements_summary_by_digest.tokens |

| memory/performance_schema/events_statements_history_long.tokens      |

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

23.8 性能框架經常使用表特性

Performance_schema數據庫是小寫的，數據庫裏面的表名也是小寫的。查詢要使用小寫。

不少表在performance_schema數據庫是隻讀的不能被修改。一些setup表的某些列能夠被修改。一些也能夠被插入和刪除。事務能夠被容許清理收集的事件，因此truncate table能夠用來清理信息。

Truncate table能夠在總結表上使用，可是不能再events_statements_summary_by_digest和內存總結表上使用，效果只是把總計列清理爲0.

23.9 性能框架表描述

23.9.1 性能框架表索引

具體看：http://dev.mysql.com/doc/refman/5.7/en/performance-schema-table-index.html

23.9.2 性能框架setup表

Setup表提供關於當前收集點啓用信息。使用表而不是全局變量提供了更高級別的性能框架配置。好比你可使用一個sql語句配置多個記錄點。

這些setup表示可用的：

· Setup_actors:如何初始化後臺線程

· Setup_consumers:決定哪些信息會被髮送和存儲。

· Setup_instruments：記錄點對象，哪些事件要被收集。

· Setup_objects:哪些對象要被監控

· Setup_timers:當前事件定時器。

23.9.2.1 setup_actors表

setup_actors表包含了信息決定是否監控或者對新的後臺線程進行歷史數據記錄。這個表默認最多100行，能夠經過修改參數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;

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

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

| % | % | % | YES | YES |

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

修改setup_actors表只會影響後臺線程，不會影響已經存在的線程。爲了影響已經存在的threads表，修改instrumented和history列。

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行會立刻影響監控。對於一些記錄點，修改只會在下次啓動纔會生效。在指定時修改並不會生效。

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中的一行。表示某個事件類型使用了什麼計時器

23.9.3 性能框架實例表

23.9.3.1 cond_instances表

Cond_instance表列出了全部性能框架能夠查看的條件。條件是同步機制，用來通知一個指定的事件已經產生完畢。因此一個線程等待這個條件的會立刻恢復工做。

當一個線程等待的東西已經變化，條件名值說明線程在等待條件名。

23.9.3.2 file_instances表

當指定文件io記錄點的時候，File_instances表列出了全部性能框架能看到的全部文件。若是文件在disk可是沒有被打開不會出如今file_instrances中。當文件在次磁盤中被刪除，那麼file_instances中也會刪除。

23.9.3.3 mutex_instances表

Mutex_instances顯示了全部能夠被性能框架查看到的信號量。信號量是同步機制用來保護資源。當2個線程運行須要放問相同的資源，2個線程會互相爭用，一個線程獲取了mutex上的鎖，那麼另一個只能等待上一個完成。

當任務執行獲取信號量，稱爲臨界區域，區域內執行都是順序的，可能有潛在瓶頸問題。

表中有3個字段：

Name：記錄點的名字

OBJECT_INSTANCE_BEGIN:被記錄的信號量在內存中的地址。

LOCKED_BY_THREAD_ID：擁有mutex的線程id，不然爲null。

對於每一個記錄的信號量，性能框架提供一下信息：

· Setup_instruments表列出了記錄點名，以wait/synch/mutex/爲前綴。

· 當有代碼建立了信號量，那麼就有一行被加入到mutex_instrances表中，OBJECT_INSTANCE_BEGIN列是mutex的惟一列。

· 當一個線程視圖鎖定信號量，events_waits_current表爲線程顯示一行，說明在等待信號量，經過object_instance_begin。

· 當線程成功鎖定了一個信號量：

§ Events_waits_current，顯示等待信號量就會完成

§ 完成的事件會被添加到歷史表中

§ Mutex_instances顯示信號量如今屬於一個thread

· 當thread unlock一個信號量，mutex_instances顯示信號量如今沒有owner，thread_id爲null。

· 當信號量對象被銷燬，對應的行也會被刪除。

查如下2個表，能夠診斷瓶頸或者死鎖：

§ Events_waits_current,查看線程等待的信號量。

§ Mutex_instrances,查看其它線程的全部的信號量。

23.9.3.4 Rwlock_instances表

Rwlock_instances表列出了全部rwlock的實例。Rwlock是同步機制用來強制在必定規則下，在給定的事件裏面能訪問一些資源。這些資源被rwlock保護。訪問要不是共享方式要不是排他方式，若是容許非一致性訪問，還能夠共享排他方式訪問。Sxlock只有在，mysql 5.7以後才能被使用，用來優化併發性。

根據訪問的需求，所的請求要不是，共享，排他，共享排他或者不受權，等待其餘線程完成。

表列以下：

· NAME：記錄點名相關的lock

· OBJECT_INSTANCE_BEGIN:被記錄的鎖在內存中的地址。

· WRITE_LOCKED_BY_THREAD_ID:當一個線程有一個rwlock，排他模式，WRITE_LOCKED_BY_THREAD_ID,就是鎖定線程的thread_id。

· READ_LOCKED_BY_COUNT:當線程當前有一個rwlock共享模式，那麼read_locked_by_count增長1。只是個計數，因此找不到那個線程擁有了讀鎖，可是能夠用來查看是否有讀鎖，有多少讀是活動的。

經過執行查詢一下表，何以知道瓶頸和死鎖：

· Events_waits_current,查看等待哪些rwlock

· Rwlock_instrances,查看其它線程是否擁有這個鎖。

只能知道那個線程有了write lock可是不知道哪一個線程有read lock。

23.9.3.5 socket_instance表

Socket_instancees表提供了一個實時的鏈接活動快照。每一個tcp/ip鏈接有一行，或者每一個unix socket file鏈接有一行。

mysql> SELECT * FROM socket_instances\G

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

EVENT_NAME: wait/io/socket/sql/server_unix_socket

OBJECT_INSTANCE_BEGIN: 4316619408

THREAD_ID: 1

SOCKET_ID: 16

IP:

PORT: 0

STATE: ACTIVE

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

EVENT_NAME: wait/io/socket/sql/client_connection

OBJECT_INSTANCE_BEGIN: 4316644608

THREAD_ID: 21

SOCKET_ID: 39

IP: 127.0.0.1

PORT: 55233

STATE: ACTIVE

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

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

OBJECT_INSTANCE_BEGIN: 4316699040

THREAD_ID: 1

SOCKET_ID: 14

IP: 0.0.0.0

PORT: 50603

STATE: ACTIVE

socket記錄點名字格式，wait/io/socket/sql/socket_type：

1. 服務有一個監聽socket，記錄點那麼socket_type的值爲server_tcpip_socket或者server_unix_socket。

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的監聽，端口是服務的端口，默認爲3306，ip爲0.0.0.0

· 對於經過tcp/ip鏈接的客戶端接口，端口不爲0，ip是客戶端的ip。

23.9.4 性能框架事件等待表

事件等待表有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';

23.9.4.1 events_waits_current表

Events_waits_current表包含了當前的等待時間，每一個thread都有一行顯示當前thread的等待時間。Events_waits_current表可使用truncate table。

Events_waits_current表列：

· THREAD_ID,EVENT_ID
線程相關的事件和線程當前事件號。這2個字段造成主鍵來標示一行。

· END_EVENT_ID
當事件啓動，這個列爲null，若是時間結束分配一個事件號。

· EVENT_NAME
生成事件的記錄點名。

· SOURCE
源代碼文件名包含產生事件的記錄點代碼位置。能夠幫助用來檢查源代碼。

· TIMER_START,TIMER_END,TIMER_WAIT
事件的timing信息。時間單位爲皮秒。TIMER_START,TIMER_END表示事件的開始和結束。TIMER_WAIT是事件的持續時間。若是事件沒有完成TIMER_END,TIMER_WAIT爲null。若是記錄點的timed=no那麼這3個列都是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表示那個event被嵌套

· NESTING_EVENT_TYPE
嵌套的事件培訓，多是如下一種，TRANSACTION,STATEMENT,STAGE,WAIT

· OPERATION
執行操做的類型，lock，read，write中一個。

· NUMBER_OF_BYTES
讀寫操做的字節個數。對於表io等待，MySQL 5.7.5以前值爲null，以後爲行數。若是值大於1，是批量io操做。MySQL執行join是nested-loop機制。性能框架能夠提供行數和每一個表執行join準確的時間。假設一個join查詢，執行以下：

SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...

在join操做的時候表的錶行的增長減小(扇出)。若是t3的扇出大於1，那麼大多數行獲取操做就來自於這個表。假設t1 10行，t2 20行對應到t1一行，t3 30行對應t2 1行。那麼一共會有被記錄的操做是：

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

爲了減小被記錄操做，能夠經過每次掃描實現聚合的方式(聚合t1,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。

23.9.4.3 events_waits_history_long 表

Events_waits_history_long表每一個線程包含了最近N條數據。表結構和events_waits_current一行，也能夠被truncate table，N是服務啓動自動設置的，也能夠從參數設置: performance_schema_events_waits_history_long_size。

23.9.5 性能框架Stage事件表

性能框架stage記錄，是語句執行的階段，好比解析語句，打開表或者執行filesort操做。Stage關聯到的了show processlist中的線程狀態。

由於事件等級，等待事件穿插在stage事件，stage事件穿插在語句事件，事務事件。

Stage事件配置

啓動stage事件的收集，啓動相應的記錄點和消費者。

Setup_instruments表包含以stage開頭的記錄點名。這些記錄點除了語句處理的信息，默認是禁用的：

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

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

| NAME | ENABLED | TIMED |

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

修改stage事件，修改enabled和timing列：

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

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

Setup_consumers表包含消費者只關聯的事件表名。消費者可能用來過濾收集器stage事件。Stage消費者默認禁用：

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

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

| NAME                       | ENABLED |

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

| events_stages_current      | NO      |

| events_stages_history      | NO      |

| events_stages_history_long | NO      |

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

啓動全部的stage事件：

mysql> UPDATE setup_consumers SET ENABLED = 'YES'

    -> WHERE NAME LIKE '%stages%';

Setup_timers包含name=‘stage’，說明stage事件timing：

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

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

| NAME  | TIMER_NAME |

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

| stage | NANOSECOND |

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

修改timing值：

mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'

-> WHERE NAME = 'stage';

Stage事件進程信息

MySQL 5.7.5，性能架構stage事件表包含2列，每行提供stage進程標示：

· WORK_COMPLETED:stage工做單元完成個數。

· WORK_ESTIMATED:預期的stage工做單元完成個數。

若是沒有進度信息，每列都是null。性能框架提供一個容器來存放這些進度數據：

· 工做單元，是一個量，隨着執行時間的增長變大。

· WORK_COMPLETED，一個或者多個單元增長一次，依賴於被記錄代碼

· WORK_ESTIMATED,能夠在stage司改，根據，被記錄代碼。

對於stage事件的進度的記錄能夠實現如下任何行爲：

· 沒有進度記錄點
這個是最常出現的，由於沒有進度數據被提供，WORK_COMPLETED和WORKESTIMATED都爲bull

· 沒有被綁定記錄點
只有WORK_COMPLETED列有意義，WORK_ESTIMATED列沒有值，顯示爲0。
打開events_stages_current表監控回話，監控程序能夠報告有多少work已經被執行，可是不知道何時能夠結束，由於記錄點沒有提供。

· 綁定進度記錄點
WORK_COMPLETED和WORK_ESTIMATED列都是有意義的。
進度標識符的類型適合於已經定義了完成臨界的操做，好比表複製記錄點。經過查詢events_stages_current表來監控會話，監控程序能夠監控全部完成比例的stage，經過計算WORK_COMPLETED / WORK_ESTIMATED的比率。

stage/sql/copy to tmp table演示，進度標識符如何工做。在執行alter table語句，這個記錄點就頗有用，而且會執行很長一段時間。

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
線程相關的事件和線程當前事件號。這2個字段造成主鍵來標示一行。

· END_EVENT_ID
當事件啓動，這個列爲null，若是時間結束分配一個事件號。

· EVENT_NAME
生成事件的記錄點名。

· SOURCE
源代碼文件名包含產生事件的記錄點代碼位置。能夠幫助用來檢查源代碼。

· WORK_COMPLETED,WORK_ESTIMATED
這些列提供了stage進度信息，對於記錄點已經用來生成這些信息。WORK_COMPLETED表示有多少工做單元已經被完成，WORK_ESTIMATED表示有多少工做單元預計的stage。

· NESTING_EVENT_ID
EVENT_ID nested生成的事件。嵌套的event的stage事件一般是語句事件。

· NESTING_EVENT_TYPE
嵌套事件類型，TRANSACTION,STATEMENT,STAGE,WAIT其中一個。

23.9.5.2 events_stage_history表

Events_stages_history爲每一個線程保留了N個記錄，具體能夠經過配置參數修改：

performance_schema_events_stages_history_size

23.9.5.3 events_stage_history_long表

Events_stages_history_long爲每一個線程保留了N個記錄，具體能夠經過配置參數修改：

performance_schema_events_stages_history_long_size

23.9.6 性能框架語句事件表

性能框架記錄點語句執行。語句事件發生在高級別的事件，等待事件嵌套在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獲取事件。

請求的詳細原來是不知道的，而且性能框架從請求的順序獲取特定的記錄點名。

從客戶端收集的請求：

1. 當服務發現一個新的包在socket級別，一個新的的語句以抽象的記錄點名statement/abstract/new_packet開始。

2. 當服務讀取包序號，獲取接受的請求類型，性能框架獲取記錄點名。好比，請求是COM_PING包，那麼記錄點名會變成statement/com/ping。若是請求是COM_QUERY包，知道是一個sql語句，可是不知道具體的類型。這個時候會給一個抽象的記錄點名statement/abstract/query。

3. 若是請求的語句，文本已經讀入到分析器。分析以後，那麼準確的語句類型已經知道了，若是請求是一個插入語句，性能框架會從新定位記錄點名statement/abstract/Query to statement/sql/insert。

對於從複製的relay log上讀取語句：

1. 語句在relay log中是以文本存儲的。沒有網絡協議，因此statement/abstract /new_packet不會被使用，而是使用statement/abstract/realy_log。

2. 當語句被解析，準確的語句類型被得知。好比insert語句，那麼性能框架會從新查找記錄點名，statement/abstract/Query to statement/sql/insert。

上面介紹的，只是基於語句的複製，對於基於行的複製，訂閱錶行處理能夠被記錄，可是relay log中的行事件描述語句的並不會出現。

對於從事件調度器來的請求：

事件執行的記錄點名爲statement/scheduler/event。

事件體重的事件執行記錄點名使用statement/sql/*，不適用其餘抽象記錄點名。事件是一個存儲過程，而且存儲過程是預編譯在內存中的。那麼在執行時就不會有解析，可是類型在執行時就知道了。

在事件體內的語句都是子句。好比一個事件執行了一個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

23.9.7 性能框架事務表

性能框架事務記錄點。在事件級別，等待事件嵌套stage事件，stage事件嵌套語句事件，語句事件嵌套事務事件。

事務事件配置

Setup_instruments包含的transaction的記錄點：

mysql> SELECT * FROM setup_instruments WHERE NAME = 'transaction';

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

| NAME | ENABLED | TIMED |

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

| transaction | NO | NO |

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

啓動收集事務事件：

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

-> WHERE NAME = 'transaction';

Setup_consumers表包含transaction的消費者：

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

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

| NAME | ENABLED |

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

| events_transactions_current | NO |

| events_transactions_history | NO |

| events_transactions_history_long | NO |

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

啓動消費者：

mysql> UPDATE setup_consumers SET ENABLED = 'YES'

-> WHERE NAME LIKE '%transactions%';

設置相關記錄點：

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

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

| NAME | TIMER_NAME |

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

| transaction | NANOSECOND |

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

修改timer_name的值：

mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'

-> WHERE NAME = 'transaction';

事務綁定

在MySQL Server，使用如下語句顯示啓動事務：

START TRANSACTION | BEGIN | XA START | XA BEGIN

事務也能夠隱式啓動，當autocommit系統變量啓動。當autocommit禁用，在啓動新事務錢要顯示的結束上面一個事務。

COMMIT | ROLLBACK | XA COMMIT | XA ROLLBACK

執行DDL語句，事務會隱式提交

性能框架定義的事務綁定和服務的很類似。事務的啓動和解釋也和服務的事務狀態匹配：

· 對於顯示啓動的事務，事務events在start transaction後啓動。

· 對於隱式啓動的事務，事務事件在第一個語句執行的時候啓動。

· 對於任何事務，當執行commit，rollback事務結束。

微妙的不一樣點：

· 性能框架中的事務事件，沒有徹底包含語句事件好比START TRANSACTION,COMMIT，ROLLBACK語句。

· 語句若是運行在非實物引擎，那麼鏈接的事務狀態不會影響。

事務記錄點

3個定義的事務屬性：

· 訪問模式(read only,read write)

· 隔離級別

· 隱式或者顯示

爲了減小事務記錄點而且保證收集事務數據是完成的，有意義的結果，全部事務都有訪問模式，隔離級別，自動提交模式。

事務事件表使用3列來ACCESS_MODE,ISOLATION_LEVEL,AUTOCOMMIT記錄。

事務記錄點消費能夠有不少種方式減小，好比根據用戶，帳號，host，thread啓動或者禁用事務減了點。

線程和嵌套事件

事務事件的上級事件是初始化事務的事件。對於顯示事務啓動，包含START_TRANSACTION和commit and china,若是是隱式事務，第一個語句啓動事務。

顯示的結束事務，COMMIT,ROLLBACK，或者DDL語句，隱式的提交事務。

事務和存儲過程

事務和存儲過程事件關聯以下：

· 存儲過程
存儲過程操做獨立的事務，一個存儲過程能夠啓動一個事務，而且一個事務能夠在存儲過程當中啓動和結束。若是在一個事務中調用，一個存儲過程能夠語句強制提交事務而且啓動一個新的事務。

· 存儲函數
存儲函數能夠限制顯示或者隱式的事務提交和回滾。

· 觸發器
觸發器活動是語句的活動訪問相關的表，因此觸發器事件的上級事件激活它。

· 調度事件
事件體的語句調度事件發生一個新鏈接。

事務和savepoint

Savepoint語句以獨立的語句事件被記錄。語句事件包括SAVEPOINT,ROLLBACK TO SAVEPOINT和RELEASE SAVEPOINT語句。

事務和錯誤
事務中的錯誤和警告被記錄在語句事件中，可是不在相關的事務事件。

23.9.8 性能框架鏈接表

性能框架提供了鏈接的統計信息。當客戶端鏈接，在一個特定的用戶名和host下。性能框架爲每一個帳號跟蹤鏈接。

· Accounts:每一個客戶端帳號的鏈接統計信息。

· Hosts：每一個客戶端hostname 的鏈接統計信息。

· Users：每一個客戶端用戶名的鏈接統計信息。

帳號這裏的意思是用戶加上host。鏈接表有CURRENT_CONNECTIONS和TOTAL_CONNECTIONS列跟蹤全部的鏈接。Accounts表有USER和HOST列跟蹤用戶和host。Users和hosts表有USER和HOST列，跟蹤用戶或者host。

假設客戶端名user1，user2從hosta,hostb鏈接過來。性能框架跟蹤鏈接入選：

· Accounts會有4條記錄，user1/hosta,user1/hostb,user2/hosta,user2/host2.

· Users表有2條記錄，user1，user2

· Host表有2條記錄，hosta,hostb

當客戶端鏈接，鏈接表中若是不存在這樣的用戶或者host，那麼就增長一行不然就修改CURRENT_CONNECTIONS和TOTAL_CONNECTIONS列。

當客戶端斷開鏈接，性能框架減小current_connecitons列。

性能框架也計數內部線程和用戶會話線程驗證錯誤。對應的user和host爲null。

每一個鏈接表均可以truncate：

· 行若是是CURRENT_CONNECTIONS=0的就刪除

· 若是>0,TOTAL_CONNECTIONS設置爲CURRENT_CONNECTIONS。

· 鏈接合計表依賴於鏈接表的值會被設爲0.

23.9.9 性能框架鏈接屬性表

具體看：

http://dev.mysql.com/doc/refman/5.7/en/performance-schema-connection-attribute-tables.html

23.9.10 性能框架用戶變量表

具體看:

http://dev.mysql.com/doc/refman/5.7/en/performance-schema-user-variable-tables.html

23.9.11 性能框架複製表

MySQL 5.7.2,性能框架提供了關於複製信息的表。和show slave status的信息相似：

· Show slave status輸出能夠閱讀進行檢查，可是不能用來編程使用。

· 查詢結果能夠保存到表中，用於分析，設置變量，或者在存儲過程上使用。

· 複製表提供了更好的診斷信息，對於多線程slave操做，show slave status使用last_SQL_Errorno和last_sql_error字段報告全部的協調器和工做線程的錯誤。因此只有最近的錯誤才能可見。複製表會爲每一個線程上的錯誤保存信息不會丟失。

· 每一個工做線程的最新的事務在在複製表是可見的。可是show_slave_status。不可見。

· 開發熟悉的性能框架接口能夠擴展複製表提供更多的信息。

複製表描述

性能框架提供一下和複製有關的表：

· 關於Slave鏈接到master的鏈接信息表：

§ Replication_connection_configuration：配置鏈接到master的參數。

§ Replication_connection_status:當前鏈接到master的狀態。

· 關於slave事務應用的表

§ replication_applier_configuration:slave中事務應用的配置信息。

§ replication_applier_status:當前事務應用的狀態。

· 關於指定線程應用從master獲取事務並執行的信息：

§ Replication_applier_status_by_coordinator:applier線程狀態，以前叫replication_execute_status_by_coordinator。對於有多個work thread的複製有多個work thread和一個協調線程，對於單線程的這個表爲空。

§ Replication_applier_status_by_worker:工做線程應用狀態。同上單線程複製表爲空。

· 包含複製組成員信息的表：

§ Replication_group_members:提供網絡和組成員狀態。

§ Replication_group_member_status:提供組成員的統計信息和參與的事務。

複製表生命週期

性能框架在如下狀態下寫入複製表：

· 在執行change master to以前表爲空。

· 在執行change master to以後。配置闡述能夠在表上發現。若是這個時候沒有活動的slave 線程，那麼thread_id列爲null，serivce_state的狀態爲off。

· Start slave以後，沒有thread_id字段不爲空。線程爲空閒或者活動service_status狀態爲on。線程鏈接到master server，若是鏈接創建有個connecting值。

· Stop slave以後，thread_id爲null，而且service_State列值爲off。

· Stop slave或者thread碰到錯誤，表信息會被保留。

· Replication_applier_Status_by_worker表只有當slave操做在多線程模式下爲非空。若是slave_parallel_workers變量大於0，那麼start slave以後，行數和線程個數同樣多。

SHOW SLAVE STATUS再也不復製表中的信息

Show slave status的信息和複製表中的信息不一樣，由於這些表主要是面向GTID的複製。不是基於文件名和位置：

· 如下字段關於文件名和位置的沒有保存：

Master_Log_File

Read_Master_Log_Pos

Relay_Log_File

Relay_Log_Pos

Relay_Master_Log_File

Exec_Master_Log_Pos

Until_Condition

Until_Log_File

Until_Log_Pos

· Master_info_file字段沒有保存。參照master.info文件。

· 如下字段基於server_id,不是server_uuid，沒有被保存：

Master_Server_Id

Replicate_Ignore_Server_Ids

· Skip_counter列基於事件個數，不是gtid沒有被保存。

· 錯誤列是last_sql_errno,last_sql_error的別名，所以不被保存

Last_Errno

Last_Error

在性能框架中，replication_applier_status_by_coodinator和表replication _applier_status_by_worker中的last_error_number和last_error_message列保存了錯誤信息。

· 命令行過濾操做的信息不被保存：

Replicate_Do_DB

Replicate_Ignore_DB

Replicate_Do_Table

Replicate_Ignore_Table

Replicate_Wild_Do_Table

Replicate_Wild_Ignore_Table

· Slave_io_State和slave_sql_running_state列沒有保存。若是須要能夠經過thread_id關聯上perocesslist表獲取表中的status值。

· Executed_gtid_set字段能夠顯示大量的文字。和性能框架表中顯示已經被slave應用的事務的GTID。已經被執行的GTID能夠經過gtid_executed系統變量獲取。

· Seconds_behind_master和relay_log_spae用來將要被決定的狀態不保留。

狀態變量移動到了複製表

從mysql 5.7.5,如下狀態被移動到了性能框架複製表：

Slave_retried_transactions

Slave_last_heartbeat

Slave_received_heartbeats

Slave_heartbeat_period

Slave_running

這些變量用於單源複製，由於只能彙報默認源複製。當有多個複製源，可使用性能複製表，彙報每一個複製渠道的狀態。

多源複製

性能框架表的第一列是channel_name.能夠看到每一個複製源。

23.9.11.1 replication_connection_configure表

表顯示了鏈接到slave服務的鏈接配置。參數被保存在表中，在change master執行的時候會被修改。

replication_connection_configuration表包含如下列：

· CHANNEL_NAME：複製源名。

· HOST:master的host名。

· PORT:master的端口

· USER:鏈接用戶

· NETWORK_INTERFACE:slave綁定的network接口。

· AUTO_POSITION:若是自定定位被使用了就是1，不然是0

· SSL_ALLOWED, SSL_CA_FILE, SSL_CA_PATH, SSL_CERTIFICATE, SSL_CIPHER, SSL_KEY, SSL_VERIFY_SERVER_CERTIFICATE, SSL_CRL_FILE, SSL_CRL_PATH
這些列顯示了slave鏈接到master的SSL的參數SSL_ALLOWED的值以下：

§ Yes，若是SSL鏈接到master被容許。

§ No，若是SSL鏈接到master不被容許。

§ Ignored,若是SSL被容許，可是slave不支持SSL。

Change master to選項還有其餘ssl選項：MASTER_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_INTERVAL:重試的秒數。

· CONNECTION_RETRY_COUNT:失誤鏈接以後重試的次數。

· HEARTBEAT_INTERVAL:複製心跳間隔。

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

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_RETRIES:顯示了sql thread應用事務錯誤，致使重試的次數。

23.9.11.5 replication_applier_status_by_coordinator

對於多線程的slave，slave使用多個工做線程和一個協調線程，協調線程用來管理工做線程，表顯示了協調線程的狀態。若是是單線程slave，表爲空。

Replication_applier_status_by_coordinator列：

· CHANNEL_NAME:複製來源名。

· THREAD_ID:SQL/協調線程id。

· LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE：最後一次錯誤號和錯誤信息。

· LAST_ERROR_TIMESTRAMP:時間戳格式爲YYMMDD HH:MM:SS。

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會被保留，知道下一個事務運行完成。

§ 當下一個GTID被其餘線程獲取，從gtid_next上得到。

· LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE：最後一次錯誤號和錯誤信息。

· LAST_ERROR_TIMESTRAMP:時間戳格式爲YYMMDD HH:MM:SS。

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插件已經安裝可是沒有啓動。

§ RECOVERING:服務已經加入到一個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_MEMBERS:固化的group事務集合。

· LAST_CONFLICT_FREE_TRANSACTION:最後一個沒有衝突的被認證的事務。

23.9.12 性能框架鎖相關表

23.9.12.1 metadata_locks

性能框架把元數據鎖經過metadata_locks顯示。顯示一下信息：

· 鎖已經被分配

· 鎖被請求可是沒有被分配。

· 鎖請求可是被死鎖kill或者鎖等待超時而被取消。

這些信息能夠了解元數據鎖和會話之間的關係。能夠查看等待的鎖，也能夠查看已經獲取的鎖。

Metadata_locks表只讀，不能寫入。默認是自動大小的，也能夠經過啓動參數配置大小：performance_schema_max_metadata_locks。

表默認是被禁用的，拖過設置setup_instruments的/locl/metadata/sql/mdl來啓動。

性能框架維護內容，使用lock_status表示鎖的狀態：

· 當元數據鎖被請求而且立刻獲取，行的狀態的是GRANTED。

· 當元數據鎖被請求可是沒有立刻得到，行的狀態爲pending。

· 當以前請求的元數據鎖獲取了，行的狀態改成granted。

· 當元數據鎖被釋放，行被刪除。

· 當pending的鎖請求被死鎖發現器取消，狀態改成victim。

· 當pending的鎖超時，狀態變爲pending to timeout。

· 當分配的鎖或者pending的鎖被kill，狀態變爲killed。

· 當VICTIM,TIMEOUT,KILLED被通知以後行會被刪除。

· PRE_ACQUIRE_NOTIFY,POST_RELEASE_NOTIFY狀態，當獲取鎖或者釋放鎖時，lock子系統通知所在的存儲引擎的狀態。

Metadata_locks列：

· OBJECT_TYPE:能夠是這些值的其中一個. GLOBAL, SCHEMA, TABLE, FUNCTION, PROCEDURE, TRIGGER (currently unused), EVENT, COMMIT, USER LEVEL LOCK, TABLESPACE, LOCKING SERVICE。
若是值爲USER LEVEL LOCK表示從get_lock()獲取鎖，若是是LOCKING SERVICE表示使用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。

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 PRIORITY, READ NO INSERT, WRITE ALLOW WRITE, WRITE CONCURRENT INSERT, WRITE LOW PRIORITY, WRITE。

· EXTERNAL_LOCK：存儲引擎級別使用的表鎖，READ EXTERNAL ,WRITE EXTERNAL

23.9.13 性能框架系統變量表

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 。

23.9.14 性能框架系統狀態變量表

和系統變量表相似，具體看：
http://dev.mysql.com/doc/refman/5.7/en/performance-schema-status-variable-tables.html

23.9.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:狀態變量用戶合計

23.9.16 性能框架其餘表

除了上面你的表還有3個表：

· Host_cache：內部host cache信息。

· Performance_timers:事件可用定時器。

· Threads:服務的線程表。

23.10 性能框架選項和變量

具體看：

http://dev.mysql.com/doc/refman/5.7/en/performance-schema-option-variable-reference.html

23.11 性能框架命令選項

具體看：

http://dev.mysql.com/doc/refman/5.7/en/performance-schema-options.html

23.12 性能框架系統變量

具體看：

http://dev.mysql.com/doc/refman/5.7/en/performance-schema-system-variables.html

23.13 性能框架狀態變量

具體看：

http://dev.mysql.com/doc/refman/5.7/en/performance-schema-status-variables.html

23.14 性能框架內存分配模型

在mysql 5.7.6以前，性能框架使用如下內存分配模型：

· 全部的內存在啓動時分配。

· 服務操做的時候不分配內存。

· 服務操做的時候不釋放內存。

· 在服務關閉的時候釋放內存。

使用這個模型，性能框架會分配大量的內存，除非顯示的配置。Mysql 5.7.6以後的分配模型：

· 能夠在服務啓動的時候分配。

· 能夠在服務操做的時候額外分配。

· 在服務操做的時候不釋放。

· 在服務關閉的時候釋放內存。

這樣能夠根據負荷來調整內存使用，不是現實配置。

有一些性能框架配置參數是自動分配，也能夠手動分配：

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

對於自動配置的參數，配置基本以下：

· 若是爲-1，默認，參數是自動配置的。

§ 初始對應的內部buffer爲空，沒有內存。

§ 當性能框架開始收集數據，沒存被分配到想要的buffer。buffer大小沒有上限，隨着負荷上升上漲。

· 若是設置爲0：

§ 初始內部buffer爲空，也不會分配內存。

· 若是設置的N>0:

§ 對象的內部buffer爲空，而且不分配內存。

§ 當數據開始收集，內存開始分配，直到設置的大小。

§ 一旦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/%';

23.15 性能框架和

具體看：

http://dev.mysql.com/doc/refman/5.7/en/performance-schema-and-plugins.html

23.16 使用性能框架診斷

性能框架可讓dba來作一些性能調整，好比一個重複出現的性能問題:

1.運行用例

2.使用性能框架表，分析根本的性能問題。分析嚴重依賴於post過濾。

3.問題區域已經劃出，禁用對應的記錄點。好比若是分析出和文件io不相關，禁用io的記錄點。

4.重複步驟1-3，這樣能夠減小干擾找出真正的問題。

5.明確了性能瓶頸的緣由：

§ 調整服務參數

§ 調整查詢。

§ 調整數據庫結構

§ 調整代碼。

6.重複步驟1，查看對性能的影響。

在性能調優的時候，mutex_instances.locked_by_thread_id，rwlock_instances. write_locked_by_thread_id列十分重要。好比：

1.線程1，在等待一個信號量。

2.可使用如下語句查看等待的信號量：

SELECT * FROM events_waits_current WHERE THREAD_ID = thread_1;

3.而後查看那個線程持有着這個信號量:

SELECT * FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN = mutex_A;

4.查看線程2在作什麼：

SELECT * FROM events_waits_current WHERE THREAD_ID = thread_2;

23.17 遷移到性能框架系統和狀態變量表

Information_schema有表包含了系統和狀態變量信息，MySQL 5.7.6以後，性能框架也包含了系統變量和狀態變量信息。性能框架的表會取代information_schema上的表。

在mysql 5.6查看狀態變量和系統變量來自於：

SHOW VARIABLES
SHOW STATUS

INFORMATION_SCHEMA.GLOBAL_VARIABLES
INFORMATION_SCHEMA.SESSION_VARIABLES

INFORMATION_SCHEMA.GLOBAL_STATUS
INFORMATION_SCHEMA.SESSION_STATUS

Mysql 5.7.6，性能框架也包含了系統變量和狀態變量：

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_56系統變量，若是爲on：

· 當從information_schema中輸出，會出現警告。

· 在mysql 5.7.6，使用show的where語句就會警告。MySQL 5.7.8以後就不會。

當變量爲off，不啓動兼容模式:

· 搜索information_schema表會報錯。

· Show語句輸出的數據來至於性能框架表。

· 這些slave_XXX的狀態變量不可用:

Slave_heartbeat_period
Slave_last_heartbeat
Slave_received_heartbeats
Slave_retried_transactions
Slave_running

應該從性能框架的複製相關的表中獲取數據。

遷移和權限

訪問性能框架中的系統變量和狀態變量須要select權限。若是show_compatibility_56爲off，那麼show variables和show status也須要select權限，若是兼容性關閉，這些語句輸出來至於性能框架的global_variables,session_variables,global_status, session_status表。

在mysql 5.7.9，這些表在性能礦建中訪問不須要select權限。對應的show variables和show status也不須要權限。

以後的發佈，information_schema變量表和show_compatibility_56會被刪除，show輸出基於性能框架表。