在上一篇《等待事件統計檢視 | 全方位認識 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儲存引擎，喜好專研開源技術，追求完美。