私はこれを何年にもわたって問題を抱えており、その根底に到達することはできませんでした。何がこれらのロックを引き起こしているのかわかりません。
エラーは次のとおりです。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バージョン：'サーバーバージョン：5.1.61ソースディストリビューション'（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回再試行するように構成しました。多くの場合、ロックは2、3の異なるテーブルでのみ発生します。
問題の今日の特定のインスタンス：
今朝のattachmentテーブルでは、昨夜からテーブルに挿入物はありませんでした。また、前夜からテーブルの更新はありませんでした。ロックが更新と挿入を行う他のユーザーに関連していない場合、特定のselectステートメントがロックを引き起こす可能性がありますか？私はすべてのselectステートメントが使用することを確認しようとしました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$$
最近のSHOWINNODBSTATUSを添付しました。これは今日からのもので、昨日からロック待機はありません。私はこの出力のすべてを理解していませんが、重要なことは、ロックがここに表示されないように見えることです。デッドロックに分類されていないからだと思いますか？
https://docs.google.com/document/d/1Hslf2B594n8ofAUYxN54Gh8FrSCIFNGGMtthVI_Lv4k/pub
この問題で興味深いのは、デッドロック領域だけですか？他にエリアがある場合は、発生時に収集して提供できるようにします。
どんな助けでもいただければ幸いです。
ニック