MySQL锁等待分析【2】

MySQL锁等待分析【1】中对锁等待的分析是一步一步来的、虽然最后是分析出来了,可是用时是比较长的;理清各个表之间的关系后,得到如下SQL语句,方便以后使用

select
    block_trx.trx_mysql_thread_id as blocking_session_id, -- 已经持有锁的session ID
    request_trx.trx_mysql_thread_id as request_session_id, -- 正在申请锁的session ID
    block_trx.trx_query as blocking_sql_text, -- 已经持有锁的SQL语句
    request_trx.trx_query as requesting_sql_text, -- 正在申请锁的SQL语句
    waits.blocking_trx_id as blocking_trx_id, -- 已经持有锁的事务ID
    waits.requesting_trx_id as requesting_trx_id, -- 正在申请锁的事务ID
    waits.requested_lock_id as requested_lock_id, -- 锁对象的ID
    locks.lock_table as lock_table, -- 锁对象所锁定的表
    locks.lock_type as lock_type, -- 锁类型
    locks.lock_mode as lock_mode -- 锁模式
from information_schema.innodb_lock_waits as waits
inner join information_schema.innodb_trx as block_trx
    on waits.blocking_trx_id=block_trx.trx_id
inner join information_schema.innodb_trx as request_trx
    on waits.requesting_trx_id=request_trx.trx_id
inner join information_schema.innodb_locks as locks
    on waits.requested_lock_id=locks.lock_id;
+---------------------+--------------------+-------------------+-----------------------------------+-----------------+-------------------+-------------------+--------------+-----------+-----------+
| blocking_session_id | request_session_id | blocking_sql_text | requesting_sql_text               | blocking_trx_id | requesting_trx_id | requested_lock_id | lock_table   | lock_type | lock_mode |
+---------------------+--------------------+-------------------+-----------------------------------+-----------------+-------------------+-------------------+--------------+-----------+-----------+
|                1435 |               1255 | NULL              | select * from tempdb.t for update | 26293           | 26299             | 26299:38:3:2      | `tempdb`.`t` | RECORD    | X         |
|                1435 |               1165 | NULL              | insert into t(x) values(3)        | 26293           | 26294             | 26294:38:3:1      | `tempdb`.`t` | RECORD    | X         |
+---------------------+--------------------+-------------------+-----------------------------------+-----------------+-------------------+-------------------+--------------+-----------+-----------+
时间: 2024-08-10 21:27:43

MySQL锁等待分析【2】的相关文章

MySQL - 锁等待超时与information_schema的三个表

引用地址:https://blog.csdn.net/J080624/article/details/80596958 回顾一下生产中的一次MySQL异常,Cause: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction解决与处理. [1]抛个异常 异常如下: Cause: java.sql.SQLException: Lock wait timeout exceeded; try resta

MySQL锁阻塞分析

日常维护中,经常会碰到线程被阻塞,导致数据库响应非常慢,下面就看看如何获取是哪个线程导致了阻塞的. blog地址:http://blog.csdn.net/hw_libo/article/details/39080809 1. 环境说明 RHEL 6.4 x86_64 + MySQL 5.6.19 事务隔离级别:RR 2. 测试过程 3. 查看锁阻塞线程信息 这里用几中方法进行分析: 3.1  使用show processlist查看 MySQL [(none)]> show processli

查询MySQL锁等待的语句

select 'Blocker' role,    p.id,    p.user,    left(p.host, locate(':', p.host) - 1) host,    tx.trx_id,    tx.trx_state,    tx.trx_started, timestampdiff(second, tx.trx_started, now()) duration, lo.lock_mode, lo.lock_type, lo.lock_table, lo.lock_inde

mysql innodb的锁机制分析

线上生产环境在某些时候经常性的出现数据库操作死锁,导致业务人员无法进行操作.经过DBA的分析,是某一张表的insert操作和delete操作发生了死锁.简单介绍下数据库的情况(因为涉及到真实数据,这里做了模拟,不影响具体的分析和分析的结果.)假设存在如下2张表: Order 表的数据如下: Customer表的数据如下: Order和Customer 在实体关系上存在一个关联,即order实体拥有一个指向customer实体的指针.在数据库设计的时候,order表的customer_id没有被设

**MySQL锁机制与用法分析**

原文:https://www.jb51.net/article/139113.htm MySQL的锁机制比较简单,其最显著的特点是不同的存储引擎支持不同的锁机制.比如,MyISAM和MEMORY存储引擎采用的是表级锁:BDB存储引擎采用的是页面锁,但也支持表级锁:InnoDB存储引擎既支持行级锁,也支持表级锁,但默认情况下采用行级锁. MySQL这3种锁的特性可大致归纳如下: (1)表级锁:开销小,加锁快:不会出现死锁:锁定粒度大,发生锁冲突的概率最高,并发度最低. (2)行级锁:开销大,加锁慢

mysql外键引发的锁等待

有这样两条sql: insert table_a (bId) value(1); -- sql-1  update table_b set b.xx=123 where b.id =1; -- sql-2 其中,table_a的字段bId是个外键:外键关联的正是table_b的id字段. 在mysql上执行这两条数据时,sql-1会锁住sql-2.我们的系统中,为这一个锁,发生了不知道多少的锁等待,更引发了不知道多少的死锁. 特此备忘.

排查MySQL事务没有提交导致 锁等待 Lock wait timeout exceeded

解决思路: select * from information_schema.innodb_trx 之后找到了一个一直没有提交的只读事务, kill 到了对应的线程后ok 了. 转载自:http://blog.sina.com.cn/s/blog_6bb63c9e0100s7cb.html 在Mysql5.5中,information_schema 库中增加了三个关于锁的表(MEMORY引擎): innodb_trx ## 当前运行的所有事务 innodb_locks ## 当前出现的锁 inn

mysql 开发进阶篇系列 13 锁问题(关于表锁,死锁示例,锁等待设置)

一. 什么时候使用表锁 对于INNODB表,在绝大部分情况下都应该使用行锁.在个别特殊事务中,可以考虑使用表锁(建议). 1. 事务需要更新大部份或全部数据,表又比较大,默认的行锁不仅使这个事务执行效率低,可能造成其他事务长时间锁等待和锁冲突,这种情况考虑使用表锁来提高事务的执行速度(具我在sql server中的经历,该大表有上100w,删除40w,表锁有时会造成长时间未执行完成. 还是使用分批来执行好). 2. 事务涉及多个表,比较复杂,很可能引起死锁,造成大量事务回滚.这种情况可以考虑一次

MySQL备份,使用xtrabackup备份全实例数据时,会造成锁等待吗?那么如果使用mysqldump进行备份呢?

一.xtrabackup和mysqldump会造成锁等待吗? xtrabackup会,它在备份时会产生短暂的全局读锁FTWL(flush table with read lock),用于拷贝frm/MYD/MYI等文件,以及记录binlog信息.如果MyISAM表的数据量非常大,则拷贝时间就越长,加锁的时间也越长 mysqldump有可能会.如果只是添加 --single-transacton 选项用于保证备份数据一致性,这时就不会产生FTWL锁了.但通常我们为了让备份文件和binlog保持一致