Bế tắc MySQL InnoDB cho 2 truy vấn chèn đơn giản


10

Tôi có một bế tắc cho hai truy vấn chèn này:

insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition, nextClubId, account_id) values (0, '2014-12-23 15:47:11.596', 180, 4, 181, 561)

insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition, nextClubId, account_id) values (0, '2014-12-23 15:47:11.611', 180, 4, 181, 563)

Đây là Trạng thái InnoDB:

------------------------
LATEST DETECTED DEADLOCK
------------------------
2014-12-23 15:47:11 1f4c
*** (1) TRANSACTION:
TRANSACTION 19896526, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1248, 3 row lock(s), undo log entries 1
MySQL thread id 17988, OS thread handle 0x17bc, query id 5701353 localhost 127.0.0.1 root update
insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition,  nextClubId, account_id) values (0, '2014-12-23 15:47:11.596', 180, 4, 181, 561)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 49735 page no 4 n bits 72 index `UK_cagoa3q409gsukj51ltiokjoh` of   table `db`.`playerclub` trx id 19896526 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

*** (2) TRANSACTION:
TRANSACTION 19896542, ACTIVE 0 sec inserting, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
5 lock struct(s), heap size 1248, 3 row lock(s), undo log entries 1
MySQL thread id 17979, OS thread handle 0x1f4c, query id 5701360 localhost 127.0.0.1    root update
insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition,   nextClubId, account_id) values (0, '2014-12-23 15:47:11.611', 180, 4, 181, 563)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 49735 page no 4 n bits 72 index `UK_cagoa3q409gsukj51ltiokjoh` of   table `db`.`playerclub` trx id 19896542 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 49735 page no 4 n bits 72 index `UK_cagoa3q409gsukj51ltiokjoh` of    table `db`.`playerclub` trx id 19896542 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

*** WE ROLL BACK TRANSACTION (2)

Khóa foriegn duy nhất trên bảng này là "account_id".

Có ý kiến ​​gì không?

EDIT: Đây là thông tin PlayerClub của tôi:

CREATE TABLE `PlayerClub` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `modifiedBy` bigint(20) DEFAULT NULL,
  `timeCreated` datetime NOT NULL,
  `account_id` bigint(20) DEFAULT NULL,
  `currentClubId` bigint(20) DEFAULT NULL,
  `endingLevelPosition` int(11) NOT NULL,
  `nextClubId` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `UK_cagoa3q409gsukj51ltiokjoh` (`account_id`),
  KEY `FK_cagoa3q409gsukj51ltiokjoh` (`account_id`),
  CONSTRAINT `FK_cagoa3q409gsukj51ltiokjoh` FOREIGN KEY (`account_id`) REFERENCES   `PlayerAccount` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=latin1

Bạn đã làm gì khác trong mỗi giao dịch trước khi gặp bế tắc?
Michael - sqlbot

Điều gì nếu bạn phát hành cam kết sau mỗi lần chèn và sau đó thử? Hãy cho chúng tôi biết ..
Nawaz Sohail

SHOW CREATE TABLE PlayerClubxin vui lòng. Điều này thường liên quan đến các chỉ số.
Jehad Keriaki

Câu trả lời:


13

ĐÂY LÀ SỰ THẬT

Dưới đây là hai CHỨNG MINH

insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition, nextClubId, account_id) values (0, '2014-12-23 15:47:11.596', 180, 4, 181, 561)
insert into PlayerClub (modifiedBy, timeCreated, currentClubId, endingLevelPosition, nextClubId, account_id) values (0, '2014-12-23 15:47:11.611', 180, 4, 181, 563)

Đây là hai dòng từ của bạn SHOW ENGINE INNODB STATUS\G

RECORD LOCKS space id 49735 page no 4 n bits 72 index `UK_cagoa3q409gsukj51ltiokjoh` of   table `db`.`playerclub` trx id 19896526 lock_mode X insert intention waiting
RECORD LOCKS space id 49735 page no 4 n bits 72 index `UK_cagoa3q409gsukj51ltiokjoh` of   table `db`.`playerclub` trx id 19896542 lock_mode X

QUAN SÁT

Bạn đang thực hiện một INSERT với hai tài khoản khác nhau: 561 và 563.

Chúng là duy nhất và không nên có vấn đề, phải không? SAI LẦM !!!

Do Chỉ số cụm của InnoDB, vẫn có thể có bế tắc. Tại sao ?

Nhìn lại hai CHỨNG MINH của bạn. Các PRIMARY KEYid vào trong không xác định. Nó phải được tạo tự động. Bất kỳ khóa nào khác ngoài KHÓA CHÍNH (duy nhất hoặc không duy nhất) sẽ được đính kèm KHÓA CHÍNH.

Vui lòng lưu ý Tài liệu MySQL về cách Chỉ mục phụ và Khóa chính được đan xen :

Tất cả các chỉ mục khác với chỉ mục được nhóm được gọi là chỉ mục phụ. Trong InnoDB, mỗi bản ghi trong một chỉ mục phụ chứa các cột khóa chính cho hàng, cũng như các cột được chỉ định cho chỉ mục phụ. InnoDB sử dụng giá trị khóa chính này để tìm kiếm hàng trong chỉ mục được nhóm.

Nếu khóa chính dài, các chỉ mục phụ sử dụng nhiều không gian hơn, do đó, có lợi khi có khóa chính ngắn.

Mặc dù bạn đang chèn account_id 561 và 563, dưới phần mềm bạn sẽ chèn 561-(id)563-(id)vào UK_cagoa3q409gsukj51ltiokjohchỉ mục. Việc PRIMARY KEYtrở thành nút cổ chai vì Chỉ số phụ phải đợi cho đến khi idcột được tự động tạo.

SỰ GIỚI THIỆU

Bạn có một bảng có hai khóa ứng viên

  • PRIMARY KEY trên id
  • UNIQUE KEY trên UK_cagoa3q409gsukj51ltiokjoh

Vì cả hai đều BIGINT, bạn có thể tăng hiệu suất và có một PlayerClubbảng nhỏ hơn bằng cách loại bỏ idvà vẫn duy trì tính duy nhất vì UK_cagoa3q409gsukj51ltiokjohcũng như tránh tình trạng bế tắc này.


1
Chỉ sau khi xóa Khóa foriegn duy nhất trên bảng này là "account_id" xảy ra dừng bế tắc.
Đô thị
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.