mysql 5.6 read-committed隔离级别下并发插入唯一索引导致死锁一例

今天,某个环境又发生了死锁,如下:

*** (1) TRANSACTION:
TRANSACTION 735307073, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 6 lock struct(s), heap size 1184, 3 row lock(s), undo log entries 1
MySQL thread id 2754, OS thread handle 0x7f29cd89a700, query id 751744317 127.0.0.1 osm update
insert into tb_trd_secu_command(
machine_date, company_no, product_id,
product_code, product_name, unit_id, unit_code,
unit_name, asset_account, stock_account, command_operator,
command_executor, command_date, command_time, command_id,
batch_no, exchange_no, asset_type, stock_type,
stock_code, stock_name, currency_type, command_dir,
limit_price, command_qty, command_amt, order_qty,
cancel_qty, command_status, execution_status, execution_amt,
execution_qty, frozen_amt)
value(
v_machine_date, v_company_no, v_product_id,
v_product_code, v_product_name, v_unit_id, v_unit_code,
v_unit_name, v_asset_account, v_stock_account, v_command_operator,
v_command_executor, v_command_date, v_command_time, v_command_id,
v_batch_no, v_exchange_no, v_asset_type, v_stock_type,
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 10538 page no 4 n bits 296 index `idx_tb_trd_secu_command_1` of table `db_trd`.`tb_trd_secu_command` trx id 735307073 lock_mode X locks gap before rec insert intention waiting
*** (2) TRANSACTION:
TRANSACTION 735307149, ACTIVE 0 sec inserting, thread declared inside InnoDB 1
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 1
MySQL thread id 2744, OS thread handle 0x7f29cd8db700, query id 751750715 127.0.0.1 osm update
insert into tb_trd_secu_command(
machine_date, company_no, product_id,
product_code, product_name, unit_id, unit_code,
unit_name, asset_account, stock_account, command_operator,
command_executor, command_date, command_time, command_id,
batch_no, exchange_no, asset_type, stock_type,
stock_code, stock_name, currency_type, command_dir,
limit_price, command_qty, command_amt, order_qty,
cancel_qty, command_status, execution_status, execution_amt,
execution_qty, frozen_amt)
value(
v_machine_date, v_company_no, v_product_id,
v_product_code, v_product_name, v_unit_id, v_unit_code,
v_unit_name, v_asset_account, v_stock_account, v_command_operator,
v_command_executor, v_command_date, v_command_time, v_command_id,
v_batch_no, v_exchange_no, v_asset_type, v_stock_type,
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 10538 page no 4 n bits 296 index `idx_tb_trd_secu_command_1` of table `db_trd`.`tb_trd_secu_command` trx id 735307149 lock mode S locks gap before rec
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 10538 page no 4 n bits 296 index `idx_tb_trd_secu_command_1` of table `db_trd`.`tb_trd_secu_command` trx id 735307149 lock_mode X locks gap before rec insert intention waiting
*** WE ROLL BACK TRANSACTION (2)

其中idx_tb_trd_secu_command_1是唯一索引。

看了下参数,当前隔离级别是read-committed,不过参数innodb_locks_unsafe_for_binlog是默认值OFF。

又仔细看了下官方文档, innodb_locks_unsafe_for_binlog和read-committed一方面是一样的,启用后,可以使得InnoDB gap锁最小化,但是在两种场景(外键约束和唯一索引)中,仍然不可避免的存在gap锁。

不管事务管理级别如何设置,只要存在唯一性约束并且可能insert/delete/update同一key值的记录,死锁都将无法100%的避免,只能是概率降低。

时间: 2024-08-07 00:16:47

mysql 5.6 read-committed隔离级别下并发插入唯一索引导致死锁一例的相关文章

Transaction And Lock--READ COMMITTED隔离级别下的"脏读"

在READ UNCOMMITTED事务隔离级别下或使用WITH(NOLOCK)来查询数据时,会出现脏读情况,因此对于一些比较"关键"的业务,会要求不能使用WITH(NOLOCK)或允许在READ UNCOMMITTED事务隔离级别下,于是我们使用默认的READ COMMITTED隔离级别来访问数据,但是这样真的就没有问题么? 让我们来做个小实验 准备测试数据 --======================================= --创建测试表 CREATE TABLE T

MySQL学习总结-演示不同隔离级别下的并发问题

演示不同隔离级别下的并发问题 1.当把事务的隔离级别设置为read uncommitted,会引发脏读.不可重复读和虚读A窗口set transaction isolation level read uncommitted;start transaction;select * from bank;----发现a账户是1000元,转到b窗口select * from bank; B窗口start transaction;update bank set money=money+100 where n

MySQL Transaction--RR事务隔离级别下加锁测试

============================================================================== 按照非索引列更新 在可重复读的事务隔离级别下,在非索引列上进行更新和删除会对所有数据行进行加锁,阻止其他会话对边进行任何数据的增删改操作. 如果更新或删除条件为c3=4且c3列上没有索引则: 1.不允许其他会话插入任意记录,因为所有记录的主键索引上存在X排他锁,无法申请插入意向X锁(lock_mode X insert intention

Read Commited 隔离级别下锁情况(MVCC实现原理)

如何通过单纯加锁实现RC隔离级别的隔离效果? 对InnoDB引擎下的mysql数据库支持行级锁,通过对事务访问时增加排他锁(X锁)可以防止其他事务的访问,只有在该事务锁提交也就是commit后才可以访问,避免脏读产生.但是在多读的场景下,一个事务假如在进行update操作,后面有许多请求都想要单纯进行读操作(普通的SELECT语句),可是因为有锁的存在只能进行等待.该方法在多读的并发环境下效率大大降低. 真实情况下由于InnoDB在RC和RR隔离级别下使用了MVCC机制,实现了一致性非阻塞读,提

浅谈mysql中不同事务隔离级别下数据的显示效果

事务的概念 事 务是一组原子性的SQL查询语句,也可以被看做一个工作单元.如果数据库引擎能够成功地对数据库应用所有的查询语句,它就会执行所有查询,如果任何一条查 询语句因为崩溃或其他原因而无法执行,那么所有的语句就都不会执行.也就是说,事务内的语句要么全部执行,要么一句也不执行. 事务的特性:acid,也称为事务的四个测试(原子性,一致性,隔离性,持久性) automicity:原子性,事务所引起的数据库操作,要么都完成,要么都不执行consisitency:一致性,事务执行前的总和和事务执行后

mysql中不同事务隔离级别下数据的显示效果--转载

事务是一组原子性的SQL查询语句,也可以被看做一个工作单元.如果数据库引擎能够成功地对数据库应用所有的查询语句,它就会执行所有查询,如果任何一条查询语句因为崩溃或其他原因而无法执行,那么所有的语句就都不会执行.也就是说,事务内的语句要么全部执行,要么一句也不执行. 事务的特性:acid,也称为事务的四个测试(原子性,一致性,隔离性,持久性) automicity:原子性,事务所引起的数据库操作,要么都完成,要么都不执行 consisitency:一致性,事务执行前的总和和事务执行后的总和是不变的

mysql 开发进阶篇系列 12 锁问题(隔离级别下锁的差异)

1. innodb在不同隔离级别下的一致性读及锁的差异 不同的隔离级别下,innodb处理sql 时采用的一致性读策略和需要的锁是不同的,同时,数据恢复和复制机制的特点,也对一些sql的一致性读策略和锁策略有很大影响.对于许多sql, 隔离级别越高,innodb给记录集的锁就越严格(龙其是使用范围条件的时候),产生的锁冲突的可能性也就越高,对并发性事务处理性能的影响也就越大.因此,在应用中,应该尽量使用较低的隔离级别,减少锁争用.通常使用Read Commited隔离级别就足够了, 对于一些确实

【mysql】关于事务的隔离级别

一.锁的种类 MySQL中锁的种类很多,有常见的表锁和行锁,也有新加入的Metadata Lock等等,表锁是对一整张表加锁,虽然可分为读锁和写锁,但毕竟是锁住整张表,会导致并发能力下降,一般是做ddl处理时使用. 行锁则是锁住数据行,这种加锁方法比较复杂,但是由于只锁住有限的数据,对于其它数据不加限制,所以并发能力强,MySQL一般都是用行锁来处理并发事务 二.锁粒度 为了尽可能提高数据库的并发度,每次锁定的数据范围越小越好,理论上每次只锁定当前操作的数据的方案会得到最大的并发度,但是管理锁是

MySQL InnoDB中的事务隔离级别和锁的关系

前言: 我们都知道事务的几种性质,数据库为了维护这些性质,尤其是一致性和隔离性,一般使用加锁这种方式.同时数据库又是个高并发的应用,同一时间会有大量的并发访问,如果加锁过度,会极大的降低并发处理能力.所以对于加锁的处理,可以说就是数据库对于事务处理的精髓所在.这里通过分析MySQL中InnoDB引擎的加锁机制,来抛砖引玉,让读者更好的理解,在事务处理中数据库到底做了什么. 一.一次封锁or两段锁因为有大量的并发访问,为了预防死锁,一般应用中推荐使用一次封锁法,就是在方法的开始阶段,已经预先知道会