Ich habe den Artikel Diagnose von MySQL InnoDB-Sperren gelesen . Karl E. Jørgensen schreibt über 2008, daher bin ich der Meinung, dass dies tatsächlich der Fall ist.
Ich möchte einen Ausschnitt aus dem SHOW ENGINE INNODB STATUS
:
---TRANSACTION 20532F16, ACTIVE 386 sec starting index read
mysql tables in use 6, locked 6
LOCK WAIT 2 lock struct(s), heap size 1248, 1 row lock(s)
MySQL thread id 96238, query id 81681916 192.168.6.31 thanhnt updating
DELETE FROM `v3_zone_date`
WHERE `dt` = NAME_CONST('_currDate',_latin1'2012-03-02' COLLATE 'latin1_swedish_ci')
------- TRX HAS BEEN WAITING 8 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 482988 page no 6 n bits 360 index `GEN_CLUST_INDEX` of table `reportingdb`.`v3_zone_date` /* Partition `pcurrent_201232` */ trx id 20532F16 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 13; compact format; info bits 0
0: len 6; hex 000237440e77; asc 7D w;;
1: len 6; hex 0000204f2acb; asc O* ;;
2: len 7; hex e6000480120110; asc ;;
3: len 3; hex 8f5340; asc S@;;
4: len 2; hex 83d4; asc ;;
5: len 3; hex 814f42; asc OB;;
6: len 3; hex 000000; asc ;;
7: len 3; hex 000000; asc ;;
8: len 3; hex 800000; asc ;;
9: len 3; hex 000001; asc ;;
10: len 3; hex 000000; asc ;;
11: len 3; hex 8fb862; asc b;;
12: len 2; hex 0000; asc ;;
------------------
---TRANSACTION 20532EE8, ACTIVE 437 sec fetching rows, thread declared inside InnoDB 236
mysql tables in use 22, locked 22
24944 lock struct(s), heap size 3586488, 11457529 row lock(s)
MySQL thread id 97447, query id 81504647 event_scheduler Copying to tmp table
Die Abfrage ist getrennt, damit ich sie aus der SHOW FULL PROCESSLIST
Ausgabe erhalte :
*************************** 18. row ***************************
Id: 97447
User: thanhnt
Host: 192.168.6.31
db: reportingdb
Command: Connect
Time: 423
State: Copying to tmp table
Info: UPDATE `selfserving_banner_zone` A,( SELECT B.`bannerid`,C.`zoneid`,ROUND(SUM(C.`realclick`)*100/SUM(C.`totalview`),5) CTR
FROM `ox_campaigns` A
INNER JOIN `ox_banners` B ON B.`campaignid`= A.`campaignid`
INNER JOIN `v3_zone_date` C ON C.`campaignid` = B.`campaignid` AND B.`bannerid` = C.bannerid
WHERE A.`revenue_type` = 5 AND C.`dt` BETWEEN DATE_SUB( NAME_CONST('_currdate',_latin1'2012-03-02' COLLATE 'latin1_swedish_ci'),INTERVAL 1 DAY) AND NAME_CONST('_currdate',_latin1'2012-03-02' COLLATE 'latin1_swedish_ci') AND C.totalview >0 AND A.isExpired NOT IN (1,2)
AND A.deleted = 0 AND B.deleted = 0 AND CURRENT_DATE BETWEEN B.`activate` AND B.`expire` AND A.status = 1 AND B.status = 1 AND C.`realclick` > 0
GROUP BY B.`bannerid`,C.`zoneid`) B
SET A.`ctr` = B.CTR WHERE A.`bannerid` = B.bannerid AND A.`zoneid` = B.zoneid
Gemäß dem obigen Artikel wartet TRANSACTION 20532F16 auf eine Sperre. Aber wie Sie sehen können, gibt es hier ein paar Hex-Dumped. Mit welcher kann die Transaktion ermittelt werden, die die Sperre enthält? Außerdem sehe ich, dass die Transaktionsnummer bereits hexadezimal ist (Beispiel: 20532EE8)
Dieser Artikel erklärt nicht genug Details über das Hex.
PS: Ich habe alle oben genannten hexadezimalen Werte (sowohl hexadezimal als auch dezimal) ausprobiert, aber kein Glück.
Antwort auf RolandoMySQLDBA:
11457529 Reihenschloss (e) übernehmen nur ... 5MB.
Wenn Ihr InnoDB-Pufferpool nicht groß genug ist, verfügen Sie möglicherweise nicht über genügend Ressourcen, um so viele Zeilensperren wie erforderlich zu definieren. Daher würde ich empfehlen, Ihre innodb_buffer_pool_size zu erhöhen .
Hier ist mein Pufferpool und Speicher:
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 21978152960; in additional pool allocated 0
Dictionary memory allocated 2636907
Buffer pool size 1310712
Free buffers 704307
Database pages 589697
Old database pages 217517
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 361757, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 365924, created 666845, written 1151187
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s
LRU len: 589697, unzip_LRU len: 0
I/O sum[32]:cur[0], unzip sum[0]:cur[0]
Wie Sie sehen können, habe ich viele Seiten frei (704307). Hast du noch andere Ideen?
PS: innotop
Zeigt das leere Ergebnis zu InnoDB Locks an:
_________________________________ InnoDB Locks __________________________________
CXN ID Type Waiting Wait Active Mode DB Table Index Ins Intent Special
UPDATE Di Mar 6 00:16:41 ICT 2012
PS: Ich habe alle oben genannten hexadezimalen Werte (sowohl hexadezimal als auch dezimal) ausprobiert, aber kein Glück.
Es gibt keine Transaktion mit dem obigen Hex in meinem SHOW ENGINE INNODB STATUS;
:
$ egrep -i '8f5340|814f42|8fb862' innodb.status_2012-03-02
3: len 3; hex 8f5340; asc S@;;
5: len 3; hex 814f42; asc OB;;
11: len 3; hex 8fb862; asc b;;
Für diejenigen, die MySQL> = 8.0 verwenden, wird das
information_schema.innodb_locks
jetzt auf verschobenperformance_schema.data_locks
.Verweisen Sie auf diesen Blog-Beitrag: https://dev.mysql.com/doc/refman/8.0/en/innodb-locks-table.html
quelle