|  事務事件統計表

performance_schema把事務事件統計表也按照與等待事件統計表類似的規則進行分類統計，事務事件instruments只有一個transaction，默認禁用，事務事件統計表有如下幾張表：

* 事務事件的收集不考慮隔離級別，訪問模式或自動提交模式 

* 讀寫事務通常比只讀事務占用更多資源，因此事務統計表包含了用于讀寫和只讀事務的單獨統計列 

* 事務所占用的資源需求多少也可能會因事務隔離級別有所差異(例如：鎖資源)。但是：每個server可能是使用相同的隔離級別，所以不單獨提供隔離級別相關的統計列

PS：對這些表使用truncate語句，影響與等待事件類似。

|  語句事件統計表

performance_schema把語句事件統計表也按照與等待事件統計表類似的規則進行分類統計，語句事件instruments默認全部開啟，所以，語句事件統計表中默認會記錄所有的語句事件統計信息，語句事件統計表包含如下幾張表：

events_statements_summary_by_account_by_event_name：按照每個帳戶和語句事件名稱進行統計

events_statements_summary_by_digest：按照每個庫級別對象和語句事件的原始語句文本統計值（md5 hash字符串）進行統計，該統計值是基于事件的原始語句文本進行精煉(原始語句轉換為標準化語句)，每行數據中的相關數值字段是具有相同統計值的統計結果。

events_statements_summary_by_host_by_event_name：按照每個主機名和事件名稱進行統計的Statement事件

events_statements_summary_by_program：按照每個存儲程序（存儲過程和函數，觸發器和事件）的事件名稱進行統計的Statement事件

events_statements_summary_by_thread_by_event_name：按照每個線程和事件名稱進行統計的Statement事件

events_statements_summary_by_user_by_event_name：按照每個用戶名和事件名稱進行統計的Statement事件

events_statements_summary_global_by_event_name：按照每個事件名稱進行統計的Statement事件

prepared_statements_instances：按照每個prepare語句實例聚合的統計信息

可通過如下語句查看語句事件統計表：

* FIRST_SEEN，LAST_SEEN：顯示某給定語句第一次插入    events_statements_summary_by_digest表和最后一次更新該表的時間戳

events_statements_summary_by_program表有自己額外的統計列：

* COUNT_STATEMENTS，SUM_STATEMENTS_WAIT，MIN_STATEMENTS_WAIT，AVG_STATEMENTS_WAIT，MAX_STATEMENTS_WAIT：關于存儲程序執行期間調用的嵌套語句的統計信息

prepared_statements_instances表有自己額外的統計列：

* COUNT_EXECUTE，SUM_TIMER_EXECUTE，MIN_TIMER_EXECUTE，AVG_TIMER_EXECUTE，MAX_TIMER_EXECUTE：執行prepare語句對象的統計信息

PS1：

關于events_statements_summary_by_digest表

如果setup_consumers配置表中statements_digest consumers啟用，則在語句執行完成時，將會把語句文本進行md5 hash計算之后 再發送到events_statements_summary_by_digest表中。分組列基于該語句的DIGEST列值(md5 hash值) 

* 如果給定語句的統計信息行在events_statements_summary_by_digest表中已經存在，則將該語句的統計信息進行更新，并更新LAST_SEEN列值為當前時間 

* 如果給定語句的統計信息行在events_statements_summary_by_digest表中沒有已存在行，并且events_statements_summary_by_digest表空間限制未滿的情況下，會在events_statements_summary_by_digest表中新插入一行統計信息，FIRST_SEEN和LAST_SEEN列都使用當前時間 

* 如果給定語句的統計信息行在events_statements_summary_by_digest表中沒有已存在行，且events_statements_summary_by_digest表空間限制已滿的情況下，則該語句的統計信息將添加到DIGEST 列值為 NULL的特殊“catch-all”行，如果該特殊行不存在則新插入一行，FIRST_SEEN和LAST_SEEN列為當前時間。如果該特殊行已存在則更新該行的信息，LAST_SEEN為當前時間

由于performance_schema表內存限制，所以維護了DIGEST = NULL的特殊行。 當events_statements_summary_by_digest表限制容量已滿的情況下，且新的語句統計信息在需要插入到該表時又沒有在該表中找到匹配的DIGEST列值時，就會把這些語句統計信息都統計到 DIGEST = NULL的行中。此行可幫助您估算events_statements_summary_by_digest表的限制是否需要調整

* 如果DIGEST = NULL行的COUNT_STAR列值占據整個表中所有統計信息的COUNT_STAR列值的比例大于0%，則表示存在由于該表限制已滿導致部分語句統計信息無法分類保存，如果你需要保存所有語句的統計信息，可以在server啟動之前調整系統變量performance_schema_digests_size的值，默認大小為200

PS2：關于存儲程序監控行為：對于在setup_objects表中啟用了instruments的存儲程序類型，events_statements_summary_by_program將維護存儲程序的統計信息，如下所示：

當某給定對象在server中首次被使用時（即使用call語句調用了存儲過程或自定義存儲函數時），將在events_statements_summary_by_program表中添加一行統計信息；

當某給定對象被刪除時，該對象在events_statements_summary_by_program表中的統計信息行將被刪除；

當某給定對象被執行時，其對應的統計信息將記錄在events_statements_summary_by_program表中并進行統計。

PS3：對這些表使用truncate語句，影響與等待事件類似。

|  內存事件統計表

performance_schema把內存事件統計表也按照與等待事件統計表類似的規則進行分類統計。

performance_schema會記錄內存使用情況并聚合內存使用統計信息，如：使用的內存類型（各種緩存，內部緩沖區等）和線程、帳號、用戶、主機的相關操作間接執行的內存操作。performance_schema從使用的內存大小、相關操作數量、高低水位（內存一次操作的最大和最小的相關統計值）。

內存大小統計信息有助于了解當前server的內存消耗，以便及時進行內存調整。內存相關操作計數有助于了解當前server的內存分配器的整體壓力，及時掌握server性能數據。例如：分配單個字節一百萬次與單次分配一百萬個字節的性能開銷是不同的，通過跟蹤內存分配器分配的內存大小和分配次數就可以知道兩者的差異。

檢測內存工作負載峰值、內存總體的工作負載穩定性、可能的內存泄漏等是至關重要的。

內存事件instruments中除了performance_schema自身內存分配相關的事件instruments配置默認開啟之外，其他的內存事件instruments配置都默認關閉的，且在setup_consumers表中沒有像等待事件、階段事件、語句事件與事務事件那樣的單獨配置項。

PS：內存統計表不包含計時信息，因為內存事件不支持時間信息收集。

內存事件統計表有如下幾張表：

從上面表中的示例記錄信息中，我們可以看到，同樣與等待事件類似，按照用戶、主機、用戶+主機、線程等緯度進行分組與統計的列，分組列與等待事件類似，這里不再贅述，但對于內存統計事件，統計列與其他幾種事件統計列不同（因為內存事件不統計時間開銷，所以與其他幾種事件類型相比無相同統計列），如下：

每個內存統計表都有如下統計列： 

* COUNT_ALLOC，COUNT_FREE：對內存分配和釋放內存函數的調用總次數 

* SUM_NUMBER_OF_BYTES_ALLOC，SUM_NUMBER_OF_BYTES_FREE：已分配和已釋放的內存塊的總字節大小 

* CURRENT_COUNT_USED：這是一個便捷列，等于COUNT_ALLOC - COUNT_FREE 

* CURRENT_NUMBER_OF_BYTES_USED：當前已分配的內存塊但未釋放的統計大小。這是一個便捷列，等于SUM_NUMBER_OF_BYTES_ALLOC - SUM_NUMBER_OF_BYTES_FREE 

* LOW_COUNT_USED，HIGH_COUNT_USED：對應CURRENT_COUNT_USED列的低和高水位標記 

* LOW_NUMBER_OF_BYTES_USED，HIGH_NUMBER_OF_BYTES_USED：對應CURRENT_NUMBER_OF_BYTES_USED列的低和高水位標記

內存統計表允許使用TRUNCATE TABLE語句。使用truncate語句時有如下行為： 

* 通常，truncate操作會重置統計信息的基準數據（即清空之前的數據），但不會修改當前server的內存分配等狀態。也就是說，truncate內存統計表不會釋放已分配內存 

 * 將COUNT_ALLOC和COUNT_FREE列重置，并重新開始計數（等于內存統計信息以重置后的數值作為基準數據）

* SUM_NUMBER_OF_BYTES_ALLOC和SUM_NUMBER_OF_BYTES_FREE列重置與COUNT_ALLOC和COUNT_FREE列重置類似 

* LOW_COUNT_USED和HIGH_COUNT_USED將重置為CURRENT_COUNT_USED列值 

*  LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED將重置為CURRENT_NUMBER_OF_BYTES_USED列值 

* 此外，按照帳戶，主機，用戶或線程分類統計的內存統計表或memory_summary_global_by_event_name表，如果在對其依賴的accounts、hosts、users表執行truncate時，會隱式對這些內存統計表執行truncate語句

關于內存事件的行為監控設置與注意事項

內存行為監控設置：

* 內存instruments在setup_instruments表中具有memory/code_area/instrument_name格式的名稱。但默認情況下大多數instruments都被禁用了，默認只開啟了memory/performance_schema/*開頭的instruments

* 以前綴memory/performance_schema命名的instruments可以收集performance_schema自身消耗的內部緩存區大小等信息。memory/performance_schema/* instruments默認啟用，無法在啟動時或運行時關閉。performance_schema自身相關的內存統計信息只保存在memory_summary_global_by_event_name表中，不會保存在按照帳戶，主機，用戶或線程分類聚合的內存統計表中

* 對于memory instruments，setup_instruments表中的TIMED列無效，因為內存操作不支持時間統計

* 注意：如果在server啟動之后再修改memory instruments，可能會導致由于丟失之前的分配操作數據而導致在釋放之后內存統計信息出現負值，所以不建議在運行時反復開關memory instruments，如果有內存事件統計需要，建議在server啟動之前就在my.cnf中配置好需要統計的事件采集

當server中的某線程執行了內存分配操作時，按照如下規則進行檢測與聚合：

* 如果該線程在threads表中沒有開啟采集功能或者說在setup_instruments中對應的instruments沒有開啟，則該線程分配的內存塊不會被監控

* 如果threads表中該線程的采集功能和setup_instruments表中相應的memory instruments都啟用了，則該線程分配的內存塊會被監控

對于內存塊的釋放，按照如下規則進行檢測與聚合：

* 如果一個線程開啟了采集功能，但是內存相關的instruments沒有啟用，則該內存釋放操作不會被監控到，統計數據也不會發生改變

* 如果一個線程沒有開啟采集功能，但是內存相關的instruments啟用了，則該內存釋放的操作會被監控到，統計數據會發生改變，這也是前面提到的為啥反復在運行時修改memory instruments可能導致統計數據為負數的原因

對于每個線程的統計信息，適用以下規則。

當一個可被監控的內存塊N被分配時，performance_schema會對內存統計表中的如下列進行更新： 

* COUNT_ALLOC：增加1 

* CURRENT_COUNT_USED：增加1 

* HIGH_COUNT_USED：如果CURRENT_COUNT_USED增加1是一個新的最高值，則該字段值相應增加 

* SUM_NUMBER_OF_BYTES_ALLOC：增加N 

* CURRENT_NUMBER_OF_BYTES_USED：增加N 

* HIGH_NUMBER_OF_BYTES_USED：如果CURRENT_NUMBER_OF_BYTES_USED增加N之后是一個新的最高值，則該字段值相應增加

當一個可被監控的內存塊N被釋放時，performance_schema會對統計表中的如下列進行更新： 
* COUNT_FREE：增加1 
* CURRENT_COUNT_USED：減少1 
* LOW_COUNT_USED：如果CURRENT_COUNT_USED減少1之后是一個新的最低值，則該字段相應減少 
* SUM_NUMBER_OF_BYTES_FREE：增加N 
* CURRENT_NUMBER_OF_BYTES_USED：減少N 
* LOW_NUMBER_OF_BYTES_USED：如果CURRENT_NUMBER_OF_BYTES_USED減少N之后是一個新的最低值，則該字段相應減少

對于較高級別的聚合（全局，按帳戶，按用戶，按主機）統計表中，低水位和高水位適用于如下規則 ：
* LOW_COUNT_USED和LOW_NUMBER_OF_BYTES_USED是較低的低水位估算值。performance_schema輸出的低水位值可以保證統計表中的內存分配次數和內存小于或等于當前server中真實的內存分配值 
* HIGH_COUNT_USED和HIGH_NUMBER_OF_BYTES_USED是較高的高水位估算值。performance_schema輸出的低水位值可以保證統計表中的內存分配次數和內存大于或等于當前server中真實的內存分配值

對于內存統計表中的低水位估算值，在memory_summary_global_by_event_name表中如果內存所有權在線程之間傳輸，則該估算值可能為負數

|  溫馨提示

性能事件統計表中的數據條目是不能刪除的，只能把相應統計字段清零；

性能事件統計表中的某個instruments是否執行統計，依賴于在setup_instruments表中的配置項是否開啟；

性能事件統計表在setup_consumers表中只受控于"global_instrumentation"配置項，也就是說一旦"global_instrumentation"配置項關閉，所有的統計表的統計條目都不執行統計（統計列值為0）；

內存事件在setup_consumers表中沒有獨立的配置項，且memory/performance_schema/* instruments默認啟用，無法在啟動時或運行時關閉。performance_schema相關的內存統計信息只保存在memory_summary_global_by_event_name表中，不會保存在按照帳戶，主機，用戶或線程分類聚合的內存統計表中。

| 作者簡介

羅小波·沃趣科技高級數據庫技術專家

IT從業多年，歷任運維工程師、高級運維工程師、運維經理、數據庫工程師，曾參與版本發布系統、輕量級監控系統、運維管理平臺、數據庫管理平臺的設計與編寫，熟悉MySQL體系結構，Innodb存儲引擎，喜好專研開源技術，追求完美。