全方位認識 sys 系統庫(一)


前陣子,我們的"全方位認識performance_schema"系列為大家完整的介紹了performance_schema系統庫。在我們的發布計划中為什么要把performance_schema放在最前面呢?其中一個原因就是因為它是sys 系統庫的數據來源,今天開始,我們將為大家逐步推出“全方位認識 sys 系統庫”系列文章,下面我們將為大家帶來系列第一篇《初相識|全方位認識 sys 系統庫》,請跟隨我們一起開始 sys 系統庫的系統學習之旅吧~

 

PS:本系列基於MySQL 5.7.18 版本整理

 

|  初識sys系統庫

1. sys系統庫使用基礎環境

在使用sys系統庫之前,你需要確保你的數據庫環境滿足如下條件:

1)sys系統庫支持MySQL 5.6或更高版本,5.5.x及其以下版本不支持;

2)因為sys系統庫提供了一些代替直接訪問performance_schema的視圖,所以必須啟用performance_schema(performance_schema系統參數設置為ON)之后sys系統庫的大部分功能才能正常使用;

3)要完全訪問sys系統庫,用戶必須具有以下權限: 

* 對所有sys表和視圖具有SELECT權限 
* 對所有sys存儲過程和函數具有EXECUTE權限 
* 對sys_config表具有INSERT、UPDATE權限 
* 對某些特定的sys系統庫存儲過程和函數需要額外權限,如,ps_setup_save()存儲過程,需要臨時表相關的權限

4)還有sys系統庫執行訪問的對象相關的權限: 

* 任何被sys系統庫訪問的performance_schema表需要有SELECT權限,如果要使用sys系統庫對performance_schema相關表執行更新,則需要performance_schema相關表的UPDATE權限 
* INFORMATION_SCHEMA.INNODB_BUFFER_PAGE表的PROCESS

5)如果要充分使用sys系統庫的功能,則必須啟用某些performance_schema的instruments和consumers,如下: 

* 所有wait instruments 
* 所有stage instruments 
* 所有statement instruments 
* 對於所啟用的類型事件的instruments,還需要啟用對應類型的consumers(xxx_current和xxx_history_long),要了解某存儲過程具體做了什么事情可能通過show create procedure procedure_name;語句查看

您可以使用sys系統庫本身來啟用所有需要的instruments和consumers:

* 啟用所有wait instruments:CALLsys.ps_setup_enable_instrument('wait');

* 啟用所有stage instruments:CALLsys.ps_setup_enable_instrument('stage');

* 啟用所有statement instruments:CALLsys.ps_setup_enable_instrument('statement');

* 啟用所有事件類型的current表:CALLsys.ps_setup_enable_consumer('current');

* 啟用所有事件類型的history_long表:CALLsys.ps_setup_enable_consumer('history_long');

* 注意:performance_schema的默認配置就可以滿足sys系統庫的大部分數據收集功能。啟用上述所提及的所有instruments和consumers會對性能產生一定影響,因此最好僅啟用所需的配置。如果你在啟用了一些默認配置之外的配置,則可以使用存儲過程:CALLsys.ps_setup_reset_to_default(TRUE); 來快速恢復到performance_schema的默認配置

PS:對於以上繁雜的權限要求,通常創建一個具有管理員權限的賬號即可,當然如果你有明確的需求,那另當別論,但sys系統庫通常都是提供給專業的DBA人員排查一些特定問題使用的,其下所涉及的各項查詢或多或少都會對性能有一定影響(主要體現在performance_schema功能實現的性能開銷),在不明需求的情況下,不建議開放這些功能來作為常規的監控手段使用。

2. sys系統庫初體驗

當你使用了use語句切換默認數據庫,那么就可以直接使用sys系統庫下的視圖名稱進行查詢,就像查詢某個庫下的表一樣操作,如下:

# version視圖可以查看sys 系統庫和mysql server的版本號
mysql> USE sys;
mysql> SELECT * FROM version;
------------- + ----------------- +
| sys_version | mysql_version |
------------- + ----------------- +
1.5.0 | 5.7.9-debug-log |
------------- + ----------------- +

 

也可以使用db_name.view_name、db_name.procedure_name、db_name.func_name等方式在不指定默認數據庫的情況下訪問sys 系統庫中的對象(這叫做名稱限定對象引用),如下:

mysql> SELECT * FROM sys.version;
------------- + ----------------- +
| sys_version | mysql_version |
------------- + ----------------- +
1.5.0 | 5.7.9-debug-log |
------------- + ----------------- +

 

PS:下文中的示例中,對於sys 系統庫的訪問都是假定指定了默認數據庫為sys 系統庫。

sys 系統庫下包含許多視圖,它們以各種方式對performance_schema表進行聚合計算展示。這些視圖中大部分都是成對出現,兩個視圖名稱相同,但有一個視圖是帶'x$'字符前綴的,例如:host_summary_by_file_io和x$host_summary_by_file_io,代表按照主機進行匯總統計的文件I/O性能數據,兩個視圖訪問數據源是相同的,但是創建視圖的語句中,不帶x$的視圖是把相關數值數據經過單位換算再顯示的(顯示為毫秒、秒、分鍾、小時、天等),帶x$前綴的視圖顯示的是原始的數據(皮秒),如下:

# x$host_summary_by_file_io視圖匯總數據,顯示未格式化的皮秒單位延遲時間,沒有x$前綴字符的視圖輸出的信息經過單位換算之后可讀性更高
mysql> SELECT * FROM host_summary_by_file_io;
+------------+-------+------------+
| host      | ios  | io_latency |
+------------+-------+------------+
| localhost  | 67570 | 5.38 s    |
| background |  3468 | 4.18 s    |
+------------+-------+------------+
# 對於帶x$的視圖顯示原始的皮秒單位數值,對於程序或工具獲取使用更易於數據處理
mysql> SELECT * FROM x$host_summary_by_file_io;
+------------+-------+---------------+
| host      | ios  | io_latency    |
+------------+-------+---------------+
| localhost  | 67574 | 5380678125144 |
| background |  3474 | 4758696829416 |
+------------+-------+---------------+

 

要查看sys 系統庫對象定義語句,可以使用適當的SHOW語句或INFORMATION_SCHEMA庫查詢。例如,要查看session視圖和format_bytes()函數的定義,可以使用如下語句:

mysql> SHOW CREATE VIEW session;
mysql> SHOW CREATE FUNCTION format_bytes;

 

然而,這些語句文本是經過格式化的,可讀性比較差。要查看更易讀的格式對象定義語句,可以訪問sys 系統庫開發網站https://github.com/mysql/mysql-sys上的各個.sql文件,或者使用mysqldump與mysqlpump工具導出sys庫,默認情況下,mysqldump和mysqlpump都不會導出sys 系統庫。要生成包含sys 系統庫的導出文件,可以使用如下命令顯式指定sys 系統庫(雖然可以導出視圖定義,但是與原始的定義語句相比仍然缺失了相當一部分內容,只是可讀性比直接show create view要好一些):

mysqldump --databases --routines sys> sys_dump.sql
mysqlpump sys> sys_dump.sql

 

如果要重新導入sys 系統庫,可以使用如下命令:

mysql < sys_dump.sql

 

3. sys 系統庫的進度報告功能

從MySQL 5.7.9開始,sys 系統庫視圖提供查看長時間運行的事務的進度報告,通過processlist和session以及x$前綴的視圖進行查看,其中processlist包含了后台線程和前台線程當前的事件信息,session不包含后台線程和command為Daemon的線程,如下:

processlist
session
x$processlist
x$session

 

session視圖是直接調用processlist視圖過濾了后台線程和command為Daemon的線程(所以兩個視圖輸出結果的字段相同),而processlist線程聯結查詢了threads、events_waits_current、events_stages_current、events_statements_current、events_transactions_current、sys.x$memory_by_thread_by_current_bytes、session_connect_attrs表,so,需要打開相應的instruments和consumers,否則誰沒打開誰對應的信息字段列就為NULL,對於trx_state字段為ACTIVE的線程,progress可以輸出百分比進度信息(只有支持進度的事件才會被統計並打印進來)

查詢示例

# 查看當前正在執行的語句進度信息
admin@localhost : sys 06:57:21> select * from session where conn_id!=connection_id() and trx_state='ACTIVE'\G;
*************************** 1. row ***************************
            thd_id: 47
          conn_id: 5
              user: admin@localhost
                db: sbtest
          command: Query
            state: alter table (merge sort)
              time: 29
current_statement: alter table sbtest1 add index i_c(c)
statement_latency: 29.34 s
          progress: 49.70
      lock_latency: 4.34 ms
    rows_examined: 0
        rows_sent: 0
    rows_affected: 0
        tmp_tables: 0
  tmp_disk_tables: 0
        full_scan: NO
    last_statement: NULL
last_statement_latency: NULL
    current_memory: 4.52 KiB
        last_wait: wait/io/file/innodb/innodb_temp_file
last_wait_latency: 369.52 us
            source: os0file.ic:470
      trx_latency: 29.45 s
        trx_state: ACTIVE
    trx_autocommit: YES
              pid: 4667
      program_name: mysql
1 row in set (0.12 sec)
# 查看已經執行完的語句相關統計信息
admin@localhost : sys 07:02:21> select * from session where conn_id!=connection_id() and trx_state='COMMITTED'\G;
*************************** 1. row ***************************
            thd_id: 47
          conn_id: 5
              user: admin@localhost
                db: sbtest
          command: Sleep
            state: NULL
              time: 372
current_statement: NULL
statement_latency: NULL
          progress: NULL
      lock_latency: 4.34 ms
    rows_examined: 0
        rows_sent: 0
    rows_affected: 0
        tmp_tables: 0
  tmp_disk_tables: 0
        full_scan: NO
    last_statement: alter table sbtest1 add index i_c(c)
last_statement_latency: 1.61 m
    current_memory: 4.52 KiB
        last_wait: idle
last_wait_latency: Still Waiting
            source: socket_connection.cc:69
      trx_latency: 1.61 m
        trx_state: COMMITTED
    trx_autocommit: YES
              pid: 4667
      program_name: mysql
1 row in set (0.12 sec)

 

對於stage事件進度報告要求必須啟用events_stages_current consumers,啟用需要查看進度相關的instruments。例如:

stage/sql/Copying to tmp table
stage/innodb/alter table (end)
stage/innodb/alter table (flush)
stage/innodb/alter table (insert)
stage/innodb/alter table (log apply index)
stage/innodb/alter table (log apply table)
stage/innodb/alter table (merge sort)
stage/innodb/alter table (read PK and internal sort)
stage/innodb/buffer pool load

 

對於不支持進度的stage 事件,或者未啟用所需的instruments或consumers的stage事件,則對應的進度信息列顯示為NULL。

本期內容就介紹到這里,本期內容參考鏈接如下:

https://dev.mysql.com/doc/refman/5.7/en/sys-schema-progress-reporting.html

https://dev.mysql.com/doc/refman/5.7/en/sys-schema-prerequisites.html

https://dev.mysql.com/doc/refman/5.7/en/sys-schema-usage.html

 

 ================================================================================================================

 

================================================================================================================

 

mysql5.7增加了sys 系統數據庫,通過這個庫可以快速的了解系統的元數據信息
這個庫確實可以方便DBA發現數據庫的很多信息,解決性能瓶頸都提供了巨大幫助
 
這個庫在mysql5.7中是默認存在的,在mysql5.6版本以上可以手動導入,數據庫包請在github自行查找
 
這個庫包括了哪些內容?
這個庫是通過視圖的形式把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
 
    表中默認數據為
variable    
value    
set_time    
set_by
diagnostics.allow_i_s_tables  
  OFF 
  2015-11-20 16:04:38 
     root@localhost
diagnostics.include_raw 
   OFF
   2015-11-20 16:04:38 
     root@localhost
statement_performance_analyzer.limit 
  100
  2015-11-20 16:04:38  
     root@localhost
statement_performance_analyzer.view 
 
2015-11-20 16:04:38
     root@localhost
statement_truncate_len  
  64 
   2016-01-22 17:00:16    
     root@localhost
 
    以上值的會話變量為@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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

"翻過這座山,你就可以看到一片海!"。堅持閱讀我們的"全方位認識 sys 系統庫"系列文章分享,你就可以系統地學完它。 謝謝你的閱讀,我們下期不見不散!


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM