Làm thế nào tôi có thể tìm thấy ai giữ khóa dựa trên hex-dump?


7

Tôi đã đọc bài viết Chẩn đoán MySQL InnoDB Khóa . Karl E. Jørgensen viết vào năm 2008 vì vậy tôi đồng ý rằng nó có hiệu lực.

Tôi muốn cung cấp một đoạn của 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

Truy vấn bị cắt rời để tôi lấy nó từ SHOW FULL PROCESSLISTđầu ra:

*************************** 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

Theo bài viết trên, GIAO DỊCH 20532F16 đang chờ khóa. Nhưng như bạn có thể thấy, có một vài hex-dump ở đây. Cái nào có thể được sử dụng để xác định giao dịch giữ khóa? Hơn nữa, tôi thấy số giao dịch đã ở dạng thập lục phân (ví dụ: 20532EE8)

Bài viết này không giải thích đủ chi tiết về hex.

PS: Tôi đã thử tất cả các hex-dump ở trên (cả hex và thập phân) nhưng không có may mắn.


Trả lời RolandoMySQLDBA:

Tôi đã viết một bài đăng gần đây về cách cần 44KB để khóa 100.000 hàng trên bàn

11457529 khóa hàng chỉ mất hơn ... 5MB.

Nếu nhóm bộ đệm InnoDB của bạn không đủ lớn, bạn có thể không có đủ tài nguyên để xác định bao nhiêu khóa hàng nếu cần. Do đó, tôi khuyên bạn nên tăng innodb_buffer_pool_size của bạn .

Đây là vùng đệm và bộ nhớ của tôi:

----------------------
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]

Như bạn có thể thấy, tôi có rất nhiều trang miễn phí (704307). Bạn có bất cứ ý tưởng khác?

PS: innotophiển thị kết quả trống về Khóa InnoDB:

_________________________________ InnoDB Locks __________________________________
CXN  ID  Type  Waiting  Wait  Active  Mode  DB  Table  Index  Ins Intent  Special

CẬP NHẬT Thứ Sáu ngày 6 tháng 3 00:16:41 CNTT 2012

PS: Tôi đã thử tất cả các hex-dump ở trên (cả hex và thập phân) nhưng không có may mắn.

Không có giao dịch với hex trên trong tôi 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;;

Câu trả lời:


5

Điều này thực sự dễ dàng bây giờ. Không sử dụng SHOW ENGINE INNODB STATUS, sử dụng information_schema.innodb_locks. Dưới đây là một ví dụ tôi đã viết một bài đăng trên blog với các khóa ngoại:

http://www.mysqlperformanceblog.com/2010/09/20/instrumentation-and-the-cost-of-forign-keys/


Như tôi đã đề cập trong này chủ đề, tôi thấy điều này trên rất hữu ích liên kết . Nhưng tôi không nhận được gì từ bảng này khi cơ sở dữ liệu của tôi bị khóa. Bạn nghĩ sao?
lượng tử

1
Bảng thực sự được đặt tên sai. Innodb_locks chứa lock_waits, không khóa. Tôi đã không đọc tuyên bố của bạn khi nhận xét ban đầu - nhưng bạn cần thay đổi thành sao chép dựa trên hàng cam kết + đã đọc. Bạn đang khóa nhiều hàng hơn bạn nghĩ. Xem phản hồi của tôi ở đây trên SO: stackoverflow.com/questions/5694658/ từ
Morgan Tocker

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.