Unerklärte InnoDB-Zeitüberschreitungen

Ich habe in letzter Zeit einige sehr grundlegende Updates gesehen und konnte die Ursache nicht ermitteln. Ein Beispiel:

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

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

Das gleiche Protokoll enthält keine Einträge mit einer Lock_time> 0. Beim Ausführen werden show innodb statusauch keine zugehörigen Sperren angezeigt . Dieses Problem scheint mindestens 5 verschiedene Tabellen zu betreffen, die auf meinen App-Server-Protokollen basieren (die einen Mysql::Error: Lock wait timeout exceededFehler in Bezug auf jeden entsprechenden Eintrag im mysql-slow-Protokoll anzeigen).

Irgendeine Idee, wohin man von hier aus gehen soll? Ich stoße in alle Richtungen auf Sackgassen. Vielen Dank.

BEARBEITEN:

TABELLE ERSTELLEN `Fotos` (
  `id` int (11) NOT NULL auto_increment,
  `type` varchar (255) NICHT NULL,
  `photo_album_id` int (11) NICHT NULL,
  `user_id` int (11) NICHT NULL,
  `title` varchar (255) default 'Untitled',
  `Beschreibung` Text,
  `credit` varchar (255) default NULL,
  `photo_file_name` varchar (255) default NULL,
  `photo_content_type` varchar (255) default NULL,
  `photo_file_size` int (11) default NULL,
  `photo_updated_at` datetime default NULL,
  `position` int (11) default '0',
  `views` int (11) default '0',
  `folder` varchar (255) default NULL,
  `veröffentlicht` tinyint (1) default '0',
  `public_at` datetime default NULL,
  `created_at` datetime default NULL,
  `update_at` datetime default NULL,
  `album_published` tinyint (1) default '0',
  `comment_count` int (11) default '0',
  `audio_file_name` varchar (255) default NULL,
  `audio_content_type` varchar (255) default NULL,
  `audio_file_size` int (11) default NULL,
  `audio_updated_at` datetime default NULL,
  `cover` tinyint (1) default '0',
  `slug` varchar (255) default NULL,
  `comment_count` int (11) default '0',
  `delete_from_s3` tinyint (1) default '0',
  `batch` int (11) default NULL,
  `audio` varchar (255) default NULL,
  Primärschlüssel (`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`),
  SCHLÜSSEL `index_photos_on_published` (` veröffentlicht`),
  KEY `index_photos_on_published_at` (` publications_at`),
  KEY `index_photos_on_type` (` type`),
  KEY `index_photos_on_user_id` (` user_id`)
) ENGINE = InnoDB AUTO_INCREMENT = 42830 DEFAULT CHARSET = utf8

— mvbl fst
quelle

Dumme Frage: Welche Indizes haben Sie auf dieser Tabelle?

— Gaius

Hallo, bitte sehen Sie die Bearbeitung.

— mvbl fst

Hmm, das ist ärgerlich, weil dies in Oracle so einfach zu diagnostizieren ist, dass Sie nur 10046 Trace Level 12 eingestellt haben und genau wissen , was es tut. Ich werde noch etwas darüber nachdenken.

— Gaius

Ich habe ein ähnliches Problem mit einer InnoDB-Tabelle. Ich denke, das hat etwas mit dem Inkrement zu tun. Ich mache: UPDATE table SET <field>=<field>+1 WHERE <pk_field>=1;Mein Tisch ist allerdings viel einfacher. Zufällig verursacht dies den gleichen Fehler, den Sie erhalten. Meine Version ist: 5.1.39. Ich verbringe heute einige Zeit damit, es herauszufinden, damit ich es aktualisieren kann, wenn ich etwas finde.

Danke, bitte lassen Sie mich wissen, was Sie herausfinden, wir haben dies immer noch nicht herausgefunden.

— mvbl fst

Ich weiß, dass dies sehr spät ist, aber Sie müssen die Ausgabe von SHOW ENGINE INNODB STATUS wirklich erfassen. während dieser Abfrage, um zu sehen, warum es wartet.

Wenn es in einer bestimmten Zeit häufig vorkommt, ist es einfach, diese Ausgabe alle x Sekunden abzurufen und zu hoffen, dass Sie sie erfassen (oder die Last möglicherweise künstlich erzeugen).

— RS
quelle

Ich würde sagen, Datenbank normalisieren - und Propper-Indizes hinzufügen.

Ein einzelnes Foto muss nicht alle Informationen über das Album enthalten, zu dem es gehört - dies verlangt nach einer separaten Tabelle für Alben - und eine Beziehungstabelle, die nur die Zuordnung von photoID <-> albumID enthält, gilt - sofern enthalten - für den Fotografen (separate Tabelle und eine Zuordnungstabelle zwischen photoID und fotografID

Es mag zunächst so aussehen, als würden Ihre Abfragen etwas komplizierter, aber die Informationen sind jetzt logisch aufgeteilt, und gleichzeitig verwenden Sie ein RDBMS für das, worum es geht. Daten und ihre Beziehungen

— eagle275
quelle