Необъяснимые тайм-ауты InnoDB

В последнее время я наблюдаю некоторые очень простые обновления и не могу определить причину. Пример:

// # 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также не обнаруживает связанных блокировок. Эта проблема, по-видимому, затрагивает как минимум 5 различных таблиц, основанных на журналах моего сервера приложений (которые показывают Mysql::Error: Lock wait timeout exceededошибку, связанную с каждой соответствующей записью в журнале mysql-slow).

Любая идея о том, куда идти отсюда? Я захожу в тупик во всех направлениях. Спасибо.

РЕДАКТИРОВАТЬ:

CREATE TABLE `photos` (
  `id` int (11) NOT NULL auto_increment,
  `type` varchar (255) NOT NULL,
  `photo_album_id` int (11) NOT NULL,
  `user_id` int (11) NOT NULL,
  `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` datetime по умолчанию NULL,
  `position` int (11) по умолчанию '0',
  `views` int (11) по умолчанию '0',
  `folder` varchar (255) по умолчанию NULL,
  `опубликовано` tinyint (1) по умолчанию '0',
  `publ_at` datetime по умолчанию NULL,
  `create_at` datetime по умолчанию NULL,
  `updated_at` datetime по умолчанию 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` datetime по умолчанию 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` (` made_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` (` publ_at`),
  KEY `index_photos_on_type` (` type`),
  KEY `index_photos_on_user_id` (` user_id`)
) ENGINE = InnoDB AUTO_INCREMENT = 42830 CHARSET ПО УМОЛЧАНИЮ = utf8

— MVBL FST
источник

Глупый вопрос: какие у вас индексы на этой таблице?

— Гай

Привет, пожалуйста, смотрите редактирование.

— mvbl fst

Хм, это раздражает, потому что это так просто диагностировать в Oracle, вы просто установите 10046 уровень трассировки 12, и он точно скажет вам , что он делает. Я еще подумаю над этим.

— Гай

У меня похожая проблема с таблицей InnoDB, я думаю, что это как-то связано с приращением. Я делаю: UPDATE table SET <field>=<field>+1 WHERE <pk_field>=1;моя таблица намного проще, хотя. Случайно это вызывает ту же ошибку, которую вы получаете. Моя версия: 5.1.39. Сегодня я провожу некоторое время, пытаясь выяснить это, поэтому я обновлю, если найду что-нибудь.

Спасибо, пожалуйста, дайте мне знать, что вы узнали, мы до сих пор не выяснили это.

— mvbl FST

Я знаю, что это действительно поздно, но вам действительно нужно захватить вывод SHOW ENGINE INNODB STATUS; во время этого запроса, чтобы увидеть, почему он ждет.

Если это происходит часто в течение определенного времени, было бы легко просто захватить этот вывод каждые x секунд и надеяться, что вы захватите его (или, возможно, искусственно сгенерируете нагрузку).

— RS
источник

Я бы сказал, нормализуйте базу данных - и добавьте пропперы.

Отдельная фотография не должна содержать всю информацию об альбоме, к которому она принадлежит - это требует отдельной таблицы для альбомов - и таблицы отношений, которая содержит только сопоставление photoID <-> albumID, то же самое относится - если включено - к фотографу (отдельная таблица и таблица сопоставления между photoID и photographerID

Поначалу может показаться, что ваши запросы становятся немного сложнее, но теперь информация логически разделена, и в то же время вы используете СУБД для того, что она имеет в виду .. данные и их отношения

— eagle275
источник