mysql5.7中的sys表詳解(轉)

在說明系統數據庫以前,先來看下MySQL在數據字典方面的演變歷史:
MySQL4.1 提供了information_schema 數據字典。今後能夠很簡單的用SQL語句來檢索須要的系統元數據了。
MySQL5.5 提供了performance_schema 性能字典。 可是這個字典比較專業,通常人可能也就看看就不了了之了。
MySQL5.7 提供了 sys系統數據庫。 sys數據庫裏面包含了一系列的存儲過程、自定義函數以及視圖來幫助咱們快速的瞭解系統的元數據信息。
sys系統數據庫結合了information_schema和performance_schema的相關數據,讓咱們更加容易的檢索元數據。 如今呢,我就示範下幾種場景下如何快速的使用。mysql

mysql5.7增長了sys 系統數據庫,經過這個庫能夠快速的瞭解系統的元數據信息ios

這個庫確實能夠方便DBA發現數據庫的不少信息,解決性能瓶頸都提供了巨大幫助git

 

這個庫在mysql5.7中是默認存在的,在mysql5.6版本以上能夠手動導入,數據庫包請在github自行查找。github

sys系統數據庫結合了information_schema和performance_schema的相關數據,讓咱們更加容易的檢索元數據。 如今呢,我就示範下幾種場景下如何快速的使用。sql

第一,
好比以前想要知道某個表是否存在與否,能夠用如下兩種方法:

A, 悲觀的方法,寫SQL從information_schema中拿信息:數據庫

 SELECT IF(COUNT(*) = 0,'Not exists!','Exists!') AS 'result' FROM information_schema.tables WHERE table_schema = 'new_feature' AND table_name = 't1'; 緩存

result 
-------------
Not exists!函數

 B、樂觀的方法,假設表存在,寫一個存儲過程: (太麻煩了)工具

如今只須要使用:性能

SELECT IF(@v_is_exists = '','Not exists!',@v_is_exists) AS 'result'; 

result 
-------------
Not exists!

第2、獲取沒有使用的索引  SELECT * FROM schema_unused_indexes; 

第三, 檢索指定數據庫下面的表掃描信息,過濾出執行次數大於10的查詢,

SELECT * FROM statement_analysis WHERE db='new_feature' AND full_scan = '*'  AND exec_count > 10

SELECT * FROM statement_analysis WHERE db='new_feature' AND tmp_tables > 0 ORDER BY tmp_tables DESC LIMIT 

第五, 檢索執行次數排名前五的語句 

SELECT statement,total FROM user_summary_by_statement_type WHERE `user`='root' ORDER BY total DESC LIMIT 5;  

這個庫包括了哪些內容?

這個庫是經過視圖的形式把information_schema 和performance_schema結合起來,查詢出更加使人容易理解的數據

存儲過程能夠能夠執行一些性能方面的配置,也能夠獲得一些性能診斷報告內容

存儲函數能夠查詢一些性能信息

 

分析每一個視圖和表以前先說明一下:關於帶不帶x$,去掉x$同名的視圖他們的數據是相同的,區別在於不帶x$的單位更加符合直接閱讀通過了轉換,而帶x$是爲了某些工具存在而使用的原始單位(多數應該是mysql默認的)

 

下面就結合mysql官方手冊來詳細分析sys庫


1.表 

    1.1 sys_config 表

        這是在這個系統庫上存在的惟一一個表了

        先看看錶結構

CREATE TABLE `sys_config` (

  `variable` varchar(128) NOT NULL,

  `value` varchar(128) DEFAULT NULL,

  `set_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

  `set_by` varchar(128) DEFAULT NULL,

  PRIMARY KEY (`variable`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8

        variable 配置選項名稱

        value     配置選項值

        set_time 該行配置修改的時間

        set_by     該行配置信息修改者,若是從被安裝沒有修改過,那麼這個數據應該爲NULL

 

    表中默認數據爲

 

 

    以上值的會話變量爲@sys.+表中variable字段,譬如:@sys.statement_truncate_len 

能夠set @sys.statement_truncate_len = 32 臨時改變值,在會話中會一直使用這個值,若是想要恢復使用表的默認值,只須要將這個會話值設置爲null;set @sys.statement_truncate_len = null;

 

diagnostics.allow_i_s_tables  

diagnostics.include_raw 

這兩個值默認爲OFF ,前者若是開啓表示容許diagnostics() 存儲過程執行掃描information_schema.tables 表,若是表不少,那麼可能會很耗性能,後者開啓將會從metrics 視圖輸出未加工處理的數據 。diagnostics() 具體內容見下面對diagnostics()的解釋。

 

statement_performance_analyzer.limit 

視圖在沒有加limit限制時,返回的最大行數

statement_performance_analyzer.view 

(略)

以上參數爲mysql5.7.9加入

 

 statement_truncate_len  

經過format_statement()函數返回值的最大長度

 

這個表非默認選項還有一個@sys.debug參數

能夠手動加入

INSERT INTO sys_config (variable, value) VALUES('debug', 'ON');

UPDATE sys_config SET value = 'OFF' WHERE variable = 'debug';

SET @sys.debug = NULL;

具體內容請參考官方文檔,此處不作介紹

 

關於這個表有兩個觸發器

1.1.1 sys_config_insert_set_user觸發器

若是加入新行經過insert語句,那麼這個觸發器會把set_by列設置爲當前操做者

1.1.2 sys_config_update_set_user觸發器           

 

若是加入新行經過update語句,那麼這個觸發器會把set_by列設置爲當前操做者

 

2.視圖

如下部分只介紹不包含x$的視圖內容

 

2.1 host_summary (主機概要)

有以下列:

• host

監聽鏈接過的主機

• statements

當前主機執行的語句總數

• statement_latency

語句等待時間(延遲時間)

• statement_avg_latency

執行語句平均延遲時間

• table_scans

表掃描次數

• file_ios

io時間總數

• file_io_latency

文件io延遲

• current_connections

當前鏈接數

• total_connections

總連接數

• unique_users

該主機的惟一用戶數

• current_memory

當前帳戶分配的內存

• total_memory_allocated

該主機分配的內存總數

 

2.2  The host_summary_by_file_io_type

•host

主機

•event_name

IO事件名稱

•total

該主機發生的事件

•total_latency

該主機發生IO事件總延遲時間

•max_latency

該主機IO事件中最大的延遲時間

 

2.3 The host_summary_by_file_io

•host

主機

•ios

IO事件總數

•io_latency

IO總的延遲時間

 

2.4 The host_summary_by_stages

• host

主機

• event_name

stage event名稱

• total

stage event發生的總數

• total_latency

stage event總的延遲時間

• avg_latency

stage event平均延遲時間

 

 

2.5 The host_summary_by_statement_latency

• host

主機

• total

這個主機的語句總數

• total_latency

這個主機總的延遲時間

• max_latency

主機最大的延遲時間

• lock_latency

等待鎖的鎖延遲時間

• rows_sent

該主機經過語句返回的總行數

• rows_examined

在存儲引擎上經過語句返回的行數

• rows_affected

該主機經過語句影響的總行數

• full_scans

全表掃描的語句總數

 

 

2.6  The host_summary_by_statement_type

• host

主機

• statement

最後的語句事件名稱

• total

sql語句總數

• total_latency

sql語句總延遲數

• max_latency

最大的sql語句延遲數

• lock_latency

鎖延遲總數

• rows_sent

語句返回的行總數

• rows_examined

經過存儲引擎的sql語句的讀取的總行數

• rows_affected

語句影響的總行數

• full_scans

全表掃描的語句事件總數

 

 

2.7 The innodb_buffer_stats_by_schema  

這個表是經過數據庫統計innodb引擎的innodb緩存

• object_schema

數據庫名稱

• allocated

分配給當前數據庫的總的字節數

• data

分配給當前數據庫的數據字節數

• pages

分配給當前數據庫的總頁數

• pages_hashed

分配給當前數據庫的hash頁數

• pages_old

 

分配給當前數據庫的舊頁數

• rows_cached

 

當前數據庫緩存的行數

 

2.8 The innodb_buffer_stats_by_table

這個表是經過每一個表innodb引擎的innodb緩存

• object_schema

數據庫名稱

• object_name

表名稱

• allocated

分配給表的總字節數

• data

分配該表的數據字節數

• pages

分配給表的頁數

• pages_hashed

分配給表的hash頁數

• pages_old

分配給表的舊頁數

• rows_cached

表的行緩存數

 

2.9 The innodb_lock_waits

這個表其實從視圖的語句來看就是information_schema這個數據庫中的innodb_locks、innodb_trx這兩個表的整合,可以更清晰的顯示當前實例的鎖狀況

• wait_started

鎖等待發生的時間

• wait_age

鎖已經等待了多長時間

• wait_age_secs

以秒爲單位顯示鎖已經等待的時間(5.7.9中添加此列)

• locked_table

被鎖的表

• locked_index

被鎖住的索引

• locked_type

鎖類型

• waiting_trx_id

正在等待的事務ID

• waiting_trx_started

等待事務開始的時間

• waiting_trx_age

已經等待事務多長時間

• waiting_trx_rows_locked

正在等待的事務被鎖的行數量

• waiting_trx_rows_modified

正在等待行重定義的數量

• waiting_pid

正在等待事務的線程id

• waiting_query

正在等待鎖的查詢

• waiting_lock_id

正在等待鎖的ID

• waiting_lock_mode

等待鎖的模式

• blocking_trx_id

阻塞等待鎖的事務id

• blocking_pid

正在鎖的線程id

• blocking_query

正在鎖的查詢

•blocking_lock_id

正在阻塞等待鎖的鎖id.

•blocking_lock_mode

阻塞鎖模式

• blocking_trx_started

阻塞事務開始的時間

• blocking_trx_age

阻塞的事務已經執行的時間

• blocking_trx_rows_locked

阻塞事務鎖住的行的數量

• blocking_trx_rows_modified

阻塞事務重定義行的數量

• sql_kill_blocking_query

kill 語句殺死正在運行的阻塞事務

在mysql5.7.9中被加入

• sql_kill_blocking_connection

kill 語句殺死會話中正在運行的阻塞事務

在mysql5.7.9中被加入

 

 

2.10 The io_by_thread_by_latency

這個過程主要信息是經過IO的消耗展現IO等待的時間

• user

對於當前線程來講,這個值是線程被分配的帳戶,對於後臺線程來說,就是線程的名稱

• total

IO事件的總數

• total_latency

IO事件的總延遲

• min_latency

單個最小的IO事件延遲

• avg_latency

平均IO延遲

• max_latency

最大IO延遲

• thread_id

線程ID

• processlist_id

對於當前線程就是此時的ID,對於後臺就是null

相關文章
相關標籤/搜索