如何查mysql死锁进程

Posted 2023-05-09

　　查询死锁进程

　　采用如下存储过程来查询数据中当前造成死锁的进程。
drop procedure sp_who_lock
go
CREATE procedure sp_who_lock
as
begin
declare @spid int
declare @blk int
declare @count int
declare @index int
declare @lock tinyint
set @lock=0
create table #temp_who_lock
(
id int identity(1,1),
spid int,
blk int
)
if @@error<>0 return @@error
insert into #temp_who_lock(spid,blk)
select 0 ,blocked
from (select * from master..sysprocesses where blocked>0)a
where not exists(select * from master..sysprocesses where a.blocked =spid and blocked>0)
union select spid,blocked from master..sysprocesses where blocked>0
if @@error<>0 return @@error
select @count=count(*),@index=1 from #temp_who_lock
if @@error<>0 return @@error
if @count=0
begin
select '没有阻塞和死锁信息'
return 0
end
while @index<<A href="mailto:=@count">=@count
begin
if exists(select 1 from #temp_who_lock a where id>@index and exists(select 1 from #temp_who_lock where id<<A href="mailto:=@index">=@index and a.blk=spid))
begin
set @lock=1
select @spid=spid,@blk=blk from #temp_who_lock where id=@index
select '引起数据库死锁的是: '+ CAST(@spid AS VARCHAR(10)) + '进程号,其执行的SQL语法如下'
select @spid, @blk
dbcc inputbuffer(@spid)
dbcc inputbuffer(@blk)
end
set @index=@index+1
end
if @lock=0
begin
set @index=1
while @index<<A href="mailto:=@count">=@count
begin
select @spid=spid,@blk=blk from #temp_who_lock where id=@index
if @spid=0
select '引起阻塞的是:'+cast(@blk as varchar(10))+ '进程号,其执行的SQL语法如下'
else
select '进程号SPID：'+ CAST(@spid AS VARCHAR(10))+ '被' + '进程号SPID：'+ CAST(@blk AS VARCHAR(10)) +'阻塞,其当前进程执行的SQL语法如下'
　　
dbcc inputbuffer(@spid)
dbcc inputbuffer(@blk)
set @index=@index+1
end
end
drop table #temp_who_lock
return 0
end

GO
--执行该存储过程
exec sp_who_lock

　　补充：
　　一、产生死锁的原因
在SQL Server中，阻塞更多的是产生于实现并发之间的隔离性。为了使得并发连接所做的操作之间的影响到达某一期望值而对资源人为的进行加锁(锁本质其实可以看作是一个标志位)。当一个连接对特定的资源进行操作时，另一个连接同时对同样的资源进行操作就会被阻塞，阻塞是死锁产生的必要条件。
　　
　　二、如何避免死锁
1.使用事务时，尽量缩短事务的逻辑处理过程，及早提交或回滚事务；
2.设置死锁超时参数为合理范围，如：3分钟-10分种；超过时间，自动放弃本次操作，避免进程悬挂；
3.优化程序，检查并避免死锁现象出现；
4.对所有的脚本和SP都要仔细测试，在正是版本之前；
5.所有的SP都要有错误处理（通过@error）；
6.一般不要修改SQL SERVER事务的默认级别。不推荐强行加锁。
　　

　　三、处理死锁
　　1、最简单的处理死锁的方法就是重启服务。
　　
　　2、根据指定的死锁进程ID进行处理
根据第二步查询到的死锁进行，大致分析造成死锁的原因，并通过如下语句释放该死锁进程
kill pid --pid为查询出来的死锁进程号
　　
　　3、通过存储过程杀掉某个库下面的所有死锁进程和锁
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[sp_killspid]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [dbo].[sp_killspid]
GO

create proc sp_killspid
@dbname varchar(200) --要关闭进程的数据库名
as
declare @sql nvarchar(500)
declare @spid nvarchar(20)

declare #tb cursor for
select spid=cast(spid as varchar(20)) from master..sysprocesses where dbid=db_id(@dbname)
open #tb
fetch next from #tb into @spid
while @@fetch_status=0
begin
exec('kill '+@spid)
fetch next from #tb into @spid
end
close #tb
deallocate #tb
go

--使用方法，“db_name”为处理的数据库名称
exec sp_killspid 'db_name' 参考技术A

加锁情况与死锁原因分析

为方便大家复现，完整表结构和数据如下：

CREATE TABLE `t3` (`c1` int(11) NOT NULL AUTO_INCREMENT,`c2` int(11) DEFAULT NULL,PRIMARY KEY (`c1`),UNIQUE KEY `c2` (`c2`)) ENGINE=InnoDBinsert into t3 values(1,1),(15,15),(20,20);

在 session1 执行 commit 的瞬间，我们会看到 session2、session3 的其中一个报死锁。这个死锁是这样产生的：

1. session1 执行 delete  会在唯一索引 c2 的 c2 = 15 这一记录上加 X lock（也就是在mysql 内部观测到的：X Lock but not gap）；

2. session2 和 session3 在执行 insert 的时候，由于唯一约束检测发生唯一冲突，会加 S Next-Key Lock，即对 (1,15] 这个区间加锁包括间隙，并且被 seesion1 的 X Lock 阻塞，进入等待；

3. session1 在执行 commit 后，会释放 X Lock，session2 和 session3 都获得 S Next-Key Lock；

4. session2 和 session3 继续执行插入操作，这个时候 INSERT INTENTION LOCK（插入意向锁）出现了，并且由于插入意向锁会被 gap 锁阻塞，所以 session2 和 session3 互相等待，造成死锁。

死锁日志如下： 

INSERT INTENTION LOCK

在之前的死锁分析第四点，如果不分析插入意向锁，也是会造成死锁的，因为插入最终还是要对记录加 X Lock 的，session2 和 session3 还是会互相阻塞互相等待。

但是插入意向锁是客观存在的，我们可以在官方手册中查到，不可忽略：

Prior to inserting the row, a type of gap lock called an insert intention gap lock is set. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap.

插入意向锁其实是一种特殊的 gap lock，但是它不会阻塞其他锁。假设存在值为 4 和 7 的索引记录，尝试插入值 5 和 6 的两个事务在获取插入行上的排它锁之前使用插入意向锁锁定间隙，即在（4，7）上加 gap lock，但是这两个事务不会互相冲突等待。

当插入一条记录时，会去检查当前插入位置的下一条记录上是否存在锁对象，如果下一条记录上存在锁对象，就需要判断该锁对象是否锁住了 gap。如果 gap 被锁住了，则插入意向锁与之冲突，进入等待状态（插入意向锁之间并不互斥）。总结一下这把锁的属性：

1. 它不会阻塞其他任何锁；

2. 它本身仅会被 gap lock 阻塞。

在学习 MySQL 过程中，一般只有在它被阻塞的时候才能观察到，所以这也是它常常被忽略的原因吧...

GAP LOCK

在此例中，另外一个重要的点就是 gap lock，通常情况下我们说到 gap lock 都只会联想到 REPEATABLE-READ 隔离级别利用其解决幻读。但实际上在 READ-COMMITTED 隔离级别，也会存在 gap lock ，只发生在：唯一约束检查到有唯一冲突的时候，会加 S Next-key Lock，即对记录以及与和上一条记录之间的间隙加共享锁。

通过下面这个例子就能验证：

这里 session1 插入数据遇到唯一冲突，虽然报错，但是对 (15,20] 加的 S Next-Key Lock 并不会马上释放，所以 session2 被阻塞。另外一种情况就是本文开始的例子，当 session2 插入遇到唯一冲突但是因为被 X Lock 阻塞，并不会立刻报错 “Duplicate key”，但是依然要等待获取 S Next-Key Lock 。

有个困惑很久的疑问：出现唯一冲突需要加 S Next-Key Lock 是事实，但是加锁的意义是什么？还是说是通过 S Next-Key Lock 来实现的唯一约束检查，但是这样意味着在插入没有遇到唯一冲突的时候，这个锁会立刻释放，这不符合二阶段锁原则。这点希望能与大家一起讨论得到好的解释。

如果是在 REPEATABLE-READ，除以上所说的唯一约束冲突外，gap lock 的存在是这样的：

普通索引（非唯一索引）的S/X Lock，都带 gap 属性，会锁住记录以及前1条记录到后1条记录的左闭右开区间，比如有[4,6,8]记录，delete 6，则会锁住[4,8）整个区间。

对于 gap lock，相信 DBA 们的心情是一样一样的，所以我的建议是：

1. 在绝大部分的业务场景下，都可以把 MySQL 的隔离界别设置为 READ-COMMITTED；

2. 在业务方便控制字段值唯一的情况下，尽量减少表中唯一索引的数量。

锁冲突矩阵

前面我们说的 GAP LOCK 其实是锁的属性，另外我们知道 InnoDB 常规锁模式有：S 和 X，即共享锁和排他锁。锁模式和锁属性是可以随意组合的，组合之后的冲突矩阵如下，这对我们分析死锁很有帮助。

参考技术B 直接通过workbench来查看吧，管理里面可以直观的看到当前连接状态的本回答被提问者和网友采纳

MySql 死锁

MySql 死锁

• 一、什么是死锁
• • InnoDB存储引擎定义了四种类型的行锁
  • 隔离等级对加锁的影响
  • 当前数据对加锁的影响
• 二、为什么会形成死锁
• • 两阶段锁协议
  • 产生死锁的四个必要条件
• 三、MySQL 如何处理死锁？
• • 杀死进程
  • MySQL表
  • 间隙锁
  • 排他锁
  • 共享锁
  • 分析行锁定
  • 行锁优化
• 四、如何避免发生死锁
• • 1.对索引加锁顺序的不一致很可能会导致死锁；
  • 2.Gap 锁往往是程序中导致死锁的真凶；
  • 3.为表添加合理的索引，如果不走索引将会为表的每一行记录加锁，死锁的概率就会大大增大；
  • 4.我们知道 MyISAM 只支持表锁，它采用一次封锁技术来保证事务之间不会发生死锁，所以，我们也可以使用同样的思想，在事务中一次锁定所需要的所有资源，减少死锁概率；
  • 5.避免大事务；
  • 6.避免在同一时间点运行多个对同一表进行读写的脚本；
  • 7.设置锁等待超时参数：innodb_lock_wait_timeout；
• 五、死锁的影响
• 六、如何发现死锁
• • 1.查询数据库进程
  • 2.查看当前的事务
  • 3.查看当前锁定的事务
  • 4.查看当前等锁的事务
• MySQL事务 autocommit 自动提交
• • 查看当前autocommit模式
  • 禁止使用当前会话的自动提交
  • Mysql 查询正在执行的事务以及等待锁的操作方式
  • • 查看正在执行的事务
  • 查看正在锁的事务
  • 查看等待锁的事务
  • 查询mysql数据库中存在的进程
• MySQL命令
• • show engines;查看数据库存储引擎
  • MYSQL 事务处理主要有两种方法：
  • 查看当前线程处理情况
  • 通过navicat中的【工具】=> 【服务器监控】进行查看结果如下
  • 记录死锁日志
  • 开启mysql慢查询和死锁日志
  • • 显示慢查询状态及日志目录
    • 开启慢查询(说明: 1开启;0关闭;)
    • 显示慢查询阈值(单位秒)，默认执行时间超过10s才会被记录到日志
    • 设置慢查询阈值 (注意:设置后需要重新打开mysql客户端才能到最新的值)
    • 查看死锁的日志是否开启
    • 开启记录死锁
    • InnoDB 行锁等待超时时间(默认为50秒)
    • 获取死锁日志信息
    • 日志中常见关键字样
    • 设置mysql 事务锁超时时间 innodb_lock_wait_timeout
• 共享锁、排他锁与意向锁
• MySQL事务查看
• • 1，查看数据库的隔离级别：
  • 2，去查看先当前库的线程情况：
  • 3，kill掉，线程ID;
  • 4，MySQL锁简写名称

一、什么是死锁

官方定义如下：两个事务都持有对方需要的锁，并且在等待对方释放，并且双方都不会释放自己的锁。

这个就好比你有一个人质，对方有一个人质，你们俩去谈判说换人。你让对面放人，对面让你放人。

共享锁（S Lock）：允许事务读取一行数据，多个事务可以拿到一把S锁（即读读并行）；

排他锁（X Lock）：允许事务删除或更新一行数据，多个事务有且只有一个事务可以拿到X锁（即写写/写读互斥）；

记录锁（LOCK_REC_NOT_GAP）: lock_mode X locks rec but not gap

间隙锁（LOCK_GAP）: lock_mode X locks gap before rec

Next-key 锁（LOCK_ORNIDARY）: lock_mode X
Next-key锁是记录锁和间隙锁的组合，它指的是加在某条记录以及这条记录前面间隙上的锁。

插入意向锁（LOCK_INSERT_INTENTION）: lock_mode X locks gap before rec insert intention

InnoDB存储引擎定义了四种类型的行锁

• LOCK_ORDINARY：Next-Key 锁，锁一条记录及其之前的间隙，这是 RR 隔离级别用的最多的锁，从名字也能看出来；lock_mode X

• LOCK_GAP：间隙锁，锁两个记录之间的 GAP，防止记录插入；lock_mode X locks gap before rec

• LOCK_REC_NOT_GAP：记录锁 只锁记录；lock_mode X locks rec but not gap

• LOCK_INSERT_INTENSION：插入意向锁，插入意向 GAP 锁，插入记录时使用，是 LOCK_GAP 的一种特例。lock_mode X locks gap before rec insert intention

隔离等级对加锁的影响

隔离级别	读数据一致性	脏读	不可重复读	幻读
未提交读（Read uncommitted）	最低级别，只能保证不读取物理上损坏的数据，事务可以看到其他事务没有被提交的数据（脏数据）	是	是	是
已提交度（Read committed）	语句级，事务可以看到其他事务已经提交的数据	否	是	是
可重复读（Repeatable read）	事务级，事务中两次查询的结果相同	否	否	是
可序列化（Serializable）	串行	否	否	否

这里说明一下，RC 总是读取记录的最新版本，而 RR 是读取该记录事务开始时的那个版本，虽然这两种读取的版本不同，但是都是快照数据，并不会被写操作阻塞，所以这种读操作称为 快照读（Snapshot Read）

MySQL 还提供了另一种读取方式叫当前读（Current Read），它读的不再是数据的快照版本，而是数据的最新版本，并会对数据加锁，根据语句和加锁的不同，又分成三种情况：

• SELECT … LOCK IN SHARE MODE：加共享(S)锁
• SELECT … FOR UPDATE：加排他(X)锁
• INSERT / UPDATE / DELETE：加排他(X)锁

当前读在 RR 和 RC 两种隔离级别下的实现也是不一样的：RC 只加记录锁，RR 除了加记录锁，还会加间隙锁，用于解决幻读问题。

当前数据对加锁的影响

比如一条最简单的根据主键进行更新的 SQL 语句，如果主键存在，则只需要对其加记录锁，如果不存在，则需要在加间隙锁。

二、为什么会形成死锁

看到这里，也许你会有这样的疑问，事务和谈判不一样，为什么事务不能使用完锁之后立马释放呢？

居然还要操作完了之后一直持有锁？

这就涉及到 MySQL 的并发控制了。

MySQL的并发控制有两种方式，一个是 MVCC，一个是两阶段锁协议。

那么为什么要并发控制呢？

是因为多个用户同时操作 MySQL 的时候，为了提高并发性能并且要求如同多个用户的请求过来之后如同串行执行的一样（可串行化调度）。

两阶段锁协议

官方定义：

两阶段锁协议是指所有事务必须分两个阶段对数据加锁和解锁，在对任何数据进行读、写操作之前，事务首先要获得对该数据的封锁；

在释放一个封锁之后，事务不再申请和获得任何其他封锁。

对应到 MySQL 上分为两个阶段：

• 扩展阶段（事务开始后，commit 之前）：获取锁
• 收缩阶段（commit 之后）：释放锁

就是说呢，只有遵循两段锁协议，才能实现 可串行化调度。

但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁，并且在加锁阶段没有顺序要求，所以这种并发控制方式会形成死锁。

产生死锁的四个必要条件

（1） 互斥条件：一个资源每次只能被一个进程使用。
（2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
（3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

三、MySQL 如何处理死锁？

MySQL有两种死锁处理方式：

• 等待，直到超时（innodb_lock_wait_timeout=50s）。
• 发起死锁检测，主动回滚一条事务，让其他事务继续执行（innodb_deadlock_detect=on）。

由于性能原因，一般都是使用死锁检测来进行处理死锁。

死锁检测

死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁。

回滚

检测到死锁之后，选择插入更新或者删除的行数最少的事务回滚，INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断。

杀死进程

通过以上方法一可以查询对应死锁的数据库进程,可以直接杀掉。

kill 进程ID

下列方法有助于最大限度地降低死锁：

（1）按同一顺序访问对象。
（2）避免事务中的用户交互。
（3）保持事务简短并在一个批处理中。
（4）使用低隔离级别。
（5）使用绑定连接。

MySQL表

CREATE TABLE `book` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `isbn` varchar(255) DEFAULT '',
  `author` varchar(255) DEFAULT '',
  `score` decimal(11,2) DEFAULT '0.00',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `mysqldemo`.`book` (`id`, `isbn`, `author`, `score`) VALUES ('10', 'N001', 'Bob', '9.20');
INSERT INTO `mysqldemo`.`book` (`id`, `isbn`, `author`, `score`) VALUES ('18', 'N002', 'ABob', '7.70');
INSERT INTO `mysqldemo`.`book` (`id`, `isbn`, `author`, `score`) VALUES ('25', 'N003', 'CBob', '7.80');
INSERT INTO `mysqldemo`.`book` (`id`, `isbn`, `author`, `score`) VALUES ('30', 'N004', 'DBob', '9.70');
INSERT INTO `mysqldemo`.`book` (`id`, `isbn`, `author`, `score`) VALUES ('41', 'N005', 'EBob', '3.70');
INSERT INTO `mysqldemo`.`book` (`id`, `isbn`, `author`, `score`) VALUES ('45', 'N006', 'F5Bob', '6.70');
INSERT INTO `mysqldemo`.`book` (`id`, `isbn`, `author`, `score`) VALUES ('49', 'N006', 'willem', '6.70');
INSERT INTO `mysqldemo`.`book` (`id`, `isbn`, `author`, `score`) VALUES ('60', 'N007', 'willem', '8.70');

间隙锁

当我们用范围条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；

对于键值在条件范围内但并不存在的记录，叫做”间隙(GAP)”。

InnoDB也会对这个”间隙”加锁，这种锁机制就是所谓的间隙锁(Next-Key锁)。

危害(坑)：若执行的条件是范围过大，则InnoDB会将整个范围内所有的索引键值全部锁定，很容易对性能造成影响。

排他锁

排他锁，也称写锁，独占锁，当前写操作没有完成前，它会阻断其他写锁和读锁。

共享锁

共享锁，也称读锁，多用于判断数据是否存在，多个读操作可以同时进行而不会互相影响。当如果事务对读锁进行修改操作，很可能会造成死锁。如下图所示。

分析行锁定

mysql> show status like 'innodb_row_lock%';
+-------------------------------+--------+
| Variable_name                 | Value  |
+-------------------------------+--------+
| Innodb_row_lock_current_waits | 0      |
| Innodb_row_lock_time          | 536668 |
| Innodb_row_lock_time_avg      | 44722  |
| Innodb_row_lock_time_max      | 51085  |
| Innodb_row_lock_waits         | 12     |
+-------------------------------+--------+
5 rows in set (0.00 sec)

• innodb_row_lock_current_waits: 当前正在等待锁定的数量

• innodb_row_lock_time: 从系统启动到现在锁定总时间长度；非常重要的参数，

• innodb_row_lock_time_avg: 每次等待所花平均时间；非常重要的参数，

• innodb_row_lock_time_max: 从系统启动到现在等待最常的一次所花的时间；

• innodb_row_lock_waits: 系统启动后到现在总共等待的次数；非常重要的参数。直接决定优化的方向和策略。

行锁优化

1 尽可能让所有数据检索都通过索引来完成，避免无索引行或索引失效导致行锁升级为表锁。

2 尽可能避免间隙锁带来的性能下降，减少或使用合理的检索范围。

3 尽可能减少事务的粒度，比如控制事务大小，而从减少锁定资源量和时间长度，从而减少锁的竞争等，提供性能。

4 尽可能低级别事务隔离，隔离级别越高，并发的处理能力越低。

四、如何避免发生死锁

对于 MySQL 的 InnoDb 存储引擎来说，死锁问题是避免不了的，没有哪种解决方案可以说完全解决死锁问题，但是我们可以通过一些可控的手段，降低出现死锁的概率。

收集死锁信息：

利用命令 SHOW ENGINE INNODB STATUS查看死锁原因。
调试阶段开启innodb_print_all_deadlocks，收集所有死锁日志。

1.对索引加锁顺序的不一致很可能会导致死锁；

所以如果可以，尽量以相同的顺序来访问索引记录和表。在程序以批量方式处理数据的时候，如果事先对数据排序，保证每个线程按固定的顺序来处理记录，也可以大大降低出现死锁的可能；

2.Gap 锁往往是程序中导致死锁的真凶；

由于默认情况下 MySQL 的隔离级别是 RR，所以如果能确定幻读和不可重复读对应用的影响不大，可以考虑将隔离级别改成 RC，可以避免 Gap 锁导致的死锁；

3.为表添加合理的索引，如果不走索引将会为表的每一行记录加锁，死锁的概率就会大大增大；

4.我们知道 MyISAM 只支持表锁，它采用一次封锁技术来保证事务之间不会发生死锁，所以，我们也可以使用同样的思想，在事务中一次锁定所需要的所有资源，减少死锁概率；

5.避免大事务；

尽量将大事务拆成多个小事务来处理；因为大事务占用资源多，耗时长，与其他事务冲突的概率也会变高；

6.避免在同一时间点运行多个对同一表进行读写的脚本；

特别注意加锁且操作数据量比较大的语句；我们经常会有一些定时脚本，应该避免它们在同一时间点运行；

7.设置锁等待超时参数：innodb_lock_wait_timeout；

这个参数并不是只用来解决死锁问题，在并发访问比较高的情况下，如果大量事务因无法立即获得所需的锁而挂起，会占用大量计算机资源，造成严重性能问题，甚至拖跨数据库。我们通过设置合适的锁等待超时阈值，可以避免这种情况发生。

五、死锁的影响

当产生某表死锁的一开始,所有涉及这张表的操作都将受到阻塞。

假设这张表在业务逻辑上是读写频繁的，那就会使很多操作在那里排队等待，而排队等待会占用数据库连接，当该达到该数据库连接数的最大承载数之后，就会使所有数据库操作均无法再继续下去。

致使数据库各项指标异常，导致整个环境崩溃。在生产环境中出现这种问题，那是相当致命的，当发现数据库指标异常时因快速处理！

六、如何发现死锁

1.查询数据库进程

主要看State字段,如果出现大量 waiting for …lock 即可判定死锁：

SHOW FULL PROCESSLIST;

注意：需要拥有root组权限（supper），否则只能看到当前用户的进程，无法查询所有。

2.查看当前的事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

3.查看当前锁定的事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

4.查看当前等锁的事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

MySQL事务 autocommit 自动提交

MySQL默认操作模式就是autocommit自动提交模式。

我们可以通过设置autocommit的值改变是否是自动提交autocommit模式。

查看当前autocommit模式

show variables like 'autocommit';

从查询结果中，我们发现Value的值是ON，表示autocommit开启。

当 autocommit 为开启状态时，即使没有手动 start transaction 开启事务，mysql默认也会将用户的操作当做事务即时提交。

例如，你执行了insert into test values(2)语句，mysql默认会帮你开启事务，并且在这条插入语句执行完成之后，默认帮你提交事务。

这时候可能有人会问了，那如果我手动开启了事务呢？

例如如下操作，开启事务并插入两条数据：

由于A客户端没有提交，因此如果我们用B客户端去查询数据，会发现新插入的数据并没有被查询到：

从上述的操作中我们可以明白，当autocommit为ON的情况下，并且又手动开启了事务，那么mysql会把start transaction 与 commit之间的语句当做一次事务来处理，默认并不会帮用户提交需要手动提交，如果用户不提交便退出了，那么事务将回滚。

禁止使用当前会话的自动提交

Mysql 查询正在执行的事务以及等待锁的操作方式

使用navicat测试学习:
首先使用 set autocommit = 0;(取消自动提交,则当执行语句commit或者rollback执行提交事务或者回滚)

mysql> show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | OFF   |
+---------------+-------+
1 row in set (0.00 sec)

mysql> UPDATE `mysqldemo`.`user` SET `id`='14', `sex`='0', `age`='28', `province`='北京' WHERE (`id`='14');
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1  Changed: 0  Warnings: 0

查看正在执行的事务

SELECT * FROM information_schema.INNODB_TRX;

在打开一个执行update


根据这个事务的线程ID（trx_mysql_thread_id）:

可以使用mysql命令：kill 线程id 杀掉线程

期间如果并未杀掉持有锁的线程：则第二个update语句提示等待锁超时

查看正在锁的事务

查看等待锁的事务

查询mysql数据库中存在的进程

MySQL命令

show engines;查看数据库存储引擎

SHOW ENGINES显示有关服务器的存储引擎的状态信息。这对于检查是否支持存储引擎或参见默认引擎特别有用。

默认InnoDB

mysql> show engines;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)

MYSQL 事务处理主要有两种方法：

在 MySQL 命令行的默认设置下，事务都是自动提交的，即执行 SQL 语句后就会马上执行 COMMIT 操作。因此要显式地开启一个事务务须使用命令 BEGIN 或 START TRANSACTION，或者执行命令 SET AUTOCOMMIT=0，用来禁止使用当前会话的自动提交。

1、用 BEGIN, ROLLBACK, COMMIT来实现

• BEGIN 开始一个事务
• ROLLBACK 事务回滚
• COMMIT 事务确认

2、直接用 SET 来改变 MySQL 的自动提交模式:

• SET AUTOCOMMIT=0 禁止自动提交
• SET AUTOCOMMIT=1 开启自动提交

mysql> use RUNOOB;
Database changed
mysql> CREATE TABLE runoob_transaction_test( id int(5)) engine=innodb;  # 创建数据表
Query OK, 0 rows affected (0.04 sec)
 
mysql> select * from runoob_transaction_test;
Empty set (0.01 sec)
 
mysql> begin;  # 开始事务
Query OK, 0 rows affected (0.00 sec)
 
mysql> insert into runoob_transaction_test value(5);
Query OK, 1 rows affected (0.01 sec)
 
mysql> insert into runoob_transaction_test value(6);
Query OK, 1 rows affected (0.00 sec)
 
mysql> commit; # 提交事务
Query OK, 0 rows affected (0.01 sec)
---------------------------------------------------------------------------------
mysql>  select * from runoob_transaction_test;
+------+
| id   |
+------+
| 5    |
| 6    |
+------+
2 rows in set (0.01 sec)
 
mysql> begin;    # 开始事务
Query OK, 0 rows affected (0.00 sec)
 
mysql>  insert into runoob_transaction_test values(7);
Query OK, 1 rows affected (0.00 sec)
 
mysql> rollback;   # 回滚
Query OK, 0 rows affected (0.00 sec)
 
mysql>   select * from runoob_transaction_test;   # 因为回滚所以数据没有插入
+------+
| id   |
+------+
| 5    |
| 6    |
+------+
2 rows in set (0.01 sec)
 
mysql>

查看当前线程处理情况

SHOW FULL PROCESSLIST;

show full processlist 返回的结果是实时变化的，是对mysql链接执行的现场快照，所以用来处理突发事件非常有用。

一般用到 show processlist 或 show full processlist 都是为了查看当前 mysql 是否有压力，都在跑什么语句，当前语句耗时多久了，有没有什么慢 SQL 正在执行之类的。

通过navicat中的【工具】=> 【服务器监控】进行查看结果如下

下面针对每列做下介绍：

Id：链接mysql 服务器线程的唯一标识，可以通过kill来终止此线程的链接。

User：当前线程链接数据库的用户

Host：显示这个语句是从哪个ip 的哪个端口上发出的。可用来追踪出问题语句的用户

db: 线程链接的数据库，如果没有则为null

Command: 显示当前连接的执行的命令，一般就是休眠或空闲（sleep），查询（query），连接（connect）

Time: 线程处在当前状态的时间，单位是秒

State：显示使用当前连接的sql语句的状态，很重要的列，后续会有所有的状态的描述，请注意，state只是语句执行中的某一个状态，一个 sql语句，已查询为例，可能需要经过copying to tmp table，Sorting result，Sending data等状态才可以完成

Info: 线程执行的sql语句，如果没有语句执行则为null。这个语句可以使客户端发来的执行语句也可以是内部执行的语句。
如何杀死oracle死锁进程

mysql 死锁:如何解决mysql死锁

mysql -- 死锁

mysql 查询导致卡死

事务 ( 进程 ID 60) 与另一个进程被死锁在锁资源上，并且已被选作死锁牺牲品。请重新运行 该事务。

MySql 死锁