會話和鎖資訊查詢檢視 | 全方位認識 sys 系統庫
在上一篇《等待事件統計檢視 | 全方位認識 sys 系統庫》中,我們介紹了sys 系統庫中的等待事件統計檢視,本期的內容先給大家介紹會話資訊和鎖等待資訊查詢檢視,通過這些檢視我們可以清晰地知道每個會話正在做什麼事情,是否存在鎖等待。下面請跟隨我們一起開始 sys 系統庫的系統學習之旅吧~
PS:由於本文中所提及的檢視功能的特殊性(DBA日常工作中除了排查慢SQL之外,另外一個可能需要佔用大量精力的地方可能就是鎖問題分析),所以下文中會列出相應檢視中的select語句文字,以便大家更直觀地學習它們。
01.innodb_lock_waits,x$innodb_lock_waits
InnoDB當前鎖等待資訊,預設按照發生鎖等待的開始時間升序排序--wait_started欄位即innodb_trx表的trx_wait_started欄位。資料來源:information_schema的innodb_trx、innodb_locks、innodb_lock_waits(注:在8.0及其之後的版本中,該檢視的資訊來源為information_schema的innodb_trx、performance_schema的data_locks和data_lock_waits)
檢視查詢語句文字
# 不帶x$字首的檢視的查詢語句 SELECT r.trx_wait_started AS wait_started, TIMEDIFF(NOW(), r.trx_wait_started) AS wait_age, TIMESTAMPDIFF(SECOND, r.trx_wait_started, NOW()) AS wait_age_secs, rl.lock_table AS locked_table, rl.lock_index AS locked_index, rl.lock_type AS locked_type, r.trx_id AS waiting_trx_id, r.trx_started as waiting_trx_started, TIMEDIFF(NOW(), r.trx_started) AS waiting_trx_age, r.trx_rows_locked AS waiting_trx_rows_locked, r.trx_rows_modified AS waiting_trx_rows_modified, r.trx_mysql_thread_id AS waiting_pid, sys.format_statement(r.trx_query) AS waiting_query, rl.lock_id AS waiting_lock_id, rl.lock_mode AS waiting_lock_mode, b.trx_id AS blocking_trx_id, b.trx_mysql_thread_id AS blocking_pid, sys.format_statement(b.trx_query) AS blocking_query, bl.lock_id AS blocking_lock_id, bl.lock_mode AS blocking_lock_mode, b.trx_started AS blocking_trx_started, TIMEDIFF(NOW(), b.trx_started) AS blocking_trx_age, b.trx_rows_locked AS blocking_trx_rows_locked, b.trx_rows_modified AS blocking_trx_rows_modified, CONCAT('KILL QUERY ', b.trx_mysql_thread_id) AS sql_kill_blocking_query, CONCAT('KILL ', b.trx_mysql_thread_id) AS sql_kill_blocking_connection FROM information_schema.innodb_lock_waits w INNER JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id INNER JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id INNER JOIN information_schema.innodb_locks bl ON bl.lock_id = w.blocking_lock_id INNER JOIN information_schema.innodb_locks rl ON rl.lock_id = w.requested_lock_id ORDER BY r.trx_wait_started; # x$innodb_lock_waits:在8.0之前的版本,兩者無區別
下面我們看看使用該檢視查詢返回的結果
# 不帶x$字首的檢視 [email protected] : sys 12:41:45> select * from innodb_lock_waits\G; *************************** 1. row *************************** wait_started: 2017-09-07 00:42:32 wait_age: 00:00:12 wait_age_secs: 12 locked_table: `luoxiaobo`.`test` locked_index: GEN_CLUST_INDEX locked_type: RECORD waiting_trx_id: 66823 waiting_trx_started: 2017-09-07 00:42:32 waiting_trx_age: 00:00:12 waiting_trx_rows_locked: 1 waiting_trx_rows_modified: 0 waiting_pid: 7 waiting_query: select * from test limit 1 for update waiting_lock_id: 66823:106:3:2 waiting_lock_mode: X blocking_trx_id: 66822 blocking_pid: 6 blocking_query: NULL blocking_lock_id: 66822:106:3:2 blocking_lock_mode: X blocking_trx_started: 2017-09-07 00:42:19 blocking_trx_age: 00:00:25 blocking_trx_rows_locked: 1 blocking_trx_rows_modified: 0 sql_kill_blocking_query: KILL QUERY 6 sql_kill_blocking_connection: KILL 6 1 row in set, 3 warnings (0.00 sec)
檢視欄位含義如下:
-
wait_started:發生鎖等待的開始時間
-
wait_age:鎖已經等待了多久,該值是一個時間格式值
-
wait_age_secs:鎖已經等待了幾秒鐘,該值是一個整型值,MySQL 5.7.9中新增
-
locked_table:鎖等待的表名稱。此列值格式為:schema_name.table_name
-
locked_index:鎖等待的索引名稱
-
locked_type:鎖等待的鎖型別
-
waiting_trx_id:鎖等待的事務ID
-
waiting_trx_started:發生鎖等待的事務開始時間
-
waiting_trx_age:發生鎖等待的事務總的鎖等待時間,該值是一個時間格式
-
waiting_trx_rows_locked:發生鎖等待的事務已經鎖定的行數(如果是複雜事務會累計)
-
waiting_trx_rows_modified:發生鎖等待的事務已經修改的行數(如果是複雜事務會累計)
-
waiting_pid:發生鎖等待的事務的processlist_id
-
waiting_query:發生鎖等待的事務SQL語句文字
-
waiting_lock_id:發生鎖等待的鎖ID
-
waiting_lock_mode:發生鎖等待的鎖模式
-
blocking_trx_id:持有鎖的事務ID
-
blocking_pid:持有鎖的事務processlist_id
-
blocking_query:持有鎖的事務的SQL語句文字
-
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語句來殺死持有鎖的查詢語句(而不是終止會話)。該列在MySQL 5.7.9中新增
-
sql_kill_blocking_connection:執行KILL語句以終止持有鎖的語句的會話。該列在MySQL 5.7.9中新增
PS:8.0中廢棄information_schema.innodb_locks和information_schema.innodb_lock_waits,遷移到performance_schema.data_locks和performance_schema.data_lock_waits,詳見連結:
https://dev.mysql.com/doc/refman/8.0/en/data-locks-table.html
https://dev.mysql.com/doc/refman/8.0/en/data-lock-waits-table.html
02.processlist,x$processlist
包含所有前臺和後臺執行緒的processlist資訊,預設按照程序等待時間和最近一個語句執行完成的時間降序排序。資料來源:performance_schema的threads、events_waits_current、events_statements_current、events_stages_current 、events_transactions_current 、session_connect_attrs表和 sys 系統庫的 x$memory_by_thread_by_current_bytess檢視
-
這些檢視列出了程序相關的較為詳細的資訊,比SHOW PROCESSLIST語句和INFORMATION_SCHEMA PROCESSLIST表更完整,且對該檢視的查詢是非阻塞的(因為不是從information_schema.processlist表中獲取資料的,對processlist表查詢是阻塞的)
檢視查詢語句文字
# 不帶x$字首的檢視
SELECT pps.thread_id AS thd_id,
pps.processlist_id AS conn_id,
IF(pps.name = 'thread/sql/one_connection',
CONCAT(pps.processlist_user, '@', pps.processlist_host),
REPLACE(pps.name, 'thread/', '')) user,
pps.processlist_db AS db,
pps.processlist_command AS command,
pps.processlist_state AS state,
pps.processlist_time AS time,
sys.format_statement(pps.processlist_info) AS current_statement,
IF(esc.end_event_id IS NULL,
sys.format_time(esc.timer_wait),
NULL) AS statement_latency,
IF(esc.end_event_id IS NULL,
ROUND(100 * (estc.work_completed / estc.work_estimated), 2),
NULL) AS progress,
sys.format_time(esc.lock_time) AS lock_latency,
esc.rows_examined AS rows_examined,
esc.rows_sent AS rows_sent,
esc.rows_affected AS rows_affected,
esc.created_tmp_tables AS tmp_tables,
esc.created_tmp_disk_tables AS tmp_disk_tables,
IF(esc.no_good_index_used > 0 OR esc.no_index_used > 0, 'YES', 'NO') AS full_scan,
IF(esc.end_event_id IS NOT NULL,
sys.format_statement(esc.sql_text),
NULL) AS last_statement,
IF(esc.end_event_id IS NOT NULL,
sys.format_time(esc.timer_wait),
NULL) AS last_statement_latency,
sys.format_bytes(mem.current_allocated) AS current_memory,
ewc.event_name AS last_wait,
IF(ewc.end_event_id IS NULL AND ewc.event_name IS NOT NULL,
'Still Waiting',
sys.format_time(ewc.timer_wait)) last_wait_latency,
ewc.source,
sys.format_time(etc.timer_wait) AS trx_latency,
etc.state AS trx_state,
etc.autocommit AS trx_autocommit,
conattr_pid.attr_value as pid,
conattr_progname.attr_value as program_name
FROM performance_schema.threads AS pps
LEFT JOIN performance_schema.events_waits_current AS ewc USING (thread_id)
LEFT JOIN performance_schema.events_stages_current AS estc USING (thread_id)
LEFT JOIN performance_schema.events_statements_current AS esc USING (thread_id)
LEFT JOIN performance_schema.events_transactions_current AS etc USING (thread_id)
LEFT JOIN sys.x$memory_by_thread_by_current_bytes AS mem USING (thread_id)
LEFT JOIN performance_schema.session_connect_attrs AS conattr_pid
ON conattr_pid.processlist_id=pps.processlist_id and conattr_pid.attr_name='_pid'
LEFT JOIN performance_schema.session_connect_attrs AS conattr_progname
ON conattr_progname.processlist_id=pps.processlist_id and conattr_progname.attr_name='program_name'
ORDER BY pps.processlist_time DESC, last_wait_latency DESC;
# 帶x$字首的檢視查詢語句與不帶x$字首的檢視查詢語句相比,只是少了單位格式化函式
......
下面我們看看使用該檢視查詢返回的結果
# 不帶x$字首的檢視
[email protected] : sys 04:27:20> select * from processlist where program_name='mysql' and trx_state is not null limit 1\G
*************************** 1. row ***************************
thd_id: 49
conn_id: 7
user: [email protected]
db: sbtest
command: Sleep
state: NULL
time: 89
current_statement: NULL
statement_latency: NULL
progress: NULL
lock_latency: 157.00 us
rows_examined: 1000
rows_sent: 1000
rows_affected: 0
tmp_tables: 0
tmp_disk_tables: 0
full_scan: YES
last_statement: select * from sbtest1 limit 1000
last_statement_latency: 2.06 ms
current_memory: 0 bytes
last_wait: idle
last_wait_latency: Still Waiting
source: socket_connection.cc:69
trx_latency: 1.49 ms
trx_state: COMMITTED
trx_autocommit: YES
pid: 3927
program_name: mysql
1 row in set (0.13 sec)
# 帶x$字首的檢視
[email protected] : sys 04:27:28> select * from x$processlist where program_name='mysql' and trx_state is not null limit 1\G;
*************************** 1. row ***************************
thd_id: 49
conn_id: 7
user: [email protected]
db: sbtest
command: Sleep
state: NULL
time: 150
current_statement: NULL
statement_latency: NULL
progress: NULL
lock_latency: 157000000
rows_examined: 1000
rows_sent: 1000
rows_affected: 0
tmp_tables: 0
tmp_disk_tables: 0
full_scan: YES
last_statement: select * from sbtest1 limit 1000
last_statement_latency: 2055762000
current_memory: 0
last_wait: idle
last_wait_latency: Still Waiting
source: socket_connection.cc:69
trx_latency: 1490662000
trx_state: COMMITTED
trx_autocommit: YES
pid: 3927
program_name: mysql
1 row in set (0.14 sec)
檢視欄位含義如下:
-
thd_id:內部threqd ID
-
conn_id:連線ID,即processlist id
-
user:對於前臺執行緒,該欄位值為account名稱,對於後臺執行緒,該欄位值為後臺執行緒名稱
-
db:執行緒的預設資料庫,如果沒有預設資料庫,則該欄位值為NULL
-
command:對於前臺執行緒,表示執行緒正在執行的客戶端程式碼對應的command名稱,如果會話處於空閒狀態則該欄位值為'Sleep ',對於後臺超執行緒,該欄位值為NULL
-
state:表示執行緒正在做什麼:什麼事件或狀態,與information_schema.processlist表中的state欄位值一樣
-
time:表示執行緒處於當前狀態已經持續了多長時間(秒)
-
current_statement:執行緒當前正在執行的語句,如果當前沒有執行任何語句,該欄位值為NULL
-
statement_latency:執行緒當前語句已經執行了多長時間,該欄位在MySQL 5.7.9中新增
-
progress:在支援進度報告的階段事件中統計的工作進度百分比。 該欄位在MySQL 5.7.9中新增
-
lock_latency:當前語句的鎖等待時間
-
rows_examined:當前語句從儲存引擎檢查的資料行數
-
rows_sent:當前語句返回給客戶端的資料行數
-
rows_affected:受當前語句影響的資料行數(DML語句對資料執行變更才會影響行)
-
tmp_tables:當前語句建立的內部記憶體臨時表的數量
-
tmp_disk_tables:當前語句建立的內部磁碟臨時表的數量
-
full_scan:當前語句執行的全表掃描次數
-
last_statement:如果在performance_schema.threads表中沒有找到正在執行的語句或正在等待執行的語句,那麼在該欄位可以顯示執行緒執行的最後一個語句(在performance_schema.events_statements_current表中查詢,該表中會為每一個執行緒保留最後一條語句執行的事件資訊,其他current字尾的事件記錄表也類似)
-
last_statement_latency:執行緒執行的最近一個語句執行了多長時間
-
current_memory:當前執行緒分配的位元組數
-
last_wait:執行緒最近的等待事件名稱
-
last_wait_latency:執行緒最近的等待事件的等待時間(執行時間)
-
source:執行緒最近的等待事件的instruments所在原始檔和行號
-
trx_latency:執行緒當前正在執行的事務已經執行了多長時間,該列在MySQL 5.7.9中新增
-
trx_state:執行緒當前正在執行的事務的狀態,該列在MySQL 5.7.9中新增
-
trx_autocommit:執行緒當前正在執行的事務的提交模式,有效值為:'ACTIVE','COMMITTED','ROLLED BACK',該列在MySQL 5.7.9中新增
-
pid:客戶端程序ID,該列在MySQL 5.7.9中新增
-
program_name:客戶端程式名稱,該列在MySQL 5.7.9中新增
03.session,x$session
檢視當前使用者會話的程序列表資訊,與processlist&x$processlist檢視類似,但是session檢視過濾掉了後臺執行緒,只顯示前臺(使用者)執行緒相關的統計資料,資料來源:sys.processlist
-
該檢視在MySQL 5.7.9中新增
檢視查詢語句
# 不帶x$的檢視查詢語句
## 只需要在processlist檢視的查詢語句上加上如下條件即可
......
[WHERE] conn_id IS NOT NULL AND command != 'Daemon';
# 帶x$字首的檢視查詢語句與不帶x$字首的檢視查詢語句相比,只是少了單位格式化函式
......
下面我們看看使用該檢視查詢返回的結果
# 不帶x$字首的檢視
[email protected] : sys 12:44:22> select * from session where command='query' and conn_id!=connection_id()\G
*************************** 1. row ***************************
thd_id: 48
conn_id: 6
user: [email protected]
db: xiaoboluo
command: Query
state: Sending data
time: 72
current_statement: select * from test limit 1 for update
statement_latency: 1.20 m
progress: NULL
lock_latency: 169.00 us
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: 461 bytes
last_wait: wait/io/table/sql/handler
last_wait_latency: Still Waiting
source: handler.cc:3185
trx_latency: NULL
trx_state: NULL
trx_autocommit: NULL
pid: 3788
program_name: mysql
1 row in set (0.15 sec)
# 帶x$字首的檢視
[email protected] : sys 12:45:09> select * from x$session where command='query' and conn_id!=connection_id()\G;
*************************** 1. row ***************************
thd_id: 48
conn_id: 6
user: [email protected]
db: xiaoboluo
command: Query
state: Sending data
time: 91
current_statement: select * from test limit 1 for update
statement_latency: 91077336919000
progress: NULL
lock_latency: 169000000
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: 461
last_wait: wait/io/table/sql/handler
last_wait_latency: Still Waiting
source: handler.cc:3185
trx_latency: NULL
trx_state: NULL
trx_autocommit: NULL
pid: 3788
program_name: mysql
1 row in set (0.13 sec)
檢視欄位含義
-
與processlist,x$processlist檢視相同,但session檢視排除了後臺執行緒和Daemon執行緒,只查詢使用者連線執行緒的資訊
04.schema_table_lock_waits,x$schema_table_lock_waits
檢視當前連結執行緒的MDL鎖等待資訊,顯示哪些會話被MDL鎖阻塞,是誰阻塞了這些會話,資料來源:performance_schema下的threads、metadata_locks、events_statements_current表
-
MDL鎖的instruments預設沒有啟用,要使用需要顯式開啟,如下:
* 啟用MDL鎖的instruments:update setup_instruments set enabled='yes',timed='yes' where name='wait/lock/metadata/sql/mdl';
* 或者也可以使用sys 系統庫下的輔助性檢視操作:call sys.ps_setup_enable_instrument('wait/lock/metadata/sql/mdl'); -
該檢視在MySQL 5.7.9中新增
檢視定義語句文字
# 不帶x$的檢視查詢語句
SELECT g.object_schema AS object_schema,
g.object_name AS object_name,
pt.thread_id AS waiting_thread_id,
pt.processlist_id AS waiting_pid,
sys.ps_thread_account(p.owner_thread_id) AS waiting_account,
p.lock_type AS waiting_lock_type,
p.lock_duration AS waiting_lock_duration,
sys.format_statement(pt.processlist_info) AS waiting_query,
pt.processlist_time AS waiting_query_secs,
ps.rows_affected AS waiting_query_rows_affected,
ps.rows_examined AS waiting_query_rows_examined,
gt.thread_id AS blocking_thread_id,
gt.processlist_id AS blocking_pid,
sys.ps_thread_account(g.owner_thread_id) AS blocking_account,
g.lock_type AS blocking_lock_type,
g.lock_duration AS blocking_lock_duration,
CONCAT('KILL QUERY ', gt.processlist_id) AS sql_kill_blocking_query,
CONCAT('KILL ', gt.processlist_id) AS sql_kill_blocking_connection
FROM performance_schema.metadata_locks g
INNER JOIN performance_schema.metadata_locks p
ON g.object_type = p.object_type
AND g.object_schema = p.object_schema
AND g.object_name = p.object_name
AND g.lock_status = 'GRANTED'
AND p.lock_status = 'PENDING'
INNER JOIN performance_schema.threads gt ON g.owner_thread_id = gt.thread_id
INNER JOIN performance_schema.threads pt ON p.owner_thread_id = pt.thread_id
LEFT JOIN performance_schema.events_statements_current gs ON g.owner_thread_id = gs.thread_id
LEFT JOIN performance_schema.events_statements_current ps ON p.owner_thread_id = ps.thread_id
WHERE g.object_type = 'TABLE';
# 帶x$字首的檢視查詢語句與不帶x$字首的檢視查詢語句相比,只是少了單位格式化函式
......
下面我們看看使用該檢視查詢返回的結果
[email protected] : sys 11:31:57> select * from schema_table_lock_waits\G;
*************************** 1. row ***************************
object_schema: xiaoboluo
object_name: test
waiting_thread_id: 1217
waiting_pid: 1175
waiting_account: [email protected]
waiting_lock_type: EXCLUSIVE
waiting_lock_duration: TRANSACTION
waiting_query: alter table test add index i_k(test)
waiting_query_secs: 58
waiting_query_rows_affected: 0
waiting_query_rows_examined: 0
blocking_thread_id: 49
blocking_pid: 7
blocking_account: [email protected]
blocking_lock_type: SHARED_WRITE
blocking_lock_duration: TRANSACTION
sql_kill_blocking_query: KILL QUERY 7
sql_kill_blocking_connection: KILL 7
*************************** 2. row ***************************
object_schema: xiaoboluo
object_name: test
waiting_thread_id: 1217
waiting_pid: 1175
waiting_account: [email protected]
waiting_lock_type: EXCLUSIVE
waiting_lock_duration: TRANSACTION
waiting_query: alter table test add index i_k(test)
waiting_query_secs: 58
waiting_query_rows_affected: 0
waiting_query_rows_examined: 0
blocking_thread_id: 1217
blocking_pid: 1175
blocking_account: [email protected]
blocking_lock_type: SHARED_UPGRADABLE
blocking_lock_duration: TRANSACTION
sql_kill_blocking_query: KILL QUERY 1175
sql_kill_blocking_connection: KILL 1175
2 rows in set (0.00 sec)
檢視欄位含義如下:
-
object_schema:發生MDL鎖等待的schema名稱
-
OBJECT_NAME:MDL鎖等待監控物件的名稱
-
waiting_thread_id:正在等待MDL鎖的thread ID
-
waiting_pid:正在等待MDL鎖的processlist ID
-
waiting_account:正在等待MDL鎖的執行緒關聯的account名稱
-
waiting_lock_type:被阻塞的執行緒正在等待的MDL鎖型別
-
waiting_lock_duration:該欄位來自元資料鎖子系統中的鎖定時間。有效值為:STATEMENT、TRANSACTION、EXPLICIT,STATEMENT和TRANSACTION值分別表示在語句或事務結束時會釋放的鎖。 EXPLICIT值表示可以在語句或事務結束時被會保留,需要顯式釋放的鎖,例如:使用FLUSH TABLES WITH READ LOCK獲取的全域性鎖
-
waiting_query:正在等待MDL鎖的執行緒對應的語句文字
-
waiting_query_secs:正在等待MDL鎖的語句已經等待了多長時間(秒)
-
waiting_query_rows_affected:受正在等待MDL鎖的語句影響的資料行數(該欄位來自performance_schema.events_statement_current表,該表中記錄的是語句事件,如果語句是多表聯結查詢,則該語句可能已經執行了一部分DML語句,所以哪怕該語句當前被其他執行緒阻塞了,被阻塞執行緒的這個欄位也可能出現大於0的值)
-
waiting_query_rows_examined:正在等待MDL鎖的語句從儲存引擎檢查的資料行數(同理,該欄位來自performance_schema.events_statement_current表)
-
blocking_thread_id:持有MDL鎖的thread ID
-
blocking_pid:持有MDL鎖的processlist ID
-
blocking_account:持有MDL鎖的執行緒關聯的account名稱
-
blocking_lock_type:持有MDL鎖的鎖型別
-
blocking_lock_duration:與waiting_lock_duration欄位解釋相同,只是該值與持有MDL鎖的執行緒相關
-
sql_kill_blocking_query:生成的KILL掉持有MDL鎖的查詢的語句
-
sql_kill_blocking_connection:生成的KILL掉持有MDL鎖對應會話的語句
本期內容就介紹到這裡,本期內容參考連結如下:
https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-lock-waits.html
https://dev.mysql.com/doc/refman/5.7/en/sys-innodb-lock-waits.html
https://dev.mysql.com/doc/refman/5.7/en/sys-processlist.html
https://dev.mysql.com/doc/refman/5.7/en/sys-session.html
| 作者簡介
羅小波·沃趣科技高階資料庫技術專家
IT從業多年,歷任運維工程師,高階運維工程師,運維經理,資料庫工程師,曾參與版本釋出系統,輕量級監控系統,運維管理平臺,資料庫管理平臺的設計與編寫,熟悉MySQL的體系結構時,InnoDB儲存引擎,喜好專研開源技術,追求完美。
相關推薦
會話和鎖資訊查詢檢視 | 全方位認識 sys 系統庫
在上一篇《等待事件統計檢視 | 全方位認識 sys 系統庫》中,我們介紹了sys 系統庫中的等待事件統計檢視,本期的內容先給大家介紹會話資訊和鎖等待資訊查詢檢視,通過這些檢視我們可以清晰地知道每個會話正在做什麼事情,是否存在鎖等待。下面請跟隨我們一起開始 sys 系統庫的系統
統計資訊查詢檢視 | 全方位認識 sys 系統庫
在上一篇《會話和鎖資訊查詢檢視|全方位認識 sys 系統庫》中,我們介紹瞭如何使用 sys 系統庫總的檢視來查詢會話狀態資訊以及鎖等待資訊,本期的內容先給大家介紹查詢表和索引相關的統計資訊快捷檢視。下面請跟隨我們一起開始 sys 系統庫的系統學習之旅吧。 PS:由於本文中所提及的檢視功能的特殊性
記憶體分配統計檢視 | 全方位認識 sys 系統庫
在上一篇《按 file 分組統計檢視 | 全方位認識 sys 系統庫》中,我們介紹了sys 系統庫中按 file 分組統計的檢視,本期的內容將為大家介紹記憶體事件和innodb buffer pool記憶體分配的統計檢視。下面請跟隨我們一起開始 sys 系統庫的系統學習之旅吧。 PS:
語句效率統計檢視 | 全方位認識 sys 系統庫
在上一篇《統計資訊查詢檢視|全方位認識 sys 系統庫》中,我們介紹了利用sys 系統庫的查詢統計資訊的快捷檢視,本期將為大家介紹語句查詢效率語句統計資訊相關的檢視,這些檢視可以快速找出資料庫中哪些語句使用了全表掃描、哪些語句使用了檔案排序、哪些語句使用了臨時表。 PS:由於本文中所提及的檢視功
按 host 分組統計檢視 | 全方位認識 sys 系統庫
在上一篇《配置表|全方位認識 sys 系統庫》中,我們介紹了sys 系統庫的配置表,但實際上我們大部分人大多數時候並不需要去修改配置表,直接使用sys 系統庫下的檢視來獲取所需的資料即可,sys 系統庫下一共有100多檢視,這些檢視都能夠給我們提供一些什麼樣的資訊呢?本期的內
配置查詢與執行緒追蹤函式|全方位認識 sys 系統庫
不知不覺中,我們的"全方位認識 sys 系統庫" 系列文章已經接近尾聲了,在上一篇《字串與數字轉換函式|全方位認識 sys 系統庫》中,我們介紹了sys 系統庫中用於字串和數字格式化轉換的函式,本期的內容給大家介紹 sys 系統庫中的剩餘函式,這也是本系列文章的最後一篇。 PS:下文中如果函式定
用於檢視配置的儲存過程 | 全方位認識 sys 系統庫
在上一篇《用於修改配置的儲存過程 | 全方位認識 sys 系統庫》中,我們介紹了sys 系統庫中用於修改配置的儲存過程,利用這些儲存過程可以代替修改performance_schema配置表的DML語句等操作,本期的內容講介紹用於檢視performance_schema配置資訊的儲存過程。 PS
字串與數字轉換函式 | 全方位認識 sys 系統庫
本系列在之前的文章中我們為大家介紹了sys 系統庫的快捷檢視、函式,本期開始我們將為大家介紹 sys 系統庫的函式。 PS:下文中如果函式定義文字較短的會列出部分函式的定義文字,以便大家更直觀地學習它們。過長的函式定義文字請自行按照《初相識|全方位認識 sys 系統庫》一文
配置表 | 全方位認識 sys 系統庫
在上一篇《初相識 | 全方位認識 sys 系統庫》中,我們針對sys 系統庫做了一個不痛不癢的開端,是不是覺得太簡單了?別急,本期我們將為大家帶來系列第二篇《配置表|全方位認識 sys 系統庫》,讓你一次性重新找回學習performance_schema時的感覺,下面請跟隨我
Oracle——使用者、角色和許可權資訊的檢視總結
Oracle在sys使用者方案中內建了許多檢視,我們可以利用它們方便地檢視系統相關的資訊。在呼叫這些檢視的時候我們可以不加schema,以下是一些 關於使用者、角色和許可權資訊的檢視總結: (1)all_users檢視:可以檢視當前使用者可以看到的所有使用者 (2)
審計資訊查詢+檢視登入使用者退出資訊
審計資訊查詢 當前的審計引數值 1設定物件資料操作 audit select,insert,delete on scott.dept by access; 2為了方面檢視,先將sys.aud$表的資料進行刪除(開發中不建議) delete
基於百度地圖SDK和Elasticsearch GEO查詢的地理圍欄分析系統(3)-前端實現
方便 復制 類型 復制代碼 自動跳轉 rar 窗口 stack delete 轉載自:http://www.cnblogs.com/Auyuer/p/8086975.html MoonLight可視化訂單需求區域分析系統實現功能: 在現實生活中,計算機和互聯網迅速發展,
根據身份證號和社會保險號碼查詢不出您的醫保資訊 請核實後重新填寫
分享一下我老師大神的人工智慧教程!零基礎,通俗易懂!http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識,造福人民,實現我們中華民族偉大復興!  
Fanuc 檢視軟體和硬體資訊的方法
--------------------------------------------- -- 時間:2018-11-04 -- 建立人:Ruo_Xiao -- 郵箱:[email protected] ----------------------------------------
Linux 檢視 cpu, mem, disk 和 network 資訊
對於一個 Linux 伺服器來說,cpu 的主頻以及佔用率,記憶體的大小以及佔用率,磁碟 I/O 速率和網絡卡 I/O 速率極大地影響著伺服器的效能。在 Linux 系統下,開發者提供了/proc 檔案系統來提供系統相關的程序資訊 1.檢視 cpu 主頻和佔用率 Linux 下 CPU 的主
Linux下檢視系統版本號和核心資訊的方法
本文轉載,侵刪!感謝博主”huoyuanshen”(✈機票點我) 參考URL:http://www.ha97.com/2987.html 簡要:1,lsb_release -a 檢視linux系統版本 &n
檢視linux伺服器的記憶體和CPU資訊
記憶體資訊: 檢視記憶體資訊 # cat /proc/meminfo CPU: 註釋: 1、總核數 = 物理CPU個數 X 每顆物理CPU的核數 2、總邏輯CPU數 = 物理CPU個數 X 每顆物理CPU的核數 X 超執行緒數 # 檢視物理CPU個數 cat
使用Tunnellij檢視請求和響應資訊
在學習Javaweb的時候可能想用一些外掛看看請求和響應資訊,在eclipse上有個TCP/IP monitor的外掛可以使用,而新一代的Java學者都逐漸使用IDEA作為開發工具。但是網上的各種學習視訊主要都是以eclipse為主,我也是在網上找了好久資料,都找不到一個關於Tunnell
如何查詢oracle會話及鎖 如何查鎖了哪張表?如何殺掉會話
=================================================================================================================== --檢視鎖表: SELECT O.OWNER, O.OBJE
android studio簽名檔案在哪?以及檢視MD5和SHA1資訊
1.簽名檔案在哪: C:\Users\Administrator\.android \debug.keystore 2.怎樣檢視獲取SHA1或者MD5: (1)開啟命令視窗:進入c盤的.android目錄下 (2)輸入命令:k