Hết thời gian chờ InnoDB không giải thích được

Gần đây tôi đã thấy một số cập nhật rất cơ bản và không thể xác định nguyên nhân. Một ví dụ:

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

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

Nhật ký tương tự không có mục nào có Lock_time> 0. Chạy show innodb statuscũng không tiết lộ bất kỳ khóa liên quan nào. Vấn đề này dường như ảnh hưởng đến ít nhất 5 bảng khác nhau dựa trên nhật ký máy chủ ứng dụng của tôi (hiển thị Mysql::Error: Lock wait timeout exceededlỗi liên quan đến từng mục tương ứng trong nhật ký chậm mysql).

Bất cứ ý tưởng về nơi để đi từ đây? Tôi đang đi vào ngõ cụt theo mọi hướng. Cảm ơn.

BIÊN TẬP:

TẠO BẢNG `ảnh` (
  `id` int (11) KHÔNG NULL auto_increment,
  `type` varchar (255) KHÔNG NULL,
  `photo_album_id` int (11) KHÔNG PHẢI,
  `user_id` int (11) KHÔNG PHẢI,
  `title` varchar (255) mặc định 'Chưa có tiêu đề',
  `mô tả` văn bản,
  `credit` varchar (255) NULL mặc định,
  `photo_file_name` varchar (255) mặc định NULL,
  `photo_content_type` varchar (255) mặc định NULL,
  `photo_file_size` int (11) NULL mặc định,
  `photo_updated_at` NULL mặc định thời gian,
  `vị trí` int (11) mặc định '0',
  `lượt xem` int (11) mặc định '0',
  `thư mục` varchar (255) NULL mặc định,
  `đã xuất bản` tinyint (1) mặc định '0',
  `Publish_at` datetime mặc định NULL,
  `created_at` datetime mặc định NULL,
  `update_at` NULL mặc định thời gian,
  `album_published` tinyint (1) mặc định '0',
  `comment_count` int (11) mặc định '0',
  `audio_file_name` varchar (255) mặc định NULL,
  `audio_content_type` varchar (255) mặc định NULL,
  `audio_file_size` int (11) NULL mặc định,
  `audio_updated_at` NULL mặc định thời gian,
  `cover` tinyint (1) mặc định '0',
  `slug` varchar (255) NULL mặc định,
  `bình luận_count` int (11) mặc định '0',
  `xóa_from_s3` tinyint (1) mặc định '0',
  `batch` int (11) NULL mặc định,
  `audio` varchar (255) NULL mặc định,
  KHÓA CHÍNH (`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` (` xóa_from_s3`),
  KEY `index_photos_on_photo_album_id` (` photo_album_id`),
  KEY `index_photos_on_published` (` đã xuất bản`),
  KEY `index_photos_on_published_at` (` đã xuất bản_at`),
  KEY `index_photos_on_type` (` type`),
  KEY `index_photos_on_user_id` (` user_id`)
) ĐỘNG CƠ = InnoDB AUTO_INCREMENT = 42830 DEFAULT CHARSET = utf8

— mvbl fst
nguồn

Câu hỏi ngớ ngẩn: bạn có chỉ số nào trên bảng đó?

— Gaius

Xin chào, xin vui lòng xem chỉnh sửa.

— mvbl fst

Hmm, điều này thật khó chịu vì điều này rất dễ chẩn đoán trong Oracle, bạn chỉ cần đặt 10046 dấu vết cấp 12 và nó sẽ cho bạn biết chính xác những gì nó đang làm. Tôi sẽ có thêm một chút suy nghĩ về nó.

— Gaius

Tôi đang gặp vấn đề tương tự với bảng InnoDB, tôi nghĩ rằng nó có liên quan đến sự gia tăng. Tôi đang làm: UPDATE table SET <field>=<field>+1 WHERE <pk_field>=1;Bảng của tôi đơn giản hơn nhiều. Một cách ngẫu nhiên, điều này gây ra lỗi tương tự mà bạn nhận được. Phiên bản của tôi là: 5.1.39. Hôm nay tôi dành một chút thời gian để cố gắng tìm ra nó vì vậy tôi sẽ cập nhật nếu tôi tìm thấy bất cứ điều gì.

Cảm ơn, xin vui lòng cho tôi biết những gì bạn tìm hiểu, chúng tôi vẫn chưa tìm ra điều này.

— mvbl fst

Tôi biết điều này thực sự muộn, nhưng bạn thực sự cần phải nắm bắt đầu ra của TÌNH TRẠNG SHOW Engine INNODB; trong truy vấn đó để xem tại sao nó chờ đợi.

Nếu nó xảy ra rất nhiều trong một thời gian cụ thể, thật dễ dàng để lấy đầu ra đó cứ sau x giây và hy vọng bạn nắm bắt được nó (hoặc có thể tạo ra tải một cách giả tạo).

— RS
nguồn

Tôi muốn nói bình thường hóa cơ sở dữ liệu - và thêm kích thước propper.

Một ảnh duy nhất không cần mang theo tất cả thông tin về album mà nó thuộc về - điều này khóc cho một bảng riêng cho album - và một bảng quan hệ chỉ chứa ánh xạ của photoID <-> albumID áp dụng tương tự - nếu có - cho người chụp (bảng riêng và bảng ánh xạ giữa photoID và nhiếp ảnh giaID

Đầu tiên có thể thấy rằng các truy vấn của bạn trở nên phức tạp hơn một chút nhưng thông tin hiện được phân chia một cách hợp lý và đồng thời bạn sử dụng RDBMS cho những gì nó nói về .. dữ liệu và mối quan hệ của chúng

— đại bàng275
nguồn