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 ช้า)

มีความคิดว่าจะไปจากที่นี่ไหม? ฉันตีปลายตายในทุกทิศทาง ขอบคุณ

แก้ไข:

สร้างตาราง `photos` (
  `id` int (11) ไม่ใช่ NULL auto_increment
  `type` varchar (255) ไม่เป็นโมฆะ
  `photo_album_id` int (11) ไม่เป็นโมฆะ
  `user_id` int (11) ไม่เป็นโมฆะ
  `title` varchar (255) ค่าเริ่มต้น 'ไม่มีชื่อ'
  `คำอธิบาย 'ข้อความ
  `credit` varchar (255) ค่าเริ่มต้นเป็นศูนย์
  `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) ค่าเริ่มต้นเป็นศูนย์
  `Published` tinyint (1) ค่าเริ่มต้น '0'
  `Published_at` datetime ค่าเริ่มต้นเป็น NULL
  `created_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) ค่าเริ่มต้นเป็นโมฆะ
  `audio_updated_at` datetime ค่าเริ่มต้นเป็น NULL
  `cover` tinyint (1) ค่าเริ่มต้น '0'
  `slug` varchar (255) ค่าเริ่มต้นเป็นศูนย์
  `comments_count` int (11) ค่าเริ่มต้น '0'
  `delete_from_s3` tinyint (1) ค่าเริ่มต้น '0'
  `batch` int (11) ค่าเริ่มต้นเป็นศูนย์
  `audio` varchar (255) ค่าเริ่มต้นเป็นศูนย์
  คีย์หลัก (`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`)
) ENGINE = InnoDB AUTO_INCREMENT = 42830 ค่าเริ่มต้นเริ่มต้น = utf8

ฉันรู้ว่ามันสายเกินไป แต่คุณต้องจับเอาท์พุทของ SHOW ENGINE INNODB STATUS; ระหว่างการสืบค้นนั้นเพื่อดูว่าทำไมมันถึงรออยู่

หากมันเกิดขึ้นบ่อยครั้งในช่วงเวลาที่กำหนดมันจะง่ายมากที่จะหยิบเอาท์พุทนั้นออกมาทุก ๆ x วินาทีและหวังว่าคุณจะจับมัน

ฉันว่าฐานข้อมูลปกติ - และเพิ่มตัวเหนี่ยวนำ

ภาพถ่ายเดียวไม่จำเป็นต้องพกข้อมูลทั้งหมดเกี่ยวกับอัลบั้มที่มันเป็นของ - ร้องนี้สำหรับตารางแยกต่างหากสำหรับอัลบั้ม - และตารางความสัมพันธ์ที่มีเพียงการทำแผนที่ของ photoID <-> albumID เหมือนกัน - หากรวมไว้กับช่างภาพ (แยกตารางและตารางการจับคู่ระหว่าง photoID และ photographerID

อาจดูเป็นครั้งแรกที่แบบสอบถามของคุณซับซ้อนขึ้นเล็กน้อย แต่ขณะนี้ข้อมูลถูกแบ่งตามหลักเหตุผลและในเวลาเดียวกันคุณใช้ RDBMS สำหรับข้อมูลและความสัมพันธ์ของพวกเขา