标签：24 浅谈 lock blocking trx 监控 id select row
1.前言
在Mysql中少不了与各式各样的锁打交道，比如说共享锁与排他锁等等，其中有时我们可能会遇到锁等待的情况，比如说同时开启两个事务对某一行记录进行修改，其中一个事务修改完但是未提交，另一个事务也修改，那么此事它就会遇到锁等待的情况(就是阻塞-->block)
2. show status like 'innodb_row_lock%'
root@localhost 17:19: [liulin]> show status like 'innodb_row_lock%'; +-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+ | Innodb_row_lock_current_waits | 1 | # 当前处于锁等待的个数 | Innodb_row_lock_time | 51068 | #InnoDB 表等待获取行锁的总时间开销，单位毫秒，
| Innodb_row_lock_time_avg | 25534 | | Innodb_row_lock_time_max | 51068 | | Innodb_row_lock_waits | 2 | # 这个表示数据库从启动开始直到现在共发生锁等待的次数(包括目前正在处于锁等待的个数) +-------------------------------+-------+
3. select * from information_schema.innodb_trx where trx_state='lock wait'\G;
root@localhost 20:28: [information_schema]> select * from information_schema.innodb_trx where trx_state='lock wait'\G;
*************************** 1. row ***************************
trx_id: 35182
trx_state: LOCK WAIT
trx_started: 2021-07-31 17:18:11
trx_requested_lock_id: 35182:116:3:11
trx_wait_started: 2021-07-31 20:27:29
trx_weight: 2
trx_mysql_thread_id: 37
trx_query: update t1 set name='liulin1' where id=1
trx_operation_state: starting index read
trx_tables_in_use: 1
trx_tables_locked: 1
trx_lock_structs: 2
trx_lock_memory_bytes: 1136
trx_rows_locked: 4
trx_rows_modified: 0
trx_concurrency_tickets: 0
trx_isolation_level: REPEATABLE READ
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_adaptive_hash_latched: 0
trx_adaptive_hash_timeout: 0
trx_is_read_only: 0
trx_autocommit_non_locking: 0
1 row in set (0.00 sec)
- 这个表示查找处于锁等待的事务的详细信息，通俗的说是它目前想要获取写锁，但是该锁被被的事务提前一步获取且还未释放，因此它想要获取就处于了阻塞状态了(blocked).
- 一般这里我们我们会设置一下锁超时等待时间的，参数为innodb_lock_wait_timeout，默认是50s,表示innoDB 事务请求行锁的超时时间限制参数
- select * from information_schema.innodb_trx ：可以查找出当前数据库中所有未提交的事务
4. select * from sys.innodb_lock_waits; 查看被锁事务和锁源事务的信息
root@localhost 20:48: [sys]> select * from innodb_lock_waits \G;
*************************** 1. row ***************************
wait_started: 2021-07-31 20:48:26
wait_age: 00:00:08
wait_age_secs: 8
locked_table: `liulin`.`t1`
locked_index: PRIMARY
locked_type: RECORD
waiting_trx_id: 35182
waiting_trx_started: 2021-07-31 17:18:11
waiting_trx_age: 03:30:23
waiting_trx_rows_locked: 7
waiting_trx_rows_modified: 0
waiting_pid: 37
waiting_query: update t1 set name='liulin1' where id=1
waiting_lock_id: 35182:116:3:11
waiting_lock_mode: X
blocking_trx_id: 35181
blocking_pid: 36
blocking_query: NULL
blocking_lock_id: 35181:116:3:11
blocking_lock_mode: X
blocking_trx_started: 2021-07-31 17:17:12
blocking_trx_age: 03:31:22
blocking_trx_rows_locked: 1
blocking_trx_rows_modified: 1
sql_kill_blocking_query: KILL QUERY 36
sql_kill_blocking_connection: KILL 36
1 row in set, 3 warnings (0.00 sec)
其中：waiting_trx_id：被锁的事务id waiting_pid :被锁的线程id
blocking_trx_id:锁源的事务id blocking_pid ：表示锁源的线程id
5. select * from performance_schema.threads where processlist_id='xxx'
root@localhost 21:01: [performance_schema]> select * from threads where processlist_id=36\G;
*************************** 1. row ***************************
THREAD_ID: 62
NAME: thread/sql/one_connection
TYPE: FOREGROUND
PROCESSLIST_ID: 36
PROCESSLIST_USER: root
PROCESSLIST_HOST: localhost
PROCESSLIST_DB: liulin
PROCESSLIST_COMMAND: Sleep
PROCESSLIST_TIME: 13441
PROCESSLIST_STATE: NULL
PROCESSLIST_INFO: update t1 set name='liulin1' where id=1
PARENT_THREAD_ID: NULL
ROLE: NULL
INSTRUMENTED: YES
HISTORY: YES
CONNECTION_TYPE: Socket
THREAD_OS_ID: 4548
1 row in set (0.00 sec)
6. select * from performance_schema.events_statements_current where thread_id='xxx';
root@localhost 22:24: [performance_schema]> select * from performance_schema.events_statements_current where thread_id='62'\G;
*************************** 1. row ***************************
THREAD_ID: 62
EVENT_ID: 46
END_EVENT_ID: 46
EVENT_NAME: statement/sql/update
SOURCE:
TIMER_START: 7601338054145000
TIMER_END: 7601339393285000
TIMER_WAIT: 1339140000
LOCK_TIME: 277000000
SQL_TEXT: update t1 set name='liulin1' where id=1
DIGEST: e63566e2378e6dbf044cfe5345a79a9a
DIGEST_TEXT: UPDATE `t1` SET NAME = ? WHERE `id` = ?
CURRENT_SCHEMA: liulin
OBJECT_TYPE: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
OBJECT_INSTANCE_BEGIN: NULL
MYSQL_ERRNO: 0
RETURNED_SQLSTATE: 00000
MESSAGE_TEXT: Rows matched: 1 Changed: 1 Warnings: 0
ERRORS: 0
WARNINGS: 0
ROWS_AFFECTED: 1
ROWS_SENT: 0
ROWS_EXAMINED: 1
CREATED_TMP_DISK_TABLES: 0
CREATED_TMP_TABLES: 0
SELECT_FULL_JOIN: 0
SELECT_FULL_RANGE_JOIN: 0
SELECT_RANGE: 0
SELECT_RANGE_CHECK: 0
SELECT_SCAN: 0
SORT_MERGE_PASSES: 0
SORT_RANGE: 0
SORT_ROWS: 0
SORT_SCAN: 0
NO_INDEX_USED: 0
NO_GOOD_INDEX_USED: 0
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
NESTING_EVENT_LEVEL: 0
1 row in set (0.00 sec)
总结：
show status like 'innodb_row_lock%' ---> select * from information_schema.innodb.trx where trx_state='lock wait' -->
select * from sys.innodb_lock_waits ---> select * from performance_schema.threads where processlist_id='xxx' --->
select * from performance_schema.events_statements_current where thread_id='xxx';
其中，第二个命令如果是只是查看锁等待的事务的详细信息的话，我们可以直接用第三个命令代替，因为第二个命令还可以查看所有状态的事务的详细信息。然后第三个命令也是查看锁源事务和被锁事务的一些详细信息，然后第四个命令可以针对连接线程id查看其内部的Mysql线程id，最后第五个命令最后再根据第四个查到的Mysql内部的线程id查看到该线程id对应的当前线程id中对应的事件。
案例篇：
背景：
硬件环境：DELL R720 , 16核，48G，SAS 900G， RAID10
在巡检的时候发现，在某个时间段的cpu压力非常高
排查和处理过程
1.通过top命令查看，发现Mysqld进程占比非常高
2.用vmstat查看发现大量的CPU是被用作了sys和wait，us处于正常
3,这时怀疑是Mysql的锁或者sql语句出现了问题
4.通过show status like 'innodb_row_lock%'查看有大量的所等待以及通过查看慢日志发现有少量的慢语句
5.其中关于慢日志可以通过pt-query-disget工具进行分析
标签：24,浅谈,lock,blocking,trx,监控,id,select,row 来源： https://www.cnblogs.com/zmc60/p/15085561.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。