多年来，我一直在处理这个问题，但一直无法深入了解它。我不知道是什么导致了这些锁。
错误是：Lock wait timeout exceeded; try restarting transaction SQLState: 41000 VendorError: 1205
SQL 语句是在事务中运行的单个插入语句。所有插入都是这种形式，因此没有批量插入或混合模式插入等。
INSERT INTO attachment( id, entityid, entitytype , addeduserid , deleteduserid , fullpath , filename, status, creationdate, lastupdated, deletiondate, hasfile,notes,history,type,mimeinfo,archivedby,archivedon, referencedate,changedby,changedon ) values (0,0,2,360,null,NULL,NULL,1,'2013-02-20 08:45:31','2013-02-20 08:45:31',NULL,0,NULL,'20/02/2013 08:45:UserA:File uploaded internally. <br>',0,NULL,null,NULL,NULL,null,NULL);
系统配置：Mysql 版本：'Server version: 5.1.61 Source distribution'（在 Redhat 上）
存储：INNODB
INNODB 相关配置（部分来自 my.cnf 编辑）：
innodb_file_per_table=1
innodb_buffer_pool_size=3G
innodb_additional_mem_pool_size=20M
innodb_log_file_size=512M
innodb_log_files_in_group=2
innodb_log_buffer_size=16M
innodb_support_xa=1
innodb_doublewrite=1
innodb_thread_concurrency=0
innodb_flush_log_at_trx_commit=2
innodb_autoinc_lock_mode=2**
innodb_rollback_on_timeout=1
innodb_locks_unsafe_for_binlog=1**
thread_cache_size=8
query_cache_size=256M
query_cache_limit=4M
table_cache=2048
table_definition_cache=1024
tmp_table_size=512M
max_heap_table_size=512M
transaction-isolation=READ-COMMITTED**
innodb_table_locks=0**
innodb_lock_wait_timeout=50**
** 这些是针对此问题专门添加的。
一般来说：
系统（即有 6 个应用程序实例，每个实例具有相同的数据库结构，都在一个 mysql 实例上运行）可以运行好几天，然后可以在开始发生锁定等待的情况下运行，并且通常会让它们在此期间以组的形式出现的一天。每个单独的错误都会重复发生，因为一旦失败，我会再试一次，通常重试会失败。我已配置为重试 4 次。通常，锁只会出现在几个不同的表上。
今天这个问题的具体实例：
今天早上在attachment桌子上，从昨晚开始，桌子上就没有插入过。自前一天晚上以来，桌面上也没有任何更新。如果锁与其他用户进行更新和插入无关，那么某些选择语句会导致锁吗？我试图确保所有选择语句都使用attachment_general_index？
由于我主要在几个不同的表上得到这个 - 这是这个表的结构。
CREATE TABLE `attachment` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`entityid` int(10) unsigned DEFAULT NULL,
`entitytype` tinyint(3) unsigned NOT NULL DEFAULT '0',
`addeduserid` int(10) unsigned NOT NULL,
`deleteduserid` int(10) unsigned DEFAULT NULL,
`fullpath` varchar(255) DEFAULT NULL,
`filename` varchar(255) DEFAULT NULL,
`status` tinyint(3) unsigned NOT NULL DEFAULT '0',
`creationdate` varchar(40) DEFAULT NULL,
`lastupdated` varchar(40) DEFAULT NULL,
`deletiondate` varchar(40) DEFAULT NULL,
`hasfile` tinyint(3) unsigned NOT NULL DEFAULT '0',
`notes` text,
`history` text,
`type` tinyint(3) unsigned DEFAULT '0',
`lastupdatedby` int(10) DEFAULT '0',
`lastupdatedinfo` varchar(255) DEFAULT NULL,
`mimeinfo` varchar(255) DEFAULT NULL,
`archivedby` int(10) unsigned DEFAULT NULL,
`archivedon` varchar(40) DEFAULT NULL,
`referencedate` varchar(40) DEFAULT NULL,
`changedby` int(10) unsigned DEFAULT NULL,
`changedon` varchar(40) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `attachment_addeduserid_fkey` (`addeduserid`),
KEY `attachment_deleteduserid_fkey` (`deleteduserid`),
KEY `attachment_archivedby_fkey` (`archivedby`),
KEY `attachment_changedby_fkey` (`changedby`),
KEY `attachment_general_index` (`entitytype`,`entityid`,`status`,`type`),
CONSTRAINT `attachment_ibfk_1` FOREIGN KEY (`addeduserid`) REFERENCES `user` (`id`),
CONSTRAINT `attachment_ibfk_2` FOREIGN KEY (`deleteduserid`) REFERENCES `user` (`id`),
CONSTRAINT `attachment_ibfk_3` FOREIGN KEY (`archivedby`) REFERENCES `user` (`id`),
CONSTRAINT `attachment_ibfk_4` FOREIGN KEY (`changedby`) REFERENCES `user` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3619 DEFAULT CHARSET=latin1$$
我附上了最近的 SHOW INNODB STATUS，这是从今天开始的，从昨天开始就没有锁等待。我不明白所有这些输出，但主要是锁似乎从未出现在这里。我认为是因为它们没有被归类为死锁？
https://docs.google.com/document/d/1Hslf2B594n8ofAUYxN54Gh8FrSCIFNGGMtthVI_Lv4k/pub
是否只有死锁区域对此问题感兴趣？如果有其他方面我会尽量收集，当它发生并可以提供。
任何帮助，将不胜感激。
缺口