Timeout InnoDB inspiegabili

Ultimamente ho visto scadere alcuni aggiornamenti di base e non sono stato in grado di determinare la causa. Un esempio:

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

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

Lo stesso registro non ha voci con Lock_time> 0. L'esecuzione show innodb statusnon rivela alcun blocco correlato. Questo problema sembra interessare almeno 5 tabelle diverse in base ai registri del mio server app (che mostrano un Mysql::Error: Lock wait timeout exceedederrore relativo a ciascuna voce corrispondente nel registro mysql-slow).

Qualche idea su dove andare da qui? Sto colpendo vicoli ciechi in tutte le direzioni. Grazie.

MODIFICARE:

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) predefinito 'Untitled',
  testo "descrizione",
  `credit` varchar (255) default NULL,
  `photo_file_name` varchar (255) predefinito NULL,
  `photo_content_type` varchar (255) default NULL,
  `photo_file_size` int (11) default NULL,
  `photo_updated_at` datetime predefinito NULL,
  `position` int (11) default '0',
  `views` int (11) default '0',
  `folder` varchar (255) default NULL,
  `pubblicato` tinyint (1) default '0',
  NULL predefinito datetime `Published_at`,
  `create_at` datetime predefinito NULL,
  NULL predefinito datetime `updated_at`,
  `album_published` tinyint (1) default '0',
  `comment_count` int (11) predefinito '0',
  `audio_file_name` varchar (255) predefinito NULL,
  `audio_content_type` varchar (255) default NULL,
  `audio_file_size` int (11) default NULL,
  NULL predefinito datetime `audio_updated_at`,
  `cover` tinyint (1) default '0',
  `slug` varchar (255) default NULL,
  `commenti_count` int (11) predefinito '0',
  `delete_from_s3` tinyint (1) default '0',
  `batch` int (11) default NULL,
  `audio` varchar (255) predefinito NULL,
  CHIAVE PRIMARIA (`id`),
  KEY `index_photos_on_album_published` (` album_published`),
  KEY `index_photos_on_batch` (` batch`),
  KEY `index_photos_on_comment_count` (` comment_count`),
  TASTO `index_photos_on_created_at` (` Created_at`),
  TASTO `index_photos_on_delete_from_s3` (` delete_from_s3`),
  TASTO `index_photos_on_photo_album_id` (` photo_album_id`),
  KEY `index_photos_on_published` (` pubblicato`),
  KEY `index_photos_on_published_at` (` Published_at`),
  KEY `index_photos_on_type` (` type`),
  TASTO `index_photos_on_user_id` (` user_id`)
) ENGINE = InnoDB AUTO_INCREMENT = 42830 CARATTERISTICHE PREDEFINITE = utf8

— mvbl fst
fonte

Domanda sciocca: quali indici hai su quel tavolo?

— Gaius,

Ciao, per favore vedi la modifica.

— mvbl,

Hmm, questo è fastidioso perché è così facile da diagnosticare in Oracle, hai appena impostato 10046 traccia livello 12 e ti dirà esattamente cosa sta facendo. Ci penserò un po 'di più.

— Gaius,

Sto riscontrando un problema simile con una tabella InnoDB, penso che abbia qualcosa a che fare con l'incremento. Sto facendo: il UPDATE table SET <field>=<field>+1 WHERE <pk_field>=1;mio tavolo è molto più semplice però. A caso questo provoca lo stesso errore che stai ricevendo. La mia versione è: 5.1.39. Sto passando un po 'di tempo oggi a cercare di capirlo, quindi aggiornerò se trovo qualcosa.

Grazie, fatemi sapere cosa scoprite, non l'abbiamo ancora capito.

— mvbl,

So che è molto tardi, ma è necessario catturare l'output di SHOW ENGINE INNODB STATUS; durante quella query per vedere perché sta aspettando.

Se succede molto durante un tempo specifico, sarebbe facile afferrare quell'output ogni x secondi e sperare di catturarlo (o forse generare artificialmente il carico).

— RS
fonte

Direi normalizzare il database - e aggiungere indpper propper.

Una singola foto non deve contenere tutte le informazioni sull'album a cui appartiene - questo grida per una tabella separata per gli album - e una tabella di relazione che contiene solo la mappatura di photoID <-> albumID lo stesso vale - se incluso - per il fotografo (tabella separata e tabella di mappatura tra photoID e photographerID

In un primo momento potrebbe sembrare che le tue query diventino un po 'più complicate, ma le informazioni ora sono divise logicamente e allo stesso tempo usi un RDBMS per quello che riguarda ... i dati e le loro relazioni

— eagle275
fonte