相关疑难解决方法(0)

我们从 Microsoft ADO.NET 连接器访问 MySQL。

有时我们会在 innodb 状态中看到以下死锁，并且无法确定问题的原因。看起来事务（2）正在等待并持有相同的锁？

------------------------
LATEST DETECTED DEADLOCK
------------------------
110606  5:35:09
*** (1) TRANSACTION:
TRANSACTION 0 45321452, ACTIVE 0 sec, OS thread id 3804 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 368, 1 row lock(s)
    MySQL thread id 84, query id 3265713 localhost 127.0.0.1 famdev Updating
    UPDATE people SET company_id = 1610, name = '<name>', password = '<hash>', temp_password = NULL, reset_password_hash = NULL, email = …

这几乎可以肯定是我的另一个问题的原因，但我认为值得将两者分开，因为我有一个基于以下日志的假设，我很乐意伪造或验证该假设。

我的假设是另一个死锁实际上是以下查询的结果，根据我的理解隐藏了原始查询，innodb 状态仅显示最近的事务（这是正确的吗？）。

根据日志，我检查了我们的代码，发现依次执行了以下两个查询：

db.Execute("UPDATE people SET iphone_device_id=NULL WHERE iphone_device_id=@0 AND people_id<>@1", DeviceID, m_User.people_id);
// I have hard coded this query in this snippet to simplify things
db.Execute("UPDATE people SET company_id = 444, name = 'Dad', password = '<pass>', temp_password = NULL, reset_password_hash = NULL, email = '<redacted>@gmail.com', phone = NULL, mobile = NULL, iphone_device_id = 'iphone:<device_id_blah>', iphone_device_time = '2011-06-06 19:12:29', last_checkin = '2011-06-07 02:49:47', location_lat = <lat>, location_long = <lng>, gps_strength = 66, picture_blob_id = …

前言

我们的应用程序运行多个DELETE并行执行查询的线程。查询影响孤立的数据，即不应该存在并发DELETE发生在来自不同线程的相同行上的可能性。但是，根据文档，MySQL 对DELETE语句使用所谓的“next-key”锁，它同时锁定匹配的键和一些间隙。这会导致死锁，我们找到的唯一解决方案是使用READ COMMITTED隔离级别。

问题

DELETE使用JOIN大表执行复杂语句时会出现问题。在特定情况下，我们有一个带有警告的表，只有两行，但查询需要从两个单独的INNER JOINed 表中删除属于某些特定实体的所有警告。查询如下：

DELETE pw 
FROM proc_warnings pw 
INNER JOIN day_position dp 
   ON dp.transaction_id = pw.transaction_id 
INNER JOIN ivehicle_days vd 
   ON vd.id = dp.ivehicle_day_id 
WHERE vd.ivehicle_id=? AND dp.dirty_data=1

当 day_position 表足够大时（在我的测试用例中有 1448 行），那么即使使用READ COMMITTED隔离模式，任何事务也会阻塞整个 proc_warnings表。

该问题始终在此示例数据上重现 - http://yadi.sk/d/QDuwBtpW1BxB9在 MySQL 5.1（在 5.1.59 上检查）和 MySQL 5.5（在 MySQL 5.5.24 上检查）中。

编辑：链接的示例数据还包含查询表的架构和索引，为方便起见，在此处复制：

CREATE TABLE  `proc_warnings` (
    `id` int(11) NOT NULL AUTO_INCREMENT, …

我正在解决 MySQL 错误“尝试获取锁定时发现死锁；尝试重新启动事务”。

我将不得不更新程序以允许死锁。该SELECT语句是否可能会产生死锁错误？我知道它只是一个读锁，所以多重选择不会有问题，但是如果有一个INSERT, UPDATEorDELETE语句（可能有连接的子查询）和一个SELECT语句（可能有连接或子查询）怎么办？

是否有可能在SELECT而不是INSERT,UPDATE或上抛出错误DELETE。

如果你好奇，故事就在这里。

我遇到了一个问题，即同时执行的多个 MySQL 更新将锁定并需要几分钟才能完成。我正在使用 InnoDB，所以我很困惑为什么会发生这种情况，因为每次更新只更新 1 行。我还使用了一个 m2.4xlarge RDS 实例（它们是最大的）。

这就是我正在做的事情：我有一个包含大约 100M 行的表，其中“views”是一列（已编入索引），我想更新大约 1M 行的视图。在几个不同的服务器上，我有一个这样的循环，其中每个服务器都有自己的一组要更新的行（伪代码）：

mysql("set autocommit=0");
mysql("start transaction");

foreach($rows as $row) {
    mysql("update table set views=views+1 where id=$row[id]");
}

mysql("commit");

这会遍历所有需要更新的行。当服务器数量很少时，它工作得很好，比如大约 4，但是当它增长到 10+ 时，更新开始立即挂在“更新”状态。没有说它正在等待锁定，它只是“更新”。这会发生大约 5 分钟，它最终将进行更新并继续循环并最终再次发生。

我不是在寻找进行更新的替代方法。拥有像 tmp 表和

update table,tmp_table set table.views = table.views+tmp_table.views where
  table.id = tmp_table.id

锁定所有正在更新的行，直到它们全部完成（可能需要几个小时），这对我不起作用。他们必须在这些可怕的循环中。

我想知道为什么他们会陷入“正在更新”状态，以及我能做些什么来防止它。

tldr; 有 10 个以上的“更新”循环最终会同时锁定所有正在完成的更新，原因不明，直到他们决定最终进行更新并继续循环，直到它在几秒钟后再次发生。

显示变量：http : //pastebin.com/NdmAeJrz

显示引擎 INNODB 状态：http : //pastebin.com/Ubwu4F1h

MySQL 版本 5.5.13-1

摘自SHOW ENGINE INNODB STATUS\G：

LATEST DETECTED DEADLOCK
------------------------
111218 10:22:34
*** (1) TRANSACTION:
TRANSACTION 1318D95B, ACTIVE 0 sec starting index read
mysql tables in use 6, locked 6
LOCK WAIT 53 lock struct(s), heap size 14776, 77 row lock(s)
MySQL thread id 60933, query id 124472414 192.168.6.31 thanhnt Copying to tmp table
INSERT INTO usertmp(userid,npayvalue,balance)       
    SELECT B.`userid`, SUM(C.`moneyv`) a,(B.`balance` + B.`promotions`+ B.`promotions1`+ B.`overdraft`) b
    FROM `ox_campaigns` A
    INNER JOIN `v3_cam_date` C ON C.`campaignid` = A.`campaignid` …

我想知道是否同时 UPDATE .... LIMIT N 不会与查询数据库的多个客户端重叠。

在 UPDATE ... LIMIT N 之后，客户端将使用分配的一些 client_id 进行 SELECT。我不希望客户端重叠结果，因此每次更新后使用 SELECT 查询数据库时，每个客户端都会有不同的记录。

这取决于表引擎？

更新锁定表/记录？（我确定这取决于引擎）。

我认为 UPDATE LIMIT 不应重叠结果，dbs 具有 ACID 属性......我想确认这一点。

我是数据库管理的新手。我试图找出死锁异常的原因，但我无法理解日志。

日志显示“事务 1 已回滚”。为什么会这样？赌注表与帐户表有外键关系，但它（运行插入的反式）无法获得 S 锁并因此因死锁而死亡是否“正常”？我的意思是，考虑到它只是验证参照完整性的读取，这似乎很糟糕。

第二笔交易也在写入赌注表，但没有更新。那么是用于创建 auto-inc 键的“机制”还是索引机制或两者都导致死锁？为什么它们不会以连续的方式发生？或者可能是他们，但某种等待时间太短了。

任何帮助，指针，进一步阅读如何使用下面的日志来解决死锁问题表示赞赏。

111031 17:39:26
*** (1) TRANSACTION:
TRANSACTION 0 984899905, ACTIVE 180 sec, process no 10882, OS thread id 1104619856 inserting
mysql tables in use 1, locked 1
LOCK WAIT 13 lock struct(s), heap size 3024, undo log entries 86
MySQL thread id 122, query id 28932942 localhost 127.0.0.1 bt update

INSERT INTO wager (amount_won, confirmation, created_by_partner, creation_date, description, fantasy_league, 
     first_game_start, image_thumb, image_wide, kind, last_game_start, last_update_version, locked, name, 
     num_future, num_past, num_present, partner, …