无法解释的InnoDB超时

我最近看到一些非常基本的更新超时，并且无法确定原因。一个例子：

//＃查询时间：51锁定时间：0已发送的行数：0已检查的行数：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）NOT NULL，
  `photo_album_id` int（11）非空，
  `user_id` int（11）NOT NULL，
  `title` varchar（255）默认为'Untitled'，
  `description`文字，
  `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`（published`），
  KEY`index_photos_on_published_at`（`published_at`），
  KEY`index_photos_on_type`（`type`），
  KEY`index_photos_on_user_id`（`user_id`）
）引擎= InnoDB AUTO_INCREMENT = 42830默认字符集= utf8

— mvbl fst
source

愚蠢的问题：您在该表上有哪些索引？

— 盖乌斯

嗨，请看编辑。

— mvbl fst 2011年

嗯，这很烦人，因为这在Oracle中非常容易诊断，您只需将10046跟踪级别设置为12，它将确切告诉您它在做什么。我会再考虑一下。

— Gaius

我在使用InnoDB表时遇到类似的问题，我认为这与增量有关。我在做：UPDATE table SET <field>=<field>+1 WHERE <pk_field>=1;我的桌子虽然简单得多。随机地，这会导致您得到相同的错误。我的版本是：5.1.39。我今天花一些时间试图解决这个问题，所以如果发现任何问题，我会进行更新。

谢谢，请让我知道您发现了什么，我们仍然没有弄清楚这一点。

— mvbl fst 2011年

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

如果它在特定时间内发生很多，那么很容易每隔x秒钟获取一次输出并希望您捕获它（或者可能是人为地产生负载）。

— RS
source

我会说规范化数据库-并添加属性。

一张照片不需要携带有关其所属相册的所有信息-这会为相册提供单独的表格-以及仅包含photoID <-> albumID映射的关系表-如果包含的话，同样适用于摄影师（单独的表以及photoID和PhotographerID之间的映射表

乍一看，您的查询变得有点复杂，但是现在信息已在逻辑上进行了划分，同时您使用RDBMS来了解..数据及其关系。

— 鹰275
source