MySQL--performance schema學習

啓用performance schema

在MySQL 5.6.6版本後，performance schema被默認打開
一般MySQL的二進制版本都默認支持PS,
若是使用編譯源碼安裝，在cmake時須要使用參數DWITH_PERFSCHEMA_STORAGE_ENGINE=1來支持PS

performance schema 是以存儲引擎的方式實現的,所以可使用如下兩種方式肯定PS是否可用
## 檢查方式1
SELECT *
FROM INFORMATION_SCHEMA.ENGINES
WHERE ENGINE='PERFORMANCE_SCHEMA'\G

## 檢查方式2
show engines \G

在MySQL配置文件中，可使用performance_schema=ON來設置自動啓用並初始化performance schema
performance schema初始化完成後，能夠像訪問正常數據庫同樣使用performance_schema庫。

 

配置performance schema

##=============================================================================##
performance_schema庫中以setup爲前綴的表存放相關配置信息：
setup_actors：配置用戶緯度的監控，默認監控全部用戶。
setup_consumers：配置events的消費者類型，即收集的events寫入到哪些統計表中。
setup_instruments：配置具體的instrument，主要包含4大類：idle、stage/xxx、statement/xxx、wait/xxx：
setup_objects：配置監控對象，默認對mysql，performance_schema和information_schema中的表都不監控，而其它DB的全部表都監控。
setup_timers：配置每種類型指令的統計時間單位。MICROSECOND表示統計單位是微妙，CYCLE表示統計單位是時鐘週期，時間度量與CPU的主頻有關，NANOSECOND表示統計單位是納秒。但不管採用哪一種度量單位，最終統計表中統計的時間都會裝換到皮秒。（1秒＝1000000000000皮秒）

##=============================================================================##
更新表setup_consumers中數據後會當即生效，但不會持久化保存，
所以若是須要永久生效，須要在配置文件中進行配置，如：
[mysqld]
#performance_schema
performance_schema_consumer_events_waits_current=on
performance_schema_consumer_events_stages_current=on
performance_schema_consumer_events_statements_current=on
performance_schema_consumer_events_waits_history=on
performance_schema_consumer_events_stages_history=on
performance_schema_consumer_events_statements_history=on

performance_schema_consumer_XX存在層級關係，當上層被禁用後，即便下層開啓，仍沒法生效。
表setup_consumers裏面的值有個層級關係：
LEVEL1: global_instrumentation 
LEVEL2:    thread_instrumentation,statements_digest
LEVEL3:    events_stages_current,events_statements_current,events_waits_current
LEVEL4: events_stages_history,events_statements_history,events_waits_history
LEVEL5: events_stages_history_long,events_statements_history_long,events_waits_history_long
以_current後綴的存放當前事件信息，
以_history和_history_long爲後綴的表存放的是_current錶的歷史記錄，
_history表默認存放最近等待的10個事件，而_history_long默認存放最近1000個等待事件

_history表存放等待事件的數量能夠經過參數來控制：
SHOW VARIABLES LIKE 'performance_schema%history%size';

##=============================================================================##
當PS啓用後，並非全部事件都會收集，能夠查看setup_instruments表來查看那些事件被收集。
SELECT * 
FROM setup_instruments;

參考：https://dev.mysql.com/doc/refman/5.6/en/setup-instruments-table.html

對於setup_instruments表中記錄，只有當ENABLED和ENABLED同時被激活狀態下，纔會收集事件

setup_instruments表中包含4大類數據：idle、stage/xxx、statement/xxx、wait/xxx.
idle表示socket空閒的時間，
stage類表示語句的每一個執行階段的統計，
statement類統計語句維度的信息，
wait類統計各類等待事件，好比IO，mutux，spin_lock,condition等。
##=============================================================================##

參考鏈接：
http://www.cnblogs.com/zhoujinyi/p/5236705.html
http://keithlan.github.io/2015/07/17/22_performance_schema/

 

performance schema對象

##=============================================================================##
cond_instances：條件等待對象實例
表中記錄了系統中使用的條件變量的對象，OBJECT_INSTANCE_BEGIN爲對象的內存地址。


##=============================================================================##
file_instances：文件實例
表中記錄了系統中打開了文件的對象，包括ibdata文件，redo文件，binlog文件，用戶的表文件等，open_count顯示當前文件打開的數目，若是重來沒有打開過，不會出如今表中。

## 查看打開次數較高的文件
SELECT * 
FROM file_instances 
ORDER BY OPEN_COUNT DESC 
LIMIT 10\G


##=============================================================================##
mutex_instances：互斥同步對象實例
表中記錄了系統中使用互斥量對象的全部記錄，其中name爲：wait/synch/mutex/*。
LOCKED_BY_THREAD_ID顯示哪一個線程正持有mutex，若沒有線程持有，則爲NULL。


##=============================================================================##
rwlock_instances： 讀寫鎖同步對象實例
表中記錄了系統中使用讀寫鎖對象的全部記錄，其中name爲 wait/synch/rwlock/*。
WRITE_LOCKED_BY_THREAD_ID爲正在持有該對象的thread_id，若沒有線程持有，
則爲NULL。READ_LOCKED_BY_COUNT爲記錄了同時有多少個讀者持有讀鎖。
經過 events_waits_current 表能夠知道，哪一個線程在等待鎖；
經過rwlock_instances知道哪一個線程持有鎖。
rwlock_instances的缺陷是，只能記錄持有寫鎖的線程，對於讀鎖則無能爲力。


##=============================================================================##
socket_instances：活躍會話對象實例
表中記錄了thread_id,socket_id,ip和port，其它表能夠經過thread_id與socket_instance進行關聯，獲取IP-PORT信息，可以與應用對接起來。
event_name主要包含3類：
wait/io/socket/sql/server_unix_socket，服務端unix監聽socket
wait/io/socket/sql/server_tcpip_socket，服務端tcp監聽socket
wait/io/socket/sql/client_connection，客戶端socket

 

 performance schema表

##=============================================================================##wait相關表
1.events_waits_current：記錄了當前線程等待的事件
2.events_waits_history：記錄了每一個線程最近等待的10個事件
3.events_waits_history_long：記錄了最近全部線程產生的10000個事件


##=============================================================================##stage相關表
1.events_stages_current：記錄了當前線程所處的執行階段
2.events_stages_history：記錄了當前線程所處的執行階段10條歷史記錄
3.events_stages_history_long：記錄了當前線程所處的執行階段10000條歷史記錄


##=============================================================================##
Statement相關表
1.events_statements_current：經過 thread_id+event_id能夠惟一肯定一條記錄。
Statments表只記錄最頂層的請求，SQL語句或是COMMAND，每條語句一行。
event_name形式爲statement/sql/*，或statement/com/*

2.events_statements_history
3.events_statements_history_long

##=============================================================================##
Connection相關表
1.users：記錄用戶鏈接數信息
2.hosts：記錄了主機鏈接數信息
3.accounts：記錄了用戶主機鏈接數信息


##=============================================================================##
Summary 表： Summary表彙集了各個維度的統計信息包括表維度，索引維度，會話維度，語句維度和鎖維度的統計信息
1，events_waits_summary_global_by_event_name：按等待事件類型聚合，每一個事件一條記錄
2，events_waits_summary_by_instance：按等待事件對象聚合，同一種等待事件，可能有多個實例，每一個實例有不一樣的內存地址，所以
event_name+object_instance_begin惟一肯定一條記錄。
3，events_waits_summary_by_thread_by_event_name：按每一個線程和事件來統計，thread_id+event_name惟一肯定一條記錄。
4，events_stages_summary_global_by_event_name：按事件階段類型聚合，每一個事件一條記錄，表結構同上。
5，events_stages_summary_by_thread_by_event_name：按每一個線程和事件來階段統計，表結構同上。
6，events_statements_summary_by_digest：按照事件的語句進行聚合。
7，events_statements_summary_global_by_event_name：按照事件的語句進行聚合。表結構同上。
8，events_statements_summary_by_thread_by_event_name：按照線程和事件的語句進行聚合，表結構同上。
9，file_summary_by_instance：按事件類型統計（物理IO維度）
10，file_summary_by_event_name：具體文件統計（物理IO維度）
11，table_io_waits_summary_by_table：根據wait/io/table/sql/handler，聚合每一個表的I/O操做（邏輯IO緯度）
12，table_io_waits_summary_by_index_usage：與table_io_waits_summary_by_table相似，按索引維度統計
13，table_lock_waits_summary_by_table：聚合了表鎖等待事件，包括internal lock 和 external lock
	internal lock經過SQL層函數thr_lock調用，OPERATION值爲：
	read normal、read with shared locks、read high priority、read no insert、write allow write、write concurrent insert、write delayed、write low priority、write normal
	external lock則經過接口函數handler::external_lock調用存儲引擎層，OPERATION列的值爲：read external、write external

14，Connection Summaries表：account、user、host
15，socket_summary_by_instance、socket_summary_by_event_name：socket聚合統計表。