我不明白两个重复查询,每个查询使用主键删除单个表上的一行,怎么会死锁。有谁能解释一下吗?
在我看来,其中一个事务应该获得锁,而另一个事务则必须等待。
以下是死锁报告,以及查询:
Fri Jun 01 2012 13:50:23
*** (1) TRANSACTION:
TRANSACTION 3 1439005348, ACTIVE 0 sec, process no 22419, OS thread id 1166235968 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), hea
首先,一些必要的背景(请,请容忍我)。我是一个web应用程序的开发人员,为了坚持,我使用MySQL。我们通过为每个数据表创建一个审计跟踪表来实现审计日志记录。例如,我们可能对客户实体有以下表定义:
-- Data table definition.
CREATE TABLE my_database.customers (
CustomerId INT(11) NOT NULL AUTO_INCREMENT PRIMARY KEY,
FirstName VARCHAR(255) NOT NULL,
LastName VARCHAR(255) NOT NULL,
-- More d
我在MySQL中有一个触发器:
CREATE DEFINER = CURRENT_USER TRIGGER `test`.`view_AFTER_INSERT` AFTER INSERT ON `views` FOR EACH ROW
BEGIN
UPDATE metrics SET met_nu_vie = met_nu_vie + 1 WHERE usp_id = NEW.usp_id;
END
基本上,当用户从web应用程序中的另一个用户接收到“视图”时,系统在表“视图”中创建一个新行,在插入后,在另一个表(度量)中增加一个计数器值。
我的问题是:如果用户收到来自10个不同用户的1
在视图中的transaction.atomic()中有一个代码块。我的问题是django是否在幕后创建了一些内置的表锁定。
with transaction.atomic():
#code block that does database operations
update_user() #this updates user table
create_customer_products() #this updates user id to customer products table
原因是我在运行代码块时出现了“锁定等待超时;尝试重新启动事务”错误。
设置是cent
根据,更新锁可以在需要写入的时候转换为独占锁。同时,三个锁(X、S和U)的兼容性可以参考下表。
X S U
X ✗ ✗ ✗
S ✗ ✓ ✓
U ✗ ✓ ✗
然而,在一些博客中提到,从MySQL 5.7开始就有一个SX锁,它实现了B-树上操作的文件并发(1977)中的一个思想。通过这些博客,我发现SX锁与update锁非常相似。例如,它们具有相同的兼容性表。
由于我找不到更多关于MySQL中SX锁的“正式”介绍,所以我想问这两种锁之间有什么区别?
我已经阅读并测试了MySQL的InnoDB中的行级锁,但我仍然很难说“我知道锁在MySQL中是如何工作的”!
以下是我的测试数据:
mysql> select * from lockable;
+----+----+----+
| id | c1 | c2 |
+----+----+----+
| 1 | A | A |
| 2 | A | B |
| 3 | A | C |
| 4 | B | A |
| 5 | B | B |
| 6 | B | C |
| 7 | C | A |
| 8 | C | B |
| 9 | C | C
我发现了一个非常混乱的死锁情况,我需要帮助才能理解。
有两个事务正在进行:
(2)持有查询delete from myTable where id = NAME_CONST('p_id',10000)的锁。这是一个按主键锁定,虽然不是完整的键,而是一个范围。当它显示为lock_mode X locks rec but not gap时,它看起来对我来说是一个完整的写锁。
(1)正在等待这个相同的锁,也等待查询delete from myTable where id = NAME_CONST('p_id',10000)。
(2)也在尝试获取此锁,MySQL检测到死
我在存储过程中使用UPDLOCK和READPAST sql提示,以便实现一种表队列(之所以说排序,是因为我选择top 1500而不是top 1,并且在选择行之后不会删除它们。有关更多细节,请参阅问题)。
我用一个简单的小表做了一些测试,一切似乎都很好-- SP的第二次调用不会等待第一次调用结束,只需跳过第一次调用锁定的行,然后返回下一次调用。在我真正的桌子上,虽然,它只是偶尔有效...其他时候,第二个调用挂起并等待第一个调用结束。这是因为第一个调用锁定了整个表,而不仅仅是一些行。
以下是测试表和真实表的SP:
Real表:
declare @temp as table (ID int prim
这里有一个mysql inno_bd表、t主键id和三个字段上的多个btree索引。字段A、B、C分别属于int、int、Date:
问题在于:有一个存档的t_archive表,如果它已经过时了,我可以使用它将记录从t移动到t_archive。要移动记录,我使用两个查询:
INSERT INTO t_archive SELECT * FROM t WHERE A = 1 AND B = 2 AND C = 3
DELETE FROM t WHERE A = 1 AND B = 2 AND C = 3
(正如您注意到的,满足条件it为4和5)在上面提到的查询中,我尝试用it:
表:
create table properties
(
id int auto_increment primary key,
other_id int null
);
create index index_properties_on_other_id
on properties (other_id);
TX 1:
start transaction;
SET @last_id = 1;
delete from `properties` WHERE `properties`.`other_id` = @last_id;
I
"SELECT ... FOR UPDATE"锁是否加入了MySQL中的行?
如果是的话,是否有可能禁用这种行为?
文档中没有这方面的内容。我已经看到Oracle支持"SELECT ... FOR UPDATE OF table_name",其中table_name是主表,或者是受影响的行将被锁定的连接表之一,但我从未见过在MySQL上下文中提到过这一点。
当经常从多个来源插入到表中时,我会从表上的间隙锁中获得死锁。以下是我的流程概述。
START TRANSACTION
UPDATE vehicle_image
SET active = 0
WHERE vehicleID = SOMEID AND active = 1
Loop:
INSERT INTO vehicle_image (vehicleID, vehicleImageFilePath, vehicleImageSplashFilePath
,vehicleImageThumbnailFilePath, vehicleImageMiniFileP