羅小波·沃趣科技進階資料庫技術專家
出品 沃趣科技
IT從業多年，曆任運維工程師，進階運維工程師，運維經理，資料庫工程師，曾參與版本釋出系統，輕量級監控系統，運維管理平台，資料庫管理平台的設計與編寫，熟悉MySQL的體系結構時，InnoDB存儲引擎，喜好專研開源技術，追求完美。
不知不覺中，performance_schema系列快要接近尾聲了，今天将帶領大家一起踏上系列第六篇的征程(全系共6個篇章)，在這一期裡，我們将為大家全面講解performance_schema中的複制狀态與變量統計表。下面，請跟随我們一起開始performance_schema系統的學習之旅吧～
01
複制資訊統計表
通常，DBA或相關資料庫運維人員在檢視從庫的複制相關的資訊，都習慣性的使用show slave status語句檢視。也許你會說，我也會用performance_schema下的表檢視一些複制報錯資訊什麼的。但是，你知道show slave status語句、mysql系統庫下的複制資訊記錄表、performance_schema系統庫下的複制資訊記錄表之間有什麼差別嗎？不知道？别急，本文即将為你詳細介紹show slave status語句與performance_schema系統庫下的複制資訊記錄表的差別（mysql系統庫下的複制表差別詳見後續 "mysql系統庫全方位介紹"系列）。
在開始詳細介紹每一張複制資訊表之前，我們先花費一些篇幅來整體認識一下這些表。
performance_schema 系統庫下提供了如下幾個與複制狀态相關的表（表含義詳見本文後續小節）：
- replication_applier_configuration
- replication_applier_status
- replication_applier_status_by_coordinator
- replication_applier_status_by_worker
- replication_connection_configuration
- replication_connection_status
- replication_group_member_stats
- replication_group_members
這些複制表中記錄的資訊生命周期如下(生命周期即指的是這些表中的資訊什麼時候寫入，什麼時候會被修改，什麼時候會被清理等）：
- 在執行CHANGE MASTER TO之前，這些表是空的
- 執行CHANGE MASTER TO之後，在配置參數表replication_applier_configuration和replication_connection_configuration中可以檢視到配置資訊了。此時，由于并沒有啟動複制，是以表中THREAD_ID列為NULL，SERVICE_STATE列的值為OFF（這兩個字段存在與表replication_applier_status、replication_applier_status_by_coordinator、replication_applier_status_by_worker、replication_connection_status幾個表中）
-
執行START SLAVE後，可以看到連接配接線程和協調器線程，工作線程狀态表中的THREAD_ID字段被配置設定了一個值，且SERVICE_STATE字段被修改為ON了，THREAD_ID字段值與show processlist語句中看到的線程id相同。
* 如果IO線程空閑或正在從主庫接收binlog時，線程的SERVICE_STATE值會一直為ON，THREAD_ID線程記錄線程ID值，如果IO線程正在嘗試連接配接主庫但還沒有成功建立連接配接時，THREAD_ID記錄CONNECTING值，THREAD_ID字段記錄線程ID，如果IO線程與主庫的連接配接斷開，或者主動停止IO線程，則SERVICE_STATE字段記錄為OFF，THREAD_ID字段被修改為NULL
- 執行 STOP SLAVE之後，所有複制IO線程、協調器線程、工作線程狀态表中的THREAD_ID列變為NULL，SERVICE_STATE列的值變為OFF。注意：停止複制相關線程之後，這些記錄并不會被清理 ，因為複制意外終止或者臨時需要會執行停止操作，可能需要擷取一些狀态資訊用于排錯或者其他用途。
- 執行RESET SLAVE之後，所有記錄複制配置和複制狀态的表中記錄的資訊都會被清除。但是show slave status語句還是能檢視到一些複制狀态和配置資訊，因為該語句是從記憶體中擷取，RESET SLAVE語句并沒有清理記憶體，而是清理了磁盤檔案、表（還包括mysql.slave_master_info和mysql.slave_relay_log_info兩個表）中記錄的資訊。如果需要清理記憶體裡報錯的複制資訊，需要使用RESET SLAVE ALL;語句
- 注意：對于replication_applier_status_by_worker、replication_applier_status_by_coordinator表（以及mysql.slave_wroker_info表）來說，如果是以單線程複制運作，則replication_applier_status_by_worker表記錄一條WORKER_ID=0的記錄，replication_applier_status_by_coordinator表與mysql.slave_wroker_info表為空(使用多線程複制，該表中才有記錄)。即，如果slave_parallel_workers系統變量大于0，則在執行START SLAVE時這些表就被填充相應多線程工作線程的資訊
performance_schema 系統庫中儲存的複制資訊與SHOW SLAVE STATUS輸出的資訊有所不同（performance_schema 中記錄的一些複制資訊是show slave status語句輸出資訊中沒有的，但是也仍然有一些show slave status語句輸出的複制資訊是performance_schema 中沒有的），因為這些表面向全局事務辨別符（GTID）使用，而不是基于binlog pos位置，是以這些表記錄server UUID值，而不是server ID值。show slave status語句輸出的資訊在performance_schema 中缺少的内容如下：
用于引用binlog file、pos和relay log file、pos等資訊選項，在performance_schema表中不記錄 。
PS1：如下系統狀态變量被移動到了這些複制狀态表中進行記錄(MySQL 5.7.5版之前使用以下狀态變量檢視）：
- Slave_retried_transactions
- Slave_last_heartbeat
- Slave_received_heartbeats
- Slave_heartbeat_period
- Slave_running
PS2：對于組複制架構，組複制的監控資訊散布在如下幾張表中
- threads
通過以上内容，我們從整體上能夠大緻了解了performance_schema中的複制資訊表記錄了什麼資訊，下面依次詳細介紹這些複制資訊表。
1.replication_applier_configuration表
該表中記錄從庫線程延遲複制的配置參數（延遲複制的線程被稱為普通線程，比如CHANNEL_NAME和DESIRED_DELAY字段記錄某個複制通道是否需要執行延遲複制，如果是MGR叢集，則記錄組複制從節點的延遲複制配置參數），該表中的記錄在Server運作時可以使用CHANGE MASTER TO語句進行更改，我們先來看看表中記錄的統計資訊是什麼樣子的。
# 如果是單主或多主複制，則該表中會為每個複制通道記錄一條類似如下資訊
admin@localhost : performance_schema 02:49:12> select * from replication_applier_configuration;
+--------------+---------------+
| CHANNEL_NAME | DESIRED_DELAY |
+--------------+---------------+
| | 0 |
+--------------+---------------+
1 row in set (0.00 sec)
# 如果是MGR叢集，則該表中會記錄類似如下MGR叢集資訊
root@localhost : performance_schema 10:56:49> select * from replication_applier_configuration;
+----------------------------+---------------+
| CHANNEL_NAME | DESIRED_DELAY |
+----------------------------+---------------+
| group_replication_applier | 0 |
| group_replication_recovery | 0 |
+----------------------------+---------------+
2 rows in set (0.00 sec)
表中各字段含義及與show slave status輸出字段對應關系如下：
對于replication_applier_configuration表，不允許執行TRUNCATE TABLE語句。
2. replication_applier_status表
該表中記錄的是從庫目前的一般事務執行狀态（該表也記錄組複制架構中的複制狀态資訊）
- 此表提供了所有線程binlog重放事務時的普通狀态資訊。線程重放事務時特定的狀态資訊儲存在replication_applier_status_by_coordinator表（單線程複制時該表為空）和replication_applier_status_by_worker表（單線程複制時表中記錄的資訊與多線程複制時的replication_applier_status_by_coordinator表中的記錄類似）
我們先來看看表中記錄的統計資訊是什麼樣子的。
# 單線程複制和多線程複制時表中的記錄相同，如果是多主複制，則每個複制通道記錄一行資訊
admin@localhost : performance_schema 02:49:28> select * from replication_applier_status;
+--------------+---------------+-----------------+----------------------------+
| CHANNEL_NAME | SERVICE_STATE | REMAINING_DELAY | COUNT_TRANSACTIONS_RETRIES |
+--------------+---------------+-----------------+----------------------------+
| | ON | NULL | 0 |
+--------------+---------------+-----------------+----------------------------+
1 row in set (0.00 sec)
# 如果是MGR叢集，則該表會記錄如下MGR叢集資訊
root@localhost : performance_schema 10:58:33> select * from replication_applier_status;
+----------------------------+---------------+-----------------+----------------------------+
| CHANNEL_NAME | SERVICE_STATE | REMAINING_DELAY | COUNT_TRANSACTIONS_RETRIES |
+----------------------------+---------------+-----------------+----------------------------+
| group_replication_applier | ON | NULL | 0 |
| group_replication_recovery | OFF | NULL | 0 |
+----------------------------+---------------+-----------------+----------------------------+
2 rows in set (0.00 sec)
對于replication_applier_status表，不允許執行TRUNCATE TABLE語句。
3. replication_applier_status_by_coordinator表
該表中記錄的是從庫使用多線程複制時，從庫的協調器工作狀态記錄，當從庫使用多線程複制時，每個通道下将建立一個協調器和多個工作線程，使用協調器線程來管理這些工作線程。如果從庫使用單線程，則此表為空（對應的記錄轉移到replication_applier_status_by_worker表中記錄），我們先來看看表中記錄的統計資訊是什麼樣子的。
# 單線程主從複制時，該表為空，為多線程主從複制時表中記錄協調者線程狀态資訊，多主複制時每個複制通過記錄一行資訊
admin@localhost : performance_schema 02:49:50> select * from replication_applier_status_by_coordinator;
+--------------+-----------+---------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | THREAD_ID | SERVICE_STATE | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+---------------+-------------------+--------------------+----------------------+
| | 43 | ON | 0 | | 0000-00-00 00:00:00 |
+--------------+-----------+---------------+-------------------+--------------------+----------------------+
1 row in set (0.00 sec)
# 如果是MGR叢集，則該表中會記錄類似如下MGR叢集資訊
root@localhost : performance_schema 11:00:11> select * from replication_applier_status_by_coordinator;
+---------------------------+-----------+---------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | THREAD_ID | SERVICE_STATE | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+---------------------------+-----------+---------------+-------------------+--------------------+----------------------+
| group_replication_applier | 91 | ON | 0 | | 0000-00-00 00:00:00 |
+---------------------------+-----------+---------------+-------------------+--------------------+----------------------+
1 row in set (0.00 sec)
對于replication_applier_status_by_coordinator表，不允許執行TRUNCATE TABLE語句。
4. replication_applier_status_by_worker表
如果從庫是單線程，則該表記錄一條WORKER_ID=0的SQL線程的狀态。如果從庫是多線程，則該表記錄系統參數slave_parallel_workers指定個數的工作線程狀态(WORKER_ID從1開始編号)，此時協調器/SQL線程狀态記錄在replication_applier_status_by_coordinator表，每一個通道都有自己獨立的工作線程和協調器線程（每個通道的工作線程個數由slave_parallel_workers參數變量指定，如果是MGR叢集時，則該表中記錄的工作線程記錄為slave_parallel_workers個group_replication_applier線程+1個group_replication_recovery線程），我們先來看看表中記錄的統計資訊是什麼樣子的。
# 單線程主從複制時表中記錄的内容如下
root@localhost : performance_schema 12:46:10> select * from replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
| | 0 | 82 | ON | | 0 | | 0000-00-00 00:00:00 |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
1 row in set (0.00 sec)
# 多線程主從複制時表中的記錄内容如下（如果是多主複制，則每個複制通道記錄slave_parallel_workers參數指定個數的worker線程資訊）
admin@localhost : performance_schema 02:50:18> select * from replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
| | 1 | 44 | ON | | 0 | | 0000-00-00 00:00:00 |
| | 2 | 45 | ON | | 0 | | 0000-00-00 00:00:00 |
| | 3 | 46 | ON | | 0 | | 0000-00-00 00:00:00 |
| | 4 | 47 | ON | | 0 | | 0000-00-00 00:00:00 |
+--------------+-----------+-----------+---------------+-----------------------+-------------------+--------------------+----------------------+
4 rows in set (0.00 sec)
# 如果是MGR叢集，則該表中會記錄類似如下MGR叢集資訊
root@localhost : performance_schema 11:00:16> select * from replication_applier_status_by_worker;
+----------------------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+----------------------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
| group_replication_recovery | 0 | NULL | OFF | | 0 | | 0000-00-00 00:00:00 |
| group_replication_applier | 1 | 92 | ON | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:104099082 | 0 | | 0000-00-00 00:00:00 |
| group_replication_applier | 2 | 93 | ON | | 0 | | 0000-00-00 00:00:00 |
......
+----------------------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
17 rows in set (0.00 sec)
對于replication_applier_status_by_worker表，不允許執行TRUNCATE TABLE語句。
5. replication_connection_configuration表
該表中記錄從庫用于連接配接到主庫的配置參數，該表中存儲的配置資訊在執行change master語句時會被修改
- 與replication_connection_status表相比，replication_connection_configuration更改頻率更低。因為它隻包含從庫連接配接到主庫的配置參數，在連接配接正常工作期間這些配置資訊保持不變的值，而replication_connection_status中包含的連接配接狀态資訊，隻要IO線程狀态發生變化，該表中的資訊就會發生修改（多主複制架構中，從庫指向了多少個主庫就會記錄多少行記錄。MGR叢集架構中，每個節點有兩條記錄，但這兩條記錄并未記錄完整的組複制連接配接配置參數，例如：host等資訊記錄到了replication_group_members表中）。
# 單線程、多線程主從複制時表中記錄的内容相同，如果是多主複制，則每個複制通道各自有一行記錄資訊
admin@localhost : performance_schema 02:51:00> select * from replication_connection_configuration\G;
*************************** 1. row ***************************
CHANNEL_NAME:
HOST: 10.10.20.14
PORT: 3306
USER: qfsys
NETWORK_INTERFACE:
AUTO_POSITION: 1
SSL_ALLOWED: NO
SSL_CA_FILE:
SSL_CA_PATH:
SSL_CERTIFICATE:
SSL_CIPHER:
SSL_KEY:
SSL_VERIFY_SERVER_CERTIFICATE: NO
SSL_CRL_FILE:
SSL_CRL_PATH:
CONNECTION_RETRY_INTERVAL: 60
CONNECTION_RETRY_COUNT: 86400
HEARTBEAT_INTERVAL: 5.000
TLS_VERSION:
1 row in set (0.00 sec)
# 如果是MGR叢集，則該表中會記錄類似如下MGR叢集資訊
root@localhost : performance_schema 11:02:03> select * from replication_connection_configuration\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
HOST: <NULL>
......
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_recovery
HOST: <NULL>
......
2 rows in set (0.00 sec)
表中各字段含義以及與change master to語句的選項對應關系如下：
注意：對于replication_connection_configuration表，不允許執行TRUNCATE TABLE語句。
6. replication_connection_status表
該表中記錄的是從庫IO線程的連接配接狀态資訊（也記錄組複制架構中其他節點的連接配接資訊，組複制架構中一個節點加入叢集之前的資料需要使用異步複制通道進行資料同步，組複制的異步複制通道資訊在show slave status中不可見），我們先來看看表中記錄的統計資訊是什麼樣子的。
# 多線程和單線程主從複制時表中記錄相同，如果是多主複制，則每個複制通道在表中個記錄一行資訊
root@localhost : performance_schema 12:55:26> select * from replication_connection_status\G
*************************** 1. row ***************************
CHANNEL_NAME:
GROUP_NAME:
SOURCE_UUID: ec123678-5e26-11e7-9d38-000c295e08a0
THREAD_ID: 101
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 136
LAST_HEARTBEAT_TIMESTAMP: 2018-06-12 00:55:22
RECEIVED_TRANSACTION_SET:
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
1 row in set (0.00 sec)
# 如果是MGR叢集，則該表中會記錄類似如下MGR叢集資訊
root@localhost : performance_schema 10:56:40> select * from replication_connection_status\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
GROUP_NAME: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
SOURCE_UUID: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
THREAD_ID: NULL
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 0
LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00
RECEIVED_TRANSACTION_SET: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:104099082
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_recovery
......
2 rows in set (0.00 sec)
對于replication_connection_status表，不允許執行TRUNCATE TABLE語句。
7. replication_group_member_stats表
該表中記錄了MySQL組複制成員的統計資訊。僅在組複制元件運作時表中才會有記錄，我們先來看看表中記錄的統計資訊是什麼樣子的。
root@localhost : performance_schema 11:02:10> select * from replication_group_member_stats\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15287289928409067:1
MEMBER_ID: 5d78a458-30d2-11e8-a66f-5254002a54f2
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 0
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 0a1e8349-2e87-11e8-8c9f-525400bdd1f2:1-148826,
2d623f55-2111-11e8-9cc3-0025905b06da:1-2,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-104099082
LAST_CONFLICT_FREE_TRANSACTION:
1 row in set (0.00 sec)
表中各字段含義如下：
- CHANNEL_NAME：組成員所在組所使用的複制通道名稱，通道名稱為：group_replication_applier
- VIEW_ID：組成員所在組的目前視圖示識符
- MEMBER_ID：顯示目前組成員server的UUID，組成員執行個體的UUID相同。組中的每個節點具有不同的值（因為是使用的組成員執行個體的UUID，該UUID随機生成，保證全局唯一）且唯一
- COUNT_TRANSACTIONS_IN_QUEUE：表示目前隊列中等待沖突檢查的事務數（等待全局事務認證的事務數），一旦沖突檢測通過，他們将排隊等待應用
- COUNT_TRANSACTIONS_CHECKED：表示已認證沖突檢查機制檢查的事務數（已認證全局事務認證的事務數，從節點加入組複制時開始計算）
- COUNT_CONFLICTS_DETECTED：表示未通過沖突檢測機制檢查的事務數（在全局事務認證時未通過的事務數）
- COUNT_TRANSACTIONS_ROWS_VALIDATING：表示沖突檢測資料庫的目前大小（用于存放每個經過驗證的事務的資料庫），可用于認證新事務，但尚未被垃圾回收的可用行數
- TRANSACTIONS_COMMITTED_ALL_MEMBERS：顯示已在目前視圖中的所有成員上成功送出的事務(類似所有成員執行個體的gtid_executed集合的交集)，該值固定時間間隔更新（是以并不實時）
- LAST_CONFLICT_FREE_TRANSACTION：顯示最後一次無沖突校驗檢查的事務辨別符(最後一個沒有沖突的事務的GTID)
對于replication_group_member_stats表，不允許執行TRUNCATE TABLE語句。
8. replication_group_members表
該表記錄組複制架構中，組成員的網絡和狀态資訊。僅在組複制元件運作時表中才會有記錄，我們先來看看表中記錄的統計資訊是什麼樣子的。
root@localhost : performance_schema 11:03:38> select * from replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 5d78a458-30d2-11e8-a66f-5254002a54f2 | node1 | 3306 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
1 row in set (0.00 sec)
- CHANNEL_NAME：組複制架構中使用的通道名稱，通道名稱為：group_replication_applier
- MEMBER_ID：組複制架構中，組成員的ID，與組成員執行個體的server UUID相同
- MEMBER_HOST：組複制架構中，組成員的網絡位址（主機名或IP位址，與成員執行個體的hostname或report_host系統變量的值相同）
- MEMBER_PORT：組複制架構中，組成員的偵聽端口，與組成員執行個體的port或report_port系統變量的值相同
-
MEMBER_STATE：組複制架構中，組成員的狀态 有效狀态如下：
* OFFLINE：組複制成員已經安裝組複制插件，但未啟動
* RECOVERING：組複制成員已經加入到組複制架構中，正在從組中接收資料，即正在加入叢集
* ONLINE：組複制成員處于正常運作狀态
* PS：組複制架構中，如果組成員的組複制狀态發生錯誤，無法正常從組中接收資料是，可能會變成ERROR狀态。如果發生網絡故障或者其他成員當機，那麼剩餘存活的孤立節點的狀态可能會變為UNREACHABLE
對于replication_group_members表，不允許執行TRUNCATE TABLE語句。
02
使用者自定義變量記錄表
performance_schema提供了一個儲存使用者定義變量的user_variables_by_thread表（該表也儲存由mysql内部連接配接線程建立的變量）。這些變量是在特定會話中定義的變量，變量名由@字元開頭。
admin@localhost : performance_schema 01:50:16> select * from user_variables_by_thread;
+-----------+-------------------------+--------------------------------------+
| THREAD_ID | VARIABLE_NAME | VARIABLE_VALUE |
+-----------+-------------------------+--------------------------------------+
| 45 | slave_uuid | 4b0027eb-6223-11e7-94ad-525400950aac |
| 45 | master_heartbeat_period | 5000000000 |
| 45 | master_binlog_checksum | CRC32 |
+-----------+-------------------------+--------------------------------------+
3 rows in set (0.01 sec)
- THREAD_ID：定義變量的會話的線程辨別符（ID）
- VARIABLE_NAME：定義的變量名稱，在該表中去掉了@字元的形式顯式
- VARIABLE_VALUE：定義的變量值
user_variables_by_thread表不允許使用TRUNCATE TABLE語句
03
system variables記錄表
MySQL server維護着許多系統變量，在performance_schema中提供了對全局、目前會話、以及按照線程分組的系統變量資訊記錄表：
- global_variables：全局系統變量。隻需要全局系統變量值的應用程式可以從該表中擷取
- session_variables：目前會話的系統變量。隻需要擷取自己目前會話的系統變量值可以從該表中擷取（注意，該表中包含了無會話級别的全局變量值，且該表不記錄已斷開連接配接的系統變量）
- variables_by_thread：按照線程ID為辨別符記錄的會話系統變量。想要在目前線程中查詢其他指定線程ID的會話級别系統變量時，應用程式可以從該表中擷取（注意，該表中僅包含有會話級别的系統變量）
# global_variables表
admin@localhost : performance_schema 09:50:31> select * from global_variables limit 5;
+--------------------------+----------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+--------------------------+----------------+
| auto_increment_increment | 2 |
| auto_increment_offset | 2 |
......
5 rows in set (0.01 sec)
# session_variables表（查詢結果與global_variables 表類似）
admin@localhost : performance_schema 09:50:40> select * from session_variables limit 5;
.............
# variables_by_thread表
admin@localhost : performance_schema 09:50:52> select * from variables_by_thread limit 5; # 可以看到比前面兩張表多了個THREAD_ID 字段來記錄線程ID
+-----------+-----------------------------------------+----------------+
| THREAD_ID | VARIABLE_NAME | VARIABLE_VALUE |
+-----------+-----------------------------------------+----------------+
| 45 | auto_increment_increment | 2 |
| 45 | auto_increment_offset | 2 |
......
5 rows in set (0.00 sec)
global_variables和session_variables表字段含義如下：
- VARIABLE_NAME：系統變量名
- VARIABLE_VALUE：系統變量值。對于global_variables，此列包含全局值。對于session_variables，此列包含目前會話生效的變量值
variables_by_thread表字段含義如下：
- THREAD_ID：會話級别系統變量對應的線程ID
- VARIABLE_NAME：會話級别系統變量名
- VARIABLE_VALUE：會話級别系統變量值
performance_schema記錄系統變量的這些表不支援TRUNCATE TABLE語句
PS：
- show_compatibility_56系統變量的值會影響這些表中的資訊記錄
- 會話變量表（session_variables，variables_by_thread）僅包含活躍會話的資訊，已經終止的會話不會記錄
- variables_by_thread表僅包含關于前台線程的會話級别系統變量資訊。且隻記錄擁有會話級别的系統變量，另外，如果在該表中有不能夠被記錄的會話級别系統變量，那麼将增加狀态變量Performance_schema_thread_instances_lost的值
04
status variables統計表
MySQL server維護着許多狀态變量，提供有關其内部相關操作的資訊。如下一些performance_schema表中記錄着狀态變量資訊：
- global_status：全局狀态變量。如果隻需要全局狀态變量值的應用程式可以查詢此表，中斷的會話狀态變量值會被聚合在此表中
- session_status：目前會話的狀态變量。如果隻希望查詢自己會話的所有狀态變量值的應用程式可以查詢此表（注意：該表包含沒有會話級别的全局狀态變量），隻記錄活躍會話，不記錄已中斷的會話
- status_by_thread：按照線程ID作為辨別符記錄每個活躍會話的狀态變量。如果需要在某個會話中查詢其他會話的狀态變量值可以查詢此表（注意：該表不包含隻具有全局級别的狀态變量），隻記錄活躍會話，不記錄中斷的會話
# global_status表
admin@localhost : performance_schema 11:01:51> select * from global_status limit 5;
+----------------------------+----------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+----------------------------+----------------+
| Aborted_clients | 0 |
| Aborted_connects | 0 |
......
5 rows in set (0.00 sec)
# session_status表（記錄内容與global_status 表類似）
admin@localhost : performance_schema 11:02:21> select * from session_status limit 5;
............
# status_by_thread 表
admin@localhost : performance_schema 11:02:49> select * from status_by_thread limit 5;
+-----------+-------------------------+----------------+
| THREAD_ID | VARIABLE_NAME | VARIABLE_VALUE |
+-----------+-------------------------+----------------+
| 45 | Bytes_received | 0 |
| 45 | Bytes_sent | 2901 |
......
5 rows in set (0.00 sec)
global_status和session_status表字段含義如下：
-
- VARIABLE_NAME：狀态變量名稱
- VARIABLE_VALUE：狀态變量值。對于global_status，此列包含全局狀态變量值。對于session_status，此列包含目前會話的狀态變量值（同時包含無會話級别的全局狀态變量值，且隻包含活躍會話的狀态變量值）。
status_by_thread表包含每個活躍線程的狀态。字段含義如下：
- THREAD_ID：與該狀态變量相關聯的線程ID
- VARIABLE_NAME：有會話級别的狀态變量名稱
- VARIABLE_VALUE：與線程ID相關的會話級别狀态變量值
performance_schema允許對這些狀态變量資訊統計表執行TRUNCATE TABLE語句：
- global_status：執行truncate會重置線程、帳戶、主機、使用者相關的全局狀态變量值，但不會重置一些從不重置的全局狀态變量值，同時會影響到status_by_account表中的狀态變量值
- session_status：不支援執行truncate語句
- status_by_thread：将所有線程的狀态變量值聚合到全局狀态變量表(global_status)和帳戶狀态變量表(status_by_account)，然後重置線程狀态變量表。如果不收集帳戶相關的統計資訊，則會在status_by_user和status_by_host中單獨收集主機和使用者的狀态變量值，是否收集host，user，account的狀态變量值，可以使用系統變量performance_schema_accounts_size，performance_schema_hosts_size和performance_schema_users_size在server啟動之前分别進行設定，設定為0，則表示不收集，大于0則表示要收集（注意，這些系統變量原本是用于控制accounts、hosts、users表中的行數，但是status_by_account，status_by_user，status_by_host中的account，user，host值是來自于accounts、hosts、users表，so…你懂的）
FLUSH STATUS語句會把所有活躍會話的狀态變量值聚合到全局狀态變量值中，然後重置所有活躍會話的狀态變量值，并在account，host和user狀态變量對應的統計表中重置已斷開連接配接的狀态變量聚合值。
- status_by_thread表僅包含前台線程的狀态變量資訊。該表記錄數量自動計算，不建議手工指定系統變量perform_schema_max_thread_instances的值，如果手工指定，務必要大于背景線程數量*2，否則可能造成因為該變量的限制沒有足夠的intruments thread instances容量導緻無法建立，進而無法監控前台線程的狀态變量統計資訊，如果無法監控前台線程的狀态變量統計資訊時，該表為空
- performance_schema執行狀态變量收集時，對于全局級别的狀态變量，如果threads表中INSTRUMENTED列值為“yes”則執行收集，否則不收集。但對于會話級别的狀态變量，無論threads表的INSTRUMENTED字段值是否為yes，始終執行收集
- performance_schema不會在狀态變量表中收集Com_xxx狀态變量的統計資訊。要擷取全局和每個會話語句的相關執行計數，請分别使用events_statements_summary_global_by_event_name和events_statements_summary_by_thread_by_event_name表進行查詢。例如：SELECT EVENT_NAME, COUNT_STAR FROM events_statements_summary_global_by_event_name WHERE EVENT_NAME LIKE 'statement/sql/%';
- 對于按帳戶，主機名和使用者名聚合的狀态變量資訊。詳見下文。
05
按照帳号、主機、使用者統計的狀态變量統計表
按照帳号、主機名、使用者名為分組對狀态變量進行分類資料，例如：按照帳号表統計的表分組列為host和user列，聚合列當然就是狀态變量本身（該功能是MySQL 5.7版本新增的），有如下幾張表：
- status_by_account：按照每個帳戶進行聚合的狀态變量
- status_by_host：按照每個主機名進行聚合的狀态變量
- status_by_user：按照每個使用者名進行聚合的狀态變量
# status_by_account表
admin@localhost : performance_schema 04:08:36> select * from status_by_account where USER is not null limit 5;
+-------+-----------+-------------------------+----------------+
| USER | HOST | VARIABLE_NAME | VARIABLE_VALUE |
+-------+-----------+-------------------------+----------------+
| admin | localhost | Bytes_received | 6049 |
| admin | localhost | Bytes_sent | 305705 |
.......
5 rows in set (0.00 sec)
# status_by_host表
admin@localhost : performance_schema 04:08:43> select * from status_by_host where HOST is not null limit 5;
+-----------+-------------------------+----------------+
| HOST | VARIABLE_NAME | VARIABLE_VALUE |
+-----------+-------------------------+----------------+
| localhost | Bytes_received | 6113 |
| localhost | Bytes_sent | 306310 |
......
5 rows in set (0.00 sec)
# status_by_user表
admin@localhost : performance_schema 04:08:58> select * from status_by_user where USER is not null limit 5;
+-------+-------------------------+----------------+
| USER | VARIABLE_NAME | VARIABLE_VALUE |
+-------+-------------------------+----------------+
| admin | Bytes_received | 6177 |
| admin | Bytes_sent | 306781 |
......
5 rows in set (0.00 sec)
表中各字段含義
- 與VARIABLE_VALUE：狀态變量值，要注意：該段值包括活躍和已終止的會話的狀态變量統計值
- USER：使用者名
- HOST：主機名或IP
狀态變量摘要表允許執行TRUNCATE TABLE語句，執行truncate語句時活動會話的狀态變量不受影響：
- status_by_account：終止的會話在account聚合表中的狀态變量值将被聚合到使用者和主機聚合表中的狀态變量計數器中，然後重置帳戶聚合表中的狀态變量值
- status_by_host：終止的會話對應的狀态變量被重置
- status_by_user：終止的會話對應的狀态變量被重置
FLUSH STATUS将會話狀态從所有活動會話添加到全局狀态變量，然後重置所有活動會話的狀态變量值，并在按照account、host、user分類聚合表中重置已斷開連接配接的狀态變量值。
- 當會話終止時收集的account相關狀态變量會添加到全局狀态變量表的計數器和accounts表的相關計數器中。如果account分類關閉了收集而host和user分類開啟了收集，則會針對主機和使用者分類聚合相應的狀态變量值，同時将會話狀态添加到hosts和users表中的相關計數器中
- 如果将performance_schema_accounts_size，performance_schema_hosts_size和performance_schema_users_size系統變量分别設定為0，則不會收集帳戶，主機和使用者分類的統計資訊
- show_compatibility_56系統變量的值會影響這些表中的統計資訊
06
host_cache表
host_cache表儲存連接配接到server的主機相關資訊緩存，其中包含客戶機主機名和IP位址資訊，可以用于避免DNS查找。該表可以使用SELECT語句進行查詢，但需要在server啟動之前開啟performance_schema參數，否則表記錄為空。
root@localhost : performance_schema 10:35:47> select * from host_cache\G;
*************************** 1. row ***************************
IP: 192.168.2.122
HOST: NULL
HOST_VALIDATED: YES
SUM_CONNECT_ERRORS: 0
COUNT_HOST_BLOCKED_ERRORS: 0
COUNT_NAMEINFO_TRANSIENT_ERRORS: 0
COUNT_NAMEINFO_PERMANENT_ERRORS: 1
COUNT_FORMAT_ERRORS: 0
COUNT_ADDRINFO_TRANSIENT_ERRORS: 0
COUNT_ADDRINFO_PERMANENT_ERRORS: 0
COUNT_FCRDNS_ERRORS: 0
COUNT_HOST_ACL_ERRORS: 0
COUNT_NO_AUTH_PLUGIN_ERRORS: 0
COUNT_AUTH_PLUGIN_ERRORS: 0
COUNT_HANDSHAKE_ERRORS: 0
COUNT_PROXY_USER_ERRORS: 0
COUNT_PROXY_USER_ACL_ERRORS: 0
COUNT_AUTHENTICATION_ERRORS: 0
COUNT_SSL_ERRORS: 0
COUNT_MAX_USER_CONNECTIONS_ERRORS: 0
COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS: 0
COUNT_DEFAULT_DATABASE_ERRORS: 0
COUNT_INIT_CONNECT_ERRORS: 0
COUNT_LOCAL_ERRORS: 0
COUNT_UNKNOWN_ERRORS: 0
FIRST_SEEN: 2017-12-30 22:34:51
LAST_SEEN: 2017-12-30 22:35:29
FIRST_ERROR_SEEN: 2017-12-30 22:34:51
LAST_ERROR_SEEN: 2017-12-30 22:34:51
1 row in set (0.00 sec)
- IP：連接配接到server的用戶端的IP位址，以字元串形式記錄
- HOST：該用戶端IP解析的DNS主機名，如果沒有計息記錄，則該字段為NULL
- HOST_VALIDATED：某個IP的用戶端的'IP-主機名稱-IP'的解析是否成功。如果HOST_VALIDATED為YES，則HOST列被當作與之相關的IP使用，以避免使用DNS解析。當HOST_VALIDATED為NO時，對于每個連會反複地嘗試DNS解析，直到最終傳回有效的解析結果或者傳回一個錯誤。可以利用該資訊來在server所使用的DNS伺服器故障期間避免執行DNS解析
- SUM_CONNECT_ERRORS：該字段記錄的連接配接錯誤數量被認為是“正在阻塞中”的連接配接數（此時你可能需要關注下max_connect_errors系統變量值，一旦該列值超過該變量的值，則後續的連接配接将直接被拒絕）。隻對協定握手錯誤進行計數，并且僅對通過驗證的主機（HOST_VALIDATED = YES）進行計數
- COUNT_HOST_BLOCKED_ERRORS：由于SUM_CONNECT_ERRORS超出了max_connect_errors系統變量的值而被阻塞的連接配接數
- COUNT_NAMEINFO_TRANSIENT_ERRORS：從IP到主機名稱的DNS解析期間的短暫錯誤的數量，例如第一次解析失敗，第二次解析成功
- COUNT_NAMEINFO_PERMANENT_ERRORS：從IP到主機名稱DNS解析期間的永久性錯誤的數量，解析DNS直到不再嘗試重新解析的錯誤
- COUNT_FORMAT_ERRORS：主機名格式錯誤的數量。 對于主機名（DNS中的主機名），MySQL不會在mysql.user表中重試執行與主機列比對操作，例如：1.2.example.com（主機名部分是數字是錯誤的格式）。但是如果直接使用IP位址時則字首是數字的不會被識别為錯誤格式，會使用IP格式比對而不是DNS格式
- COUNT_ADDRINFO_TRANSIENT_ERRORS：從主機名稱到IP反向DNS解析過程中的短暫錯誤數量
- COUNT_ADDRINFO_PERMANENT_ERRORS：從主機名稱到IP反向DNS解析期間的永久性錯誤的數量
- COUNT_FCRDNS_ERRORS：DNS反向解析發生錯誤的數量。當IP-主機名稱-IP的解析發生了解析的結果IP與發起請求的用戶端原始IP不比對時，就産後了這個錯誤
- COUNT_HOST_ACL_ERRORS：某個主機沒有有權限的使用者可登入server時，從這個主機嘗試登入server會發生這個錯誤。在這種情況下，server傳回ER_HOST_NOT_PRIVILEGED錯誤
- COUNT_NO_AUTH_PLUGIN_ERRORS：由于請求的身份驗證插件不可用而導緻的錯誤數量。例如：某個身份驗證插件并未加載，那麼這個插件被請求時就會發生這個錯誤
- COUNT_AUTH_PLUGIN_ERRORS：身份認證插件報告的錯誤數。驗證插件可以報告不同的錯誤代碼，以指出故障的根本原因。根據錯誤類型，相應地增加對應錯誤類型的錯誤計數列值(COUNT_AUTHENTICATION_ERRORS、COUNT_AUTH_PLUGIN_ERRORS、COUNT_HANDSHAKE_ERRORS），未知的插件錯誤在COUNT_AUTH_PLUGIN_ERRORS列中計數
- COUNT_HANDSHAKE_ERRORS：在握手協定級别檢測到的錯誤數
- COUNT_PROXY_USER_ERRORS：代理使用者A在代理不存在的另一使用者B時檢測到的錯誤數
- COUNT_PROXY_USER_ACL_ERRORS：當代理使用者A被代理給另一個存在但是對于A沒有PROXY權限的使用者B時，檢測到的錯誤數量
- COUNT_AUTHENTICATION_ERRORS：認證失敗造成的錯誤次數
- COUNT_SSL_ERRORS：由于SSL問題導緻的錯誤數量
- COUNT_MAX_USER_CONNECTIONS_ERRORS：超出每個使用者連接配接配額造成的錯誤數
- COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS：超出每使用者連接配接每小時配額造成的錯誤數量
- COUNT_DEFAULT_DATABASE_ERRORS：與預設資料庫相關的錯誤數。例如：資料庫不存在或使用者沒有權限通路
- COUNT_INIT_CONNECT_ERRORS：由init_connect系統變量加載的檔案中的語句執行失敗引起的錯誤數
- COUNT_LOCAL_ERRORS：server本地執行相關操作時的錯誤數量，與網絡、身份驗證、授權無關的錯誤。例如，記憶體不足的情況屬于這一類别
- COUNT_UNKNOWN_ERRORS：其他未知錯誤的數量，該列保留供将來使用
- FIRST_SEEN：對于某個IP用戶端，第一次嘗試連接配接發生的時間
- LAST_SEEN：對于某個IP用戶端，最後一次嘗試連接配接發生的時間
- FIRST_ERROR_SEEN：對于某個IP用戶端，第一次嘗試連接配接發生錯誤的時間
- LAST_ERROR_SEEN：對于某個IP用戶端，最後一次嘗試連接配接發生錯誤的時間
FLUSH HOSTS和TRUNCATE TABLE host_cache具有相同的效果：它們清除主機緩存。host_cache表被清空并解除阻塞任何因為錯誤記錄數量超過限制而被阻塞的主機連接配接。FLUSH HOSTS需要RELOAD權限。 TRUNCATE TABLE需要host_cache表的DROP權限。
PS：如果啟動選項 skip_name_resolve 設定為ON，則該表不記錄任何資訊，因為該表的作用就是用于避免、加速域名解析用于，跳過域名解析功能時則該表記錄的資訊用途不大。
- END -