相关疑难解决方法(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 = …

我们在 Windows Server 2008 R2 上运行 MySQL 5.1。

我们最近一直在对我们的数据库进行一些诊断，并发现了一些我们无法解释的令人不安的伪影。当我们有需要很长时间（> 2000 毫秒）的查询时，我们添加了一些代码来记录。结果令人惊讶（并且可能是对我们僵局的解释）。

有时，通常只需要很少时间（<10 毫秒）的查询需要 4 到 13 秒。需要明确的是，这些是持续运行（每秒数次）并且不会受到这些查询时间峰值影响的查询。

我们已经检查了我们的索引，寻找任何明显的错误，但运气不佳。

更新

人表：

| people | CREATE TABLE `people` (
`people_id` bigint(20) NOT NULL AUTO_INCREMENT,
`company_id` bigint(20) NOT NULL,
`name` varchar(255) DEFAULT NULL,
`password` varchar(255) DEFAULT NULL,
`temp_password` varchar(10) DEFAULT NULL,
`reset_password_hash` varchar(255) DEFAULT NULL,
`email` varchar(255) DEFAULT NULL,
`phone` varchar(32) DEFAULT NULL,
`mobile` varchar(32) DEFAULT NULL,
`iphone_device_id` varchar(160) DEFAULT NULL,
`iphone_device_time` datetime DEFAULT NULL,
`last_checkin` datetime DEFAULT NULL, …

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

我的假设是另一个死锁实际上是以下查询的结果，根据我的理解隐藏了原始查询，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 = …

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

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

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

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

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

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

这取决于表引擎？

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

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