无法解释的 InnoDB 超时

mvb*_*fst 11 mysql innodb query locked-objects

我最近看到一些非常基本的更新超时,但无法确定原因。一个例子:

//# Query_time: 51 Lock_time: 0 Rows_sent: 0 Rows_examined: 0

UPDATE photos SET position = position + 1 WHERE (photo_album_id = 40470);

同一个日志没有 Lock_time > 0 的条目。运行show innodb status也不会显示任何相关的锁。根据我的应用服务器日志(显示Mysql::Error: Lock wait timeout exceeded与 mysql-slow 日志中的每个相应条目相关的错误),此问题似乎影响了至少 5 个不同的表。

知道从这里去哪里吗?我在各个方向都陷入了死胡同。谢谢。

编辑:

创建表`照片`(
  `id` int(11) NOT NULL auto_increment,
  `type` varchar(255) 非空,
  `photo_album_id` int(11) 非空,
  `user_id` int(11) 非空,
  `title` varchar(255) 默认为“无标题”,
  `描述`文本,
  `credit` varchar(255) 默认为 NULL,
  `photo_file_name` varchar(255) 默认为 NULL,
  `photo_content_type` varchar(255) 默认为 NULL,
  `photo_file_size` int(11) 默认为 NULL,
  `photo_updated_at` 日期时间默认为 NULL,
  `position` int(11) 默认为 '0',
  `views` int(11) 默认为 '0',
  `folder` varchar(255) 默认为 NULL,
  `published` tinyint(1) 默认'0',
  `published_at` 日期时间默认为 NULL,
  `created_at` 日期时间默认为 NULL,
  `updated_at` 日期时间默认为 NULL,
  `album_published` tinyint(1) 默认'0',
  `comment_count` int(11) 默认'0',
  `audio_file_name` varchar(255) 默认为 NULL,
  `audio_content_type` varchar(255) 默认为 NULL,
  `audio_file_size` int(11) 默认为 NULL,
  `audio_updated_at` 日期时间默认为 NULL,
  `cover` tinyint(1) 默认为“0”,
  `slug` varchar(255) 默认为 NULL,
  `comments_count` int(11) 默认'0',
  `delete_from_s3` tinyint(1) 默认'0',
  `batch` int(11) 默认为 NULL,
  `audio` varchar(255) 默认为 NULL,
  主键(`id`),
  KEY`index_photos_on_album_published`(`album_published`),
  KEY`index_photos_on_batch`(`batch`),
  KEY`index_photos_on_comment_count`(`comment_count`),
  KEY`index_photos_on_created_at`(`created_at`),
  KEY`index_photos_on_delete_from_s3`(`delete_from_s3`),
  KEY`index_photos_on_photo_album_id`(`photo_album_id`),
  KEY`index_photos_on_published`(`已发布`),
  KEY`index_photos_on_published_at`(`published_at`),
  KEY`index_photos_on_type`(`type`),
  密钥`index_photos_on_user_id`(`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=42830 默认字符集=utf8

R. *_* S. 3

我知道这确实很晚了,但是您确实需要捕获 SHOW ENGINE INNODB STATUS 的输出;在该查询期间查看它为何等待。

如果它在特定时间内发生很多,那么很容易每隔 x 秒获取该输出并希望捕获它(或者可能人为地生成负载)。