web-dev-qa-db-ja.com

16進ダンプに基づいて、ロックを保持しているユーザーを見つけるにはどうすればよいですか?

Diagnosing MySQL InnoDB Locks の記事を読んでいます。 Karl E.Jørgensenが2008年に書いているので、それが有効であるとはわかりません。

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

クエリは切り離されているので、SHOW FULL PROCESSLIST出力から取得します。

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

上記の記事によると、TRANSACTION 20532F16はロックを待機しています。しかし、ご覧のとおり、ここにはいくつかの16進ダンプがあります。ロックを保持するトランザクションを判別するために使用できるのはどれですか?さらに、トランザクション番号がすでに16進数であることがわかります(例:20532EE8)

この 記事は、ヘクスに関する十分な詳細を説明していません。

PS:上記の16進数ダンプ(16進数と10進数の両方)をすべて試しましたが、うまくいきませんでした。


RolandoMySQLDBAへの返信:

テーブルの100,000行をロックするために44KBがどのように必要かについて、 最近の投稿を書きました

11457529行ロックが引き継ぐ... 5MB。

InnoDBバッファープールが十分に大きくない場合、必要な数の行ロックを定義するための十分なリソースがない可能性があります。したがって、 innodb_buffer_pool_size を増やすことをお勧めします。

これが私のバッファプールとメモリです:

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

ご覧のとおり、多くのページが空いています(704307)。他に何かアイデアはありますか?

PS:innotopは、InnoDBロックに関する空の結果を示しています。

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

UPDATE Tue Mar 6 00:16:41 ICT 2012

PS:上記の16進数ダンプ(16進数と10進数の両方)をすべて試しましたが、うまくいきませんでした。

私のSHOW ENGINE INNODB STATUS;には、上記の16進数のトランザクションはありません。

$ 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;;
7
quanta

これは本当に簡単です。 SHOW ENGINE INNODB STATUSは使用せず、information_schema.innodb_locksを使用してください。これが、外部キーを使用してブログ投稿を書いた例です。

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

5
Morgan Tocker

MySQL> = 8.0を使用している人のために、information_schema.innodb_locksperformance_schema.data_locksに移動しました。

このブログ投稿を参照してください: https://dev.mysql.com/doc/refman/8.0/en/innodb-locks-table.html

1
Yuki Inoue