Незрозумілі очікування 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).

Будь-яка ідея, куди поїхати звідси? Я б'є по тупиках у всіх напрямках. Дякую.

Редагувати:

СТВОРИТИ ТАБЛИЦЮ "фотографії" (
  `id` int (11) NOT NULL auto_increment,
  `type` varchar (255) NOT NULL,
  `photo_album_id` int (11) НЕ NULL,
  `user_id` int (11) NOT NULL,
  `title` varchar (255) за замовчуванням" Без назви ",
  текст "опис",
  за замовчуванням NULL `Credit` varchar (255),
  `photo_file_name` varchar (255) за замовчуванням NULL,
  `photo_content_type` varchar (255) за замовчуванням NULL,
  `photo_file_size` int (11) за замовчуванням NULL,
  `photo_update_at` дата за замовчуванням NULL,
  `позиція` int (11) за замовчуванням '0',
  `views` int (11) за замовчуванням '0',
  `папка` varchar (255) за замовчуванням NULL,
  `опублікований` tinyint (1) за замовчуванням '0',
  `default_at` дата за замовчуванням NULL,
  `created_at` дата за замовчуванням NULL,
  `updated_at` дата за замовчуванням NULL,
  `album_publisher` 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_update_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_publisher` (` альбом_публікований`),
  KEY `index_photos_on_batch` (` партія`),
  KEY `index_photos_on_comment_count` (` коментар_рахунок`),
  KEY `index_photos_on_create_at` (` створено_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` (` опубліковано_at`),
  КЛЮЧОВИЙ `index_photos_on_type` (` type`),
  KEY `index_photos_on_user_id` (` user_id`)
) ENGINE = InnoDB AUTO_INCREMENT = 42830 DEFAULT 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

Я знаю, що це справді пізно, але вам дійсно потрібно зафіксувати вихід ШОУ ДВИГАТЕЛЯ ІННОДБА СТАНУ; під час цього запиту, щоб дізнатися, чому він чекає.

Якщо це трапляється багато протягом певного часу, було б просто просто захопити цей висновок кожні х секунд і сподіватися, що ви захопите його (або, можливо, штучно генеруєте навантаження).

— RS
джерело

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

Одному фотографії не потрібно містити всю інформацію про альбом, якому він належить - це вимагає окремої таблиці для альбомів - і таблиці відношень, яка містить лише відображення photoID <-> albumID, те саме стосується фотографії, якщо воно включено. (окрема таблиця та таблиця зіставлення між photoID та photographerID

Спочатку може здатися, що ваші запити стають дещо складнішими, але інформація тепер логічно розділена, і в той же час ви використовуєте RDBMS для того, про що йдеться .. дані та їх відносини

— орел275
джерело