mysql 5.7中嶄新的 mysql sys schema
mysql 5.7中嶄新的 mysql sys schema 聲明：本文內容來自于《MySQL運維內參》，筆者讀后整理的筆記，僅供學習使用。
以下內容都是MySQL 5.7的新功能
一、 Performance Schema的改進
1、元數據庫鎖
select * from performance_schema.metadata_locks;
通過該表可以看到：
a)、哪些會話擁有元數據鎖；
b）、哪些會話正在等待元數據鎖；
c）、哪些請求由于死鎖被殺掉，或者鎖等待超時而被丟棄。
2、進程跟蹤
select * from performance_schema.events_stages_current;
通過該表可以跟蹤長時間操作的進度（比如ALTER TABLE）:
備注：stages是階段的意思。
3、查看未提交事務
從mysql 5.7開始，新增events_transactions_current表，通過該表查看當前線上的事務的狀態，如果線上數據庫遇到undo log大量增長，數據庫性能急劇下降，可以通過該表查看當前是否存在處于未提交狀態的事務。如果發現的確有大量的事務的state處于active狀態，這時可以確定數據庫的事務未提交。
二、SYS庫的介紹
performation schema使用起來不方便，mysql 5.7用sys庫來解決這個問題。
mysql sys庫本身不采集和存儲什么信息，而是將performance schema和infomation schema的數據以更加容易理解的方式總結歸檔出的視圖。
在sys庫中，沒有x$前綴的視圖提供了更加友好且易讀的數據；x$前綴的視圖提供了原始數據，需要加工才好看。
1）、主機相關信息：以host_summary開頭的視圖，從主機、文件時間類型、語句類型角度展示文件IO延遲的信息；
2）、innodb buffer pool和鎖的相關信息：以innodb開頭的視圖，匯總了innodb buffer page信息和事務等待鎖的信息；
3）、io使用情況：以io開頭的視圖，總結了io使用者的信息，包括等待io的情況、io使用量情況；
4)、 內存使用情況：以memory開頭的視圖，從主機、線程、用戶、事件的角度展示了內存使用情況；
5）、連接與會話信息：processlist和session總結了連接與會話信息；
6）、表相關信息：以schema_table開頭的視圖，從全表掃描、innodb緩沖池等方面展示了表統計信息；
7）、索引信息：其中包含index的視圖，統計了索引使用情況，以及重復索引和未使用索引情況；
8）、語句相關信息：以statement開頭的視圖，統計的規范化后的語句使用情況，包括錯誤數、警告數、執行全表掃描的、使用臨時表、執行排序等信息；
9）、用戶的相關信息：以user開頭的視圖，統計了用戶使用文件IO、執行的語句統計信息等；
10）、等待事件相關信息：以wait開頭的視圖，從主機和事件角度展示等待事件的延遲情況；
11）、鎖信息：innodb_lock_waits和schema_table_lock_waits展示了鎖信息
三、重點視圖與應用場景
1、查看表訪問量
場景：查看每張表的讀寫次數
+--------------+----------------------+---------------+
| table_schema | table_name | io_to_request |
+--------------+----------------------+---------------+
| oa_2016 | form_trigger_record | | oa_2016 | form_log | | oa_2016 | ctp_content_all | | oa_2016 | org_relationship |
2、冗余索引和未使用的索引
通過sys庫中的schema_index_statistics 和schema_redundant_indexes兩個視圖，可以看到哪些索引沒有被使用過或者使用率低。
3、表自增id監控
場景：知道哪張表有自增主鍵，并且監控自增主鍵是否快要超過閾值
(root@localhost)[sys]> *************************** table_schema: oa_2016
table_name: ctp_content_all
data_type: column_type: is_signed: is_unsigned: max_value: auto_increment: auto_increment_ratio:
4、查看實例消耗的磁盤IO
(root@localhost)[sys]> +------------------------------------------------+--------+
+------------------------------------------------+--------+
| @@datadir/oa_2016/portal_link_space| @@datadir/oa_2016/pro_eipusercustomsort| @@datadir/oa_2016/ctp_dr_url_map| @@datadir/oa_2016/office_auto_applyinfo| @@datadir/oa_2016/edoc_exchange_turn_rec| @@datadir/oa_2016/portal_portlet_property| @@datadir/oa_2016/showpost_info| @@datadir/oa_2016/cip_agent| @@datadir/oa_2016/thirdparty_portal_config| @@datadir/oa_2016/portal_link_option+------------------------------------------------+--------+
DBA可以通過該查詢大致的了解磁盤IO消耗在哪里，哪些文件消耗的最多。DBA可以根據這些信息，針對某表，某庫進行優化。
5、監控全表掃描的sql語句
通過sys.statements_with_full_table_scans來看全表掃描的sql語句：
root@localhost)[sys]> *************************** query: db: oa_2016
exec_count: total_latency: no_index_used_count: no_good_index_used_count: no_index_used_pct: rows_sent: rows_examined: rows_sent_avg: rows_examined_avg: first_seen: last_seen: digest:
通過上面可以看到，該sql語句總共執行了5次，有5次都沒有使用索引，總共消耗了997.89 us。
6、操作風險
sys庫的視圖來源于performace_schema和information_schema，我們知道performace_schema開啟后，數據庫會有10%性能下降：
(root@localhost)[sys]> show variables +----------------------------------------------------------+-------+
| Variable_name | Value |
+----------------------------------------------------------+-------+
| performance_schema | ON |
所以，我們查詢sys或者performance_schema時，要謹慎操作。
7參考
參考《mysql運維內參》一書
