Signification de «verrouillage des verrous mais pas d'attente d'attente» dans le rapport de blocage
À propos de la signification de
locks rec but not gap waitingen TRANSACTION (1), lequel est correct?- Vous avez déjà obtenu le verrouillage de l'espace, en attente du verrouillage de l'index X en cluster?
- Vous avez déjà obtenu le verrouillage de l'index X en cluster, en attente du verrouillage de l'espace?
Il y a 31 lignes dans la transaction (1). Quelle est la signification de ces lignes? Cela représente-t-il un verrouillage de l'écart?
0: len 4; hex 800c20d6; asc ;; .... 29: SQL NULL; 30: SQL NULL;
Dernier rapport DEADLOCK DEADLOCK
LATEST DETECTED DEADLOCK
------------------------
2015-09-25 15:27:24 1b8084000
*** (1) TRANSACTION:
TRANSACTION 5226928, ACTIVE 0 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 31 lock struct(s), heap size 6544, 548 row lock(s)
MySQL thread id 71, OS thread handle 0x1b45be000, query id 4085356 localhost root Creating sort index
SELECT `rpush_notifications`.* FROM `rpush_notifications` WHERE (processing = 0 AND delivered = 0 AND failed = 0 AND (deliver_after IS NULL OR deliver_after < '2015-09-25 07:27:24')) ORDER BY created_at ASC LIMIT 100 FOR UPDATE
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 10287 page no 10901 n bits 152 index `PRIMARY` of table `ct_development`.`rpush_notifications` trx id 5226928 lock_mode X locks rec but not gap waiting
Record lock, heap no 78 PHYSICAL RECORD: n_fields 31; compact format; info bits 0
0: len 4; hex 800c20d6; asc ;;
1: len 6; hex 0000004fc1aa; asc O ;;
2: len 7; hex 4c0000027b07fe; asc L { ;;
3: len 30; hex 52707573683a3a436c69656e743a3a4163746976655265636f72643a3a41; asc Rpush::Client::ActiveRecord::A; (total 47 bytes);
4: SQL NULL;
5: len 30; hex 373838653836643365666465626262626639633464363261626433366132; asc 788e86d3efdebbbbf9c4d62abd36a2; (total 64 bytes);
6: len 7; hex 64656661756c74; asc default;;
7: len 7; hex 6869206d6f6d21; asc hi mom!;;
8: len 13; hex 7b22666f6f223a22626172227d; asc {"foo":"bar"};;
9: len 4; hex 80015180; asc Q ;;
10: len 1; hex 80; asc ;;
11: SQL NULL;
12: len 1; hex 81; asc ;;
13: len 5; hex 99973276d8; asc 2v ;;
14: SQL NULL;
15: len 0; hex ; asc ;;
16: SQL NULL;
17: len 5; hex 99973276d6; asc 2v ;;
18: len 5; hex 99973276d6; asc 2v ;;
19: len 1; hex 80; asc ;;
20: SQL NULL;
21: len 1; hex 80; asc ;;
22: SQL NULL;
23: len 4; hex 80000002; asc ;;
24: len 4; hex 80000000; asc ;;
25: SQL NULL;
26: SQL NULL;
27: len 1; hex 80; asc ;;
28: SQL NULL;
29: SQL NULL;
30: SQL NULL;
*** (2) TRANSACTION:
TRANSACTION 5226922, ACTIVE 0 sec updating or deleting, thread declared inside InnoDB 0
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 1
MySQL thread id 1446, OS thread handle 0x1b8084000, query id 4085345 localhost root updating
UPDATE `rpush_notifications` SET processing = 0, delivered = 0, delivered_at = NULL, failed = 1, failed_at = '2015-09-25 07:27:24', error_code = NULL, error_description = '' WHERE `rpush_notifications`.`id` IN (794838, 794839)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 10287 page no 10901 n bits 152 index `PRIMARY` of table `ct_development`.`rpush_notifications` trx id 5226922 lock_mode X locks rec but not gap
Record lock, heap no 78 PHYSICAL RECORD: n_fields 31; compact format; info bits 0
0: len 4; hex 800c20d6; asc ;;
1: len 6; hex 0000004fc1aa; asc O ;;
2: len 7; hex 4c0000027b07fe; asc L { ;;
3: len 30; hex 52707573683a3a436c69656e743a3a4163746976655265636f72643a3a41; asc Rpush::Client::ActiveRecord::A; (total 47 bytes);
4: SQL NULL;
5: len 30; hex 373838653836643365666465626262626639633464363261626433366132; asc 788e86d3efdebbbbf9c4d62abd36a2; (total 64 bytes);
6: len 7; hex 64656661756c74; asc default;;
7: len 7; hex 6869206d6f6d21; asc hi mom!;;
8: len 13; hex 7b22666f6f223a22626172227d; asc {"foo":"bar"};;
9: len 4; hex 80015180; asc Q ;;
10: len 1; hex 80; asc ;;
11: SQL NULL;
12: len 1; hex 81; asc ;;
13: len 5; hex 99973276d8; asc 2v ;;
14: SQL NULL;
15: len 0; hex ; asc ;;
16: SQL NULL;
17: len 5; hex 99973276d6; asc 2v ;;
18: len 5; hex 99973276d6; asc 2v ;;
19: len 1; hex 80; asc ;;
20: SQL NULL;
21: len 1; hex 80; asc ;;
22: SQL NULL;
23: len 4; hex 80000002; asc ;;
24: len 4; hex 80000000; asc ;;
25: SQL NULL;
26: SQL NULL;
27: len 1; hex 80; asc ;;
28: SQL NULL;
29: SQL NULL;
30: SQL NULL;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 10287 page no 7992 n bits 1480 index `index_rpush_notifications_multi` of table `ct_development`.`rpush_notifications` trx id 5226922 lock_mode X locks rec but not gap waiting
Record lock, heap no 1279 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 1; hex 80; asc ;;
1: len 1; hex 80; asc ;;
2: len 4; hex 800c20d6; asc ;;
*** WE ROLL BACK TRANSACTION (2)
Schéma de table
CREATE TABLE `rpush_notifications` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`type` varchar(255) NOT NULL,
`badge` int(11) DEFAULT NULL,
`device_token` varchar(64) DEFAULT NULL,
`sound` varchar(255) DEFAULT 'default',
`alert` varchar(255) DEFAULT NULL,
`data` text,
`expiry` int(11) DEFAULT '86400',
`delivered` tinyint(1) NOT NULL DEFAULT '0',
`delivered_at` datetime DEFAULT NULL,
`failed` tinyint(1) NOT NULL DEFAULT '0',
`failed_at` datetime DEFAULT NULL,
`error_code` int(11) DEFAULT NULL,
`error_description` text,
`deliver_after` datetime DEFAULT NULL,
`created_at` datetime DEFAULT NULL,
`updated_at` datetime DEFAULT NULL,
`alert_is_json` tinyint(1) DEFAULT '0',
`collapse_key` varchar(255) DEFAULT NULL,
`delay_while_idle` tinyint(1) NOT NULL DEFAULT '0',
`registration_ids` mediumtext,
`app_id` int(11) NOT NULL,
`retries` int(11) DEFAULT '0',
`uri` varchar(255) DEFAULT NULL,
`fail_after` datetime DEFAULT NULL,
`processing` tinyint(1) NOT NULL DEFAULT '0',
`priority` int(11) DEFAULT NULL,
`url_args` text,
`category` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `index_rapns_notifications_multi` (`app_id`,`delivered`,`failed`,`deliver_after`),
KEY `index_rpush_notifications_multi` (`delivered`,`failed`)
) ENGINE=InnoDB AUTO_INCREMENT=337371 DEFAULT CHARSET=utf8;
Question 1: InnoDB essaie d'obtenir un verrou exclusif sur la ligne (c'est en fait un verrou sur l'enregistrement d'index clusterisé, le PK), mais pas le espace environnant (un verrou d'écart). Vous pouvez en savoir plus sur les verrous d'enregistrements et d'écarts ici: https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-record-locks
La demande de verrouillage exclusif provient de la clause "for update" ajoutée à l'instruction SELECT. Gardez à l'esprit que lorsque vous utilisez le niveau d'isolement en lecture répétable (sélectionnez @@ session.tx_isolation), qui est la valeur par défaut, le verrou exclusif sera placé sur chaque ligne - examiné pour le SELECT, pas juste ceux qui sont retournés (ceux qui correspondent à tous les prédicats de la clause WHERE). Ainsi, vous pourrez peut-être réduire le nombre de lignes examinées, et donc les verrous détenus, ce qui réduira considérablement les risques de conflits, en utilisant un index composite sur: traitement, remis, échoué, livrer_après
Je ne sais pas quelle est la cardinalité (nombre de valeurs uniques) pour ces colonnes, mais vous devez généralement les répertorier dans l'index composite de la cardinalité la plus élevée à la plus faible.
Question 2: 31 est le nombre de champs dans l'enregistrement d'index (ou la ligne, logiquement) sur lesquels il essaie/attend d'obtenir un verrou exclusif. InnoDB utilise un PK en cluster, donc les enregistrements de l'index en cluster (le PK) contiennent les champs pour chaque colonne définie par l'utilisateur - 29 champs dans le cas de votre table Push_notifications: catégorie id ... - et il y a toujours deux autres champs internes pour chaque table InnoDB: un champ d'ID de transaction de 6 octets et un champ de pointeur de rouleau de 7 octets (ceux-ci sont utilisés pour MVCC). Ainsi, les 31 éléments que vous voyez répertoriés sont les champs contenus dans l'enregistrement d'index (ou la ligne, logiquement) sur lesquels nous attendons le verrouillage.
Juste pour info: Vous pouvez obtenir d'autres pannes des verrous InnoDB en utilisant les nouvelles tables Information_Schema dans 5.6+: https://dev.mysql.com /doc/refman/5.7/en/innodb-information-schema-transactions.html
Il y a aussi d'excellents rapports dans le nouveau schéma SYS, qui est inclus avec le serveur dans MySQL 5.7+ (n'a pas encore tout à fait fait son chemin dans le manuel en ligne): https://github.com/MarkLeith/mysql-sys # innodb_lock_waits - xinnodb_lock_waits
Vous pouvez installer manuellement le dernier schéma SYS dans MySQL 5.6, si cela vous intéresse: https://github.com/MarkLeith/mysql-sys/blob/master/sys_56.sql
Pour plus d'informations à ce sujet: http://www.slideshare.net/Leithal/performance-schema-and-sys-schema-in-mysql-57
J'espère que ça aide!