在說明系統數據庫以前,先來看下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