설명 할 수없는 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중 관련 잠금도 표시되지 않습니다. 이 문제는 내 응용 프로그램 서버 로그 ( Mysql::Error: Lock wait timeout exceededmysql-slow 로그의 각 해당 항목과 관련된 오류 를 표시)에 따라 5 가지 이상의 다른 테이블에 영향을 미치는 것으로 보입니다 .

여기서 어디로 갈지에 대한 아이디어가 있습니까? 나는 모든 방향에서 막 다른 길을 치고있다. 감사.

편집하다:

테이블`사진`(
  `id` int (11) NOT NULL 자동 _ 증가,
  `type` varchar (255) NOT NULL,
  `photo_album_id` int (11) NOT NULL,
  `user_id` int (11) NOT NULL,
  `title` varchar (255) 기본 '무제',
  `설명`텍스트,
  `credit` varchar (255) 기본 NULL,
  `photo_file_name` varchar (255) 기본 NULL,
  `photo_content_type` varchar (255) 기본 NULL,
  `photo_file_size` int (11) 기본 NULL,
  `photo_updated_at` 날짜 / 시간 기본 NULL,
  `position` int (11) 기본값 '0',
  `views` int (11) 기본값 '0',
  `폴더`varchar (255) 기본 NULL,
  `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) 기본 NULL,
  `audio_updated_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_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`),
  키`index_photos_on_user_id` (`user_id`)
) ENGINE = InnoDB AUTO_INCREMENT = 42830 기본 문자셋 = utf8

— mvbl fst
소스

바보 같은 질문 : 그 테이블에 어떤 인덱스가 있습니까?

— Gaius

안녕, 편집을 참조하십시오.

— mvbl fst

흠, 이것은 오라클에서 진단하기 쉽기 때문에 성가시다. 추적 레벨 12를 10046으로 설정하면 정확히 무엇을하고 있는지 알 수있다 . 그것에 대해 좀 더 생각해 볼게요.

— Gaius

InnoDB 테이블과 비슷한 문제가 있는데, 증가와 관련이 있다고 생각합니다. 나는하고있다 : UPDATE table SET <field>=<field>+1 WHERE <pk_field>=1;내 테이블은 훨씬 간단합니다. 무작위로 이것은 동일한 오류를 발생시킵니다. 내 버전은 5.1.39입니다. 나는 오늘 그것을 알아 내려고 노력하는 데 시간을 보내고 있으므로 아무것도 발견하면 업데이트 할 것입니다.

고마워, pls는 당신이 무엇을 발견했는지 알려주십시오, 우리는 여전히 이것을 알아 내지 못했습니다.

— mvbl fst

나는 이것이 정말로 늦다는 것을 알고 있지만, 당신은 실제로 SHOW ENGINE INNODB STATUS의 결과를 캡처해야합니다. 해당 쿼리 중에 왜 대기 중인지 확인할 수 있습니다.

특정 시간 동안 많은 일이 발생하면 x 초마다 출력을 잡아서 캡처하기를 바랍니다 (또는 인위적으로 부하를 생성하기를 바랍니다).

— RS
소스

데이터베이스를 정규화한다고 말하고 propper indizes를 추가하십시오.

단일 사진은 자신이 속한 앨범에 대한 모든 정보를 전달할 필요가 없습니다. 앨범에 대한 별도의 테이블이 필요합니다. 포함 된 경우 photoID <-> albumID의 매핑 만 포함 된 관계형 테이블이 사진사에게 적용됩니다. (photoID와 photographerID 사이의 별도 테이블과 매핑 테이블

처음에는 쿼리가 조금 더 복잡해졌지만 정보는 논리적으로 나뉘어져 있으며 동시에 RDBMS를 사용하여 .. 데이터 및 관계에 대한 정보를 얻을 수 있습니다.

— 독수리 275
소스