锁大全与 GDB调试
生活随笔
收集整理的這篇文章主要介紹了
锁大全与 GDB调试
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
1.innodb_lock_monitor：打開鎖信息的方式
mysql> create table innodb_lock_monitor(id int) engine=InnoDB; Query OK, 0 rows affected, 1 warning (2.29 sec)
mysql> begin work; Query OK, 0 rows affected (0.00 sec)
mysql> update t set val = val + 1 where id = 1; Query OK, 1 row affected (0.07 sec) Rows matched: 1 Changed: 1 Warnings: 0
mysql> select sleep(15); -- we need to give it some time to run the monitor ... mysql> rollback work; Query OK, 0 rows affected (0.06 sec)
mysql> drop table innodb_lock_monitor;
鎖信息會出現在 the error log The output from innodb_lock_monitor in the error log
2.通過變量打開鎖信息方式
SET global innodb_status_output=ON; -- enable standard monitor SET global innodb_status_output_locks=ON; -- enable extra locks info SET global innodb_status_output_locks=OFF; -- disable extra locks info SET global innodb_status_output=OFF; -- disable standard monitor information_schema.innodb_trx： 查看每個事物 鎖相關信息
mysql> select * from information_schema.innodb_trx\G *************************** 1. row *************************** trx_id: 64049 -- may be not created if read only & non-locking (?) trx_state: LOCK WAIT -- RUNNING, LOCK WAIT, ROLLING BACK or COMMITTING trx_started: 2015-03-30 07:14:53 trx_requested_lock_id: 64049:498:3:4 -- not NULL if waiting. See INNODB_LOCK.LOCK_ID trx_wait_started: 2015-03-30 07:14:53 trx_weight: 2 -- depends on num. of rows changed and locked, nontran tables trx_mysql_thread_id: 6 -- See Id in PROCESSLIST trx_query: insert into t values(6,8) -- current query executed (1024 utf8) trx_operation_state: inserting -- see thread states... trx_tables_in_use: 1 trx_tables_locked: 1 -- tables with records locked trx_lock_structs: 2 -- number of lock structures trx_lock_memory_bytes: 360 -- memory for lock structures trx_rows_locked: 1 -- approx., may include delete-marked non visible trx_rows_modified: 0 -- rows modified or inserted trx_concurrency_tickets: 0 -- these columns are properly explained in the manual trx_isolation_level: REPEATABLE READ trx_unique_checks: 1 trx_foreign_key_checks: 1 trx_last_foreign_key_error: NULL -- varchar(256) utf8 trx_adaptive_hash_latched: 0 trx_adaptive_hash_timeout: 10000 trx_is_read_only: 0 trx_autocommit_non_locking: 0 -- non-locking SELECT in autocommit mode -- we skip this call protected by sys_mutex: -- trx->id = trx_sys_get_new_trx_id(); (trx_id = 0) information_schema.innodb_locks：查看innodb 鎖信息
mysql> select * from information_schema.innodb_locks\G *************************** 1. row *************************** lock_id: 64049:498:3:4 -- trx id:space no:page no:heap no or trx_id:table id lock_trx_id: 64049 -- join with INNODB_TRX on TRX_ID to get details lock_mode: S -- row->lock_mode = lock_get_mode_str(lock) lock_type: RECORD -- row->lock_type = lock_get_type_str(lock) lock_table: `test`.`t` -- lock_get_table_name(lock).m_name ... lock_index: PRIMARY -- index name for record lock or NULL lock_space: 498 -- space no for record lock or NULL lock_page: 3 -- page no for record lock or NULL lock_rec: 4 -- heap no for record lock or NULL lock_data: 6 -- key values for index, supremum/infimum pseudo-record, -- or NULL (table lock or page is not in buf. pool) -- read fill_innodb_locks_from_cache() in i_s.cc, see trx0i_s.cc also requesting_trx_id: 69360 -- join INNODB_TRX on TRX_ID requested_lock_id: 69360:507:3:8 -- join INNODB_LOCKS on LOCK_ID blocking_trx_id: 69355 -- ... blocking_lock_id: 69355:507:3:8 1 row in set (0.00 sec) 查看相互阻塞信息
SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, left(r.trx_query,20) waiting_query, -- this is real concat(concat(lw.lock_type, ' '), lw.lock_mode) waiting_for_lock, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, left(b.trx_query,20) blocking_query, -- this is just current concat(concat(lb.lock_type, ' '), lb.lock_mode) blocking_lock FROM information_schema.innodb_lock_waits w INNER JOIN information_schema.innodb_trx b ON b.trx_id = w. blocking_trx_id INNER JOIN information_schema.innodb_trx r ON r.trx_id = w. requesting_trx_id INNER JOIN information_schema.innodb_locks lw ON lw.lock_trx_id = r. trx_id INNER JOIN information_schema.innodb_locks lb ON lb.lock_trx_id = b. trx_id;
mysql> select * from information_schema.innodb_lock_waits\G *************************** 1. row *************************** requesting_trx_id: 69360 -- join INNODB_TRX on TRX_ID requested_lock_id: 69360:507:3:8 -- join INNODB_LOCKS on LOCK_ID blocking_trx_id: 69355 -- ... blocking_lock_id: 69355:507:3:8 1 row in set (0.00 sec)
KILL 2
mysql> begin; Query OK, 0 rows affected (0.00 sec)mysql> select * from rr where a =1 for update; +------+------+------+------+------+------+ | a | xx | xxx | xxxx | zz | rr | +------+------+------+------+------+------+ | 1 | NULL | NULL | NULL | NULL | NULL | +------+------+------+------+------+------+ 1 row in set (0.01 sec)
(gdb) p *(trx_sys->rw_trx_list->start->lock->trx_locks->start)
$1 = {trx = 0x23e9d68, trx_locks = {prev = 0x0, next = 0x23ea340}, type_mode = 17, hash = 0x8f8f8f8f8f8f8f8f, index = 0x8f8f8f8f8f8f8f8f, un_member = {tab_lock = {table = 0x231be08, locks = {prev = 0x0, next = 0x0}}, rec_lock = {space = 36814344, page_no = 0, n_bits = 0}}} (gdb) p trx_sys->rw_trx_list->start->lock->trx_locks->start->un_member->tab_lock->table->name $2 = 0x22d9ce0 "test/rr"
Breakpoint 1, lock_table (flags=0, table=0x7fb111bb2de8, mode=LOCK_IS,thr=0x7fb118f176f0) at /usr/src/debug/percona-server-5.6.23-72.1/storage/innobase/lock/lock0lock.cc:4426
(gdb) p table->name $1 = 0x7fb12dffe560 "test/t" We can also try to study record locks this way:
(gdb) set $trx_locklist = trx_sys->rw_trx_list->start->lock->trx_locks
(gdb) set $rowlock = $trx_locklist.start->trx_locks->next
(gdb) p *$rowlock $23 = {trx = 0x7fb111f6fc68, trx_locks = {prev = 0x7fb111f774e8, next = 0x0}, type_mode = 34, hash = 0x0, index = 0x7fb118fe7368, un_member = {tab_lock = { table = 0x33, locks = {prev = 0x3, next = 0x50}}, rec_lock = { space = 51, page_no = 3, n_bits = 80}}}
(gdb) x $rowlock + 1 0x7fb111f77578: 00000000000000000000000000111110
Table level AUTO_INC locks
? InnoDB uses a special lock called the table-level AUTO-INC lock for inserts into tables withAUTO_INCREMENT columns. This lock is normally held to the end of the statement (not tothe end of the transaction) ? innodb_autoinc_lock_mode (default 1, no lock when 2) matters a lot since MySQL 5.1 ? The manual is neither correct, nor complete. Check http://bugs.mysql.com/bug.php?id=76563
... TABLE LOCK table `test`.`t` trx id 69136 lock mode AUTO-INC waiting ---TRANSACTION 69135, ACTIVE 20 sec, thread declared inside InnoDB 4997 mysql tables in use 1, locked 1 2 lock struct(s), heap size 360, 0 row lock(s), undo log entries 4 MySQL thread id 3, OS thread handle 0x6010, query id 9 localhost ::1 root User sleep insert into t(val) select sleep(5) from mysql.user TABLE LOCK table `test`.`t` trx id 69135 lock mode AUTO-INC TABLE LOCK table `test`.`t` trx id 69135 lock mode IX Record (row) locks
Record (row) locks
? There are two types of record locks in InnoDB – implicit (logical entity) and explicit
? The explicit record locks are the locks that make use of the global record lock hash table and the lock_t structures (we discussed only them so far)
? Implicit record locks do not have an associated lock_t object allocated. This is calculated based on the ID of the requesting transaction and the transaction ID available in each record
? If a transaction wants to acquire a record lock (implicit or explicit), then it needs to determine whether any other transaction has an implicit lock on the row before checking on the explicit lock
? If a transaction has modified or inserted an index record, then it owns an implicit x-lock on it
? For the clustered index, get the transaction id from the given record. If it is a valid transaction id, then that is the transaction which is holding the implicit exclusive lock on the row.
Implicit and explicit record locks, continued ? On a secondary index record, a transaction has an implicit x-lock also if it has modified the clustered index record, the max trx id of the page where the secondary index record resides is >= trx id of the transaction (or database recovery is running), and there are no explicit non-gaplock requests on the secondary index record.
? In the case of secondary indexes, we need to make use of the undo logs to determine if anytransactions have an implicit exclusive row lock on record.
? Check static trx_t* lock_sec_rec_some_has_impl(rec, index, offsets) for details
? Implicit lock can be and is converted to explicit (for example, when we wait for it) - check staticvoid lock_rec_convert_impl_to_expl(block, rec, index, offsets)
? Implicit record locks do not affect the gaps
? Read comments in the source code and great post by Annamalai:https://blogs.oracle.com/mysqlinnodb/entry/introduction_to_transaction_locks_in
Gap locks ? Gap lock is a on a gap between index records, or a lock on the gap before the first or after the last index record
? Usually gap locks are set as part of next-key lock, but may be set separately!
? Identified as “locks gap before rec”, you can see both “lock_mode X” and “lock mode S”:
RECORD LOCKS space id 513 page no 4 n bits 72 index `c1` of table `test`.`tt` trx id 74693 lock mode S locks gap before rec Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 4; hex 80000001; asc ;; 1: len 4; hex 80000002; asc ;;
? Check http://bugs.mysql.com/bug.php?id=71736 for the test case
? “Gap locking is not needed for statements that lock rows using a unique index to search for a unique row. (This does not include the case that the search condition includes only somecolumns of a multiple-column unique index; in that case, gap locking does occur.)”
? “A gap X-lock has the same effect as a gap S-lock” Next-key locks
? Next-key lock is a is a combination of a record lock on the index record and a gap lock on the gap before the index record
? “By default, InnoDB operates in REPEATABLE READ transaction isolation level and with the innodb_locks_unsafe_for_binlog system variable disabled. In this case, InnoDB uses next-key locks for searches and index scans, which prevents phantom rows”
? Identified as “lock_mode X” or “lock_mode S”: RECORD LOCKS space id 513 page no 3 n bits 72 index `PRIMARY` of table `test`.`tt`
trx id 74693 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;; Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 32 0: len 4; hex 80000001; asc ;; 1: len 6; hex 0000000123c5; asc # ;; 2: len 7; hex 3b00000190283e; asc ; (>;; 3: len 4; hex 80000001; asc ;;
? “A type of gap lock called an insert intention gap lock is set by INSERT operations prior to rowinsertion. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the sameposition within the gap”
? We can use classic example from the manual (added as a fix for http://bugs.mysql.com/bug. php?id=43210) to see insert intention locks
? Identified as “insert intention”: RECORD LOCKS space id 515 page no 3 n bits 72 index `PRIMARY` of table `test`.`t` trx id 74772 lock_mode X insert intention Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0 0: len 8; hex 73757072656d756d; asc supremum;
? Read http://dev.mysql.com/doc/refman/5.7/en/innodb-predicate-locks.html
? As of MySQL 5.7.5, InnoDB supports SPATIAL indexing of columns containing spatial columns
? To enable support of isolation levels for tables with SPATIAL indexes, InnoDB uses predicate locks.
? A SPATIAL index contains minimum bounding rectangle (MBR) values, so InnoDB enforces consistent read on the index by setting a predicate lock on the MBR value used for a query.
? Other transactions cannot insert or modify a row that would match the query condition.
? Read storage/innobase/include/lock0prdt.h (breakpoints on lock_prdt_lock(),
lock_prdt_consistent())
? This is what you can get in gdb: Breakpoint 1, lock_prdt_lock (block=0x7f167f0a2368, prdt=0x7f167dde3280, index=0x7f1658942f10, mode=LOCK_S, type_mode=8192, thr=0x7f1658936240, mtr=0x7f167dde3480) Locks and SAVEPOINTs
? Read http://dev.mysql.com/doc/refman/5.7/en/savepoint.html:
? “The ROLLBACK TO SAVEPOINT statement rolls back a transaction to the named savepoint without terminating the transaction. Modifications that the current transaction made to rows after the savepoint was set are undone in the rollback, but InnoDB does not release the row locks that were stored in memory after the savepoint.”
? “(For a new inserted row, the loc k information is carried by the transaction ID stored in the row; the lock is not separately stored in memory. In this case, the row lock is released in the undo.)” - this is probably the only clear mention of implicit locks
? Simple test case: start transaction; update t set val=5 where id=1; -- 1 row lock here, new data in 1 row savepoint a; update t set val=5 where id=2; -- 2 row locks here, new data in 2 rows select * from t; rollback to savepoint a; select * from t; -- 2 row locks here, new data in 1 row
TABLE LOCK table `test`.`t` trx id 92960 lock mode IX
RECORD LOCKS space id 219 page no 3 n bits 72 index `GEN_CLUST_INDEX` of table `test`.`t` trx id 92960 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 00: len 8; hex 73757072656d756d; asc supremum;;Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 00: len 6; hex 000000179102; asc ;;1: len 6; hex 000000016b20; asc k ;;2: len 7; hex 190000022c1545; asc , E;;3: len 4; hex 80000001; asc ;;4: len 4; hex 80000005; asc ;;Record lock, heap no 3 PHYSICAL RECORD: n_fields 5; compact format; info bits 00: len 6; hex 000000179103; asc ;;1: len 6; hex 000000016b1b; asc k ;;2: len 7; hex 960000014c0110; asc L ;;3: len 4; hex 80000002; asc ;;4: len 4; hex 80000004; asc ;;
鎖并沒有回滾掉
? Read the manual, http://dev.mysql.com/doc/refman/5.6/en/innodb-lock-modes.html ? Intention shared (IS): Transaction T intends to set S locks on individual rows in table t ? Intention exclusive (IX): Transaction T intends to set X locks on those rows ? Before a transaction can acquire an S lock on a row in table t, it must first acquire an IS or stronger lock on t ? Before a transaction can acquire an X lock on a row, it must first acquire an IX lock on t ? Intention locks do not block anything except full table requests (for example, LOCK TABLES ... WRITE or ALTER TABLE)
---TRANSACTION 85539, ACTIVE 15 sec 2 lock struct(s), heap size 360, 5 row lock(s) MySQL thread id 2, OS thread handle 0x7fb142bca700, query id 58 localhost root init show engine innodb status TABLE LOCK table `test`.`t` trx id 85539 lock mode IS RECORD LOCKS space id 53 page no 3 n bits 72 index `PRIMARY` of table `test`.`t` trx id 85539 lock mode S
? These are set by LOCK TABLES READ|WRITE if InnoDB is aware of them
? “In MySQL 5.6, innodb_table_locks = 0 has no effect for tables locked explicitly with LOCK TABLES ... WRITE. It does have an effect for tables locked for read or write by LOCK TABLES ... WRITE implicitly (for example, through triggers) or by LOCK TABLES ... READ. ”
? ALTER TABLE blocks reads (not just writes) at the point where it is ready to install a new version of the table .frm file, discard the old file, and clear outdated table structures from the table and table definition caches. At this point, it must acquire an exclusive (X) lock.
? In the output of SHOW ENGINE INNODB STATUS (when extra locks output is enabled): ---TRANSACTION 85520, ACTIVE 47 sec mysql tables in use 1, locked 1 1 lock struct(s), heap size 360, 0 row lock(s) MySQL thread id 2, OS thread handle 0x7fb142bca700, query id 48 localhost root init show engine innodb status TABLE LOCK table `test`.`t` trx id 85520 lock mode X
? MySQL (since 5.5.3) uses metadata locking to manage concurrent access to database objects and toensure data consistency. Metadata locking applies to schemas, tables and stored routines.
? Session can not perform a DDL statement on a table that is used in an uncompleted explicitly orimplicitly started transaction in another session. This is achieved by acquiring metadata locks ontables used within a transaction and deferring release of those locks until the transaction ends.
? Starting with 5.7.3 you can monitor metadata locks via metadata_locks table in P_S:
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME ='global_instrumentation'; UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME ='wait/lock/metadata/sql/mdl'; select * from performance_schema.metadata_locks\G
? https://dev.mysql.com/doc/refman/5.6/en/metadata-locking.html ? http://www.percona.com/blog/2013/02/01/implications-of-metadata-locking-changes-in-mysql-5-5/ ? http://www.percona.com/blog/2015/04/03/transactional-metadata-locks/ ? http://bugs.mysql.com/bug.php?id=76588
mysql> create table innodb_lock_monitor(id int) engine=InnoDB; Query OK, 0 rows affected, 1 warning (2.29 sec)
mysql> begin work; Query OK, 0 rows affected (0.00 sec)
mysql> update t set val = val + 1 where id = 1; Query OK, 1 row affected (0.07 sec) Rows matched: 1 Changed: 1 Warnings: 0
mysql> select sleep(15); -- we need to give it some time to run the monitor ... mysql> rollback work; Query OK, 0 rows affected (0.06 sec)
mysql> drop table innodb_lock_monitor;
鎖信息會出現在 the error log The output from innodb_lock_monitor in the error log
2.通過變量打開鎖信息方式
SET global innodb_status_output=ON; -- enable standard monitor SET global innodb_status_output_locks=ON; -- enable extra locks info SET global innodb_status_output_locks=OFF; -- disable extra locks info SET global innodb_status_output=OFF; -- disable standard monitor information_schema.innodb_trx： 查看每個事物 鎖相關信息
mysql> select * from information_schema.innodb_trx\G *************************** 1. row *************************** trx_id: 64049 -- may be not created if read only & non-locking (?) trx_state: LOCK WAIT -- RUNNING, LOCK WAIT, ROLLING BACK or COMMITTING trx_started: 2015-03-30 07:14:53 trx_requested_lock_id: 64049:498:3:4 -- not NULL if waiting. See INNODB_LOCK.LOCK_ID trx_wait_started: 2015-03-30 07:14:53 trx_weight: 2 -- depends on num. of rows changed and locked, nontran tables trx_mysql_thread_id: 6 -- See Id in PROCESSLIST trx_query: insert into t values(6,8) -- current query executed (1024 utf8) trx_operation_state: inserting -- see thread states... trx_tables_in_use: 1 trx_tables_locked: 1 -- tables with records locked trx_lock_structs: 2 -- number of lock structures trx_lock_memory_bytes: 360 -- memory for lock structures trx_rows_locked: 1 -- approx., may include delete-marked non visible trx_rows_modified: 0 -- rows modified or inserted trx_concurrency_tickets: 0 -- these columns are properly explained in the manual trx_isolation_level: REPEATABLE READ trx_unique_checks: 1 trx_foreign_key_checks: 1 trx_last_foreign_key_error: NULL -- varchar(256) utf8 trx_adaptive_hash_latched: 0 trx_adaptive_hash_timeout: 10000 trx_is_read_only: 0 trx_autocommit_non_locking: 0 -- non-locking SELECT in autocommit mode -- we skip this call protected by sys_mutex: -- trx->id = trx_sys_get_new_trx_id(); (trx_id = 0) information_schema.innodb_locks：查看innodb 鎖信息
mysql> select * from information_schema.innodb_locks\G *************************** 1. row *************************** lock_id: 64049:498:3:4 -- trx id:space no:page no:heap no or trx_id:table id lock_trx_id: 64049 -- join with INNODB_TRX on TRX_ID to get details lock_mode: S -- row->lock_mode = lock_get_mode_str(lock) lock_type: RECORD -- row->lock_type = lock_get_type_str(lock) lock_table: `test`.`t` -- lock_get_table_name(lock).m_name ... lock_index: PRIMARY -- index name for record lock or NULL lock_space: 498 -- space no for record lock or NULL lock_page: 3 -- page no for record lock or NULL lock_rec: 4 -- heap no for record lock or NULL lock_data: 6 -- key values for index, supremum/infimum pseudo-record, -- or NULL (table lock or page is not in buf. pool) -- read fill_innodb_locks_from_cache() in i_s.cc, see trx0i_s.cc also requesting_trx_id: 69360 -- join INNODB_TRX on TRX_ID requested_lock_id: 69360:507:3:8 -- join INNODB_LOCKS on LOCK_ID blocking_trx_id: 69355 -- ... blocking_lock_id: 69355:507:3:8 1 row in set (0.00 sec) 查看相互阻塞信息
SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, left(r.trx_query,20) waiting_query, -- this is real concat(concat(lw.lock_type, ' '), lw.lock_mode) waiting_for_lock, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, left(b.trx_query,20) blocking_query, -- this is just current concat(concat(lb.lock_type, ' '), lb.lock_mode) blocking_lock FROM information_schema.innodb_lock_waits w INNER JOIN information_schema.innodb_trx b ON b.trx_id = w. blocking_trx_id INNER JOIN information_schema.innodb_trx r ON r.trx_id = w. requesting_trx_id INNER JOIN information_schema.innodb_locks lw ON lw.lock_trx_id = r. trx_id INNER JOIN information_schema.innodb_locks lb ON lb.lock_trx_id = b. trx_id;
mysql> select * from information_schema.innodb_lock_waits\G *************************** 1. row *************************** requesting_trx_id: 69360 -- join INNODB_TRX on TRX_ID requested_lock_id: 69360:507:3:8 -- join INNODB_LOCKS on LOCK_ID blocking_trx_id: 69355 -- ... blocking_lock_id: 69355:507:3:8 1 row in set (0.00 sec)
?
EG1
mysql> SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, left(r.trx_query,20) waiting_query, concat(concat(lw.lock_type, ' '), lw.lock_mode) waiting_for_lock, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, left(b.trx_query,20) blocking_query, concat(concat(lb.lock_type, ' '), lb.lock_mode) blocking_lock FROM information_schema.innodb_lock_waits w INNER JOIN information_schema.innodb_trx b ON b.trx_id = w. blocking_trx_id INNER JOIN information_schema.innodb_trx r ON r.trx_id = w. requesting_trx_id INNER JOIN information_schema.innodb_locks lw ON lw.lock_trx_id = r. trx_id INNER JOIN information_schema.innodb_locks lb ON lb.lock_trx_id = b. trx_id; +----------------+----------------+----------------------+------------------+-----------------+-----------------+----------------+---------------+ | waiting_trx_id | waiting_thread | waiting_query | waiting_for_lock | blocking_trx_id | blocking_thread | blocking_query | blocking_lock | +----------------+----------------+----------------------+------------------+-----------------+-----------------+----------------+---------------+ | 90918 | 4 | select * from rr whe | RECORD X | 90910 | 2 | NULL | RECORD X | +----------------+----------------+----------------------+------------------+-----------------+-----------------+----------------+---------------+ 1 row in set (0.02 sec)KILL 2
?
EG2;
mysql> select * from information_schema.innodb_trx\G *************************** 1. row ***************************trx_id: 90918trx_state: LOCK WAITtrx_started: 2016-07-17 23:26:55trx_requested_lock_id: 90918:203:3:2trx_wait_started: 2016-07-17 23:41:05trx_weight: 2trx_mysql_thread_id: 4trx_query: select * from rr where a =1 for updatetrx_operation_state: starting index readtrx_tables_in_use: 1trx_tables_locked: 1trx_lock_structs: 2trx_lock_memory_bytes: 1248trx_rows_locked: 1trx_rows_modified: 0trx_concurrency_tickets: 0trx_isolation_level: REPEATABLE READtrx_unique_checks: 1trx_foreign_key_checks: 1 trx_last_foreign_key_error: NULLtrx_adaptive_hash_latched: 0trx_adaptive_hash_timeout: 10000trx_is_read_only: 0 trx_autocommit_non_locking: 0 *************************** 2. row ***************************trx_id: 90910trx_state: RUNNINGtrx_started: 2016-07-17 22:53:07trx_requested_lock_id: NULLtrx_wait_started: NULLtrx_weight: 2trx_mysql_thread_id: 2trx_query: NULLtrx_operation_state: NULLtrx_tables_in_use: 0trx_tables_locked: 0trx_lock_structs: 2trx_lock_memory_bytes: 376trx_rows_locked: 2trx_rows_modified: 0trx_concurrency_tickets: 0trx_isolation_level: REPEATABLE READtrx_unique_checks: 1trx_foreign_key_checks: 1 trx_last_foreign_key_error: NULLtrx_adaptive_hash_latched: 0trx_adaptive_hash_timeout: 10000trx_is_read_only: 0 trx_autocommit_non_locking: 0 2 rows in set (0.00 sec) mysql> show processlist; +----+------+-----------+--------------------+---------+------+--------------+----------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+------+-----------+--------------------+---------+------+--------------+----------------------------------------+ | 1 | root | localhost | information_schema | Sleep | 2885 | | NULL | | 2 | root | localhost | test | Sleep | 2989 | | NULL | | 3 | root | localhost | test | Sleep | 2887 | | NULL | | 4 | root | localhost | test | Query | 8 | Sending data | select * from rr where a =1 for update | | 5 | root | localhost | NULL | Query | 0 | init | show processlist | +----+------+-----------+--------------------+---------+------+--------------+----------------------------------------+ mysql> select * from information_schema.innodb_locks\G *************************** 1. row ***************************lock_id: 90918:203:3:2 lock_trx_id: 90918lock_mode: Xlock_type: RECORDlock_table: `test`.`rr`lock_index: GEN_CLUST_INDEXlock_space: 203lock_page: 3lock_rec: 2lock_data: 0x000000179000 *************************** 2. row ***************************lock_id: 90910:203:3:2 lock_trx_id: 90910lock_mode: Xlock_type: RECORDlock_table: `test`.`rr`lock_index: GEN_CLUST_INDEXlock_space: 203lock_page: 3lock_rec: 2lock_data: 0x000000179000 2 rows in set (0.01 sec) mysql> select * from information_schema.innodb_lock_waits\G *************************** 1. row *************************** requesting_trx_id: 90918 requested_lock_id: 90918:203:3:2blocking_trx_id: 90910blocking_lock_id: 90910:203:3:2 1 row in set (0.00 sec)?
?
?
gdb調試鎖
會話1：mysql> begin; Query OK, 0 rows affected (0.00 sec)mysql> select * from rr where a =1 for update; +------+------+------+------+------+------+ | a | xx | xxx | xxxx | zz | rr | +------+------+------+------+------+------+ | 1 | NULL | NULL | NULL | NULL | NULL | +------+------+------+------+------+------+ 1 row in set (0.01 sec)
?
gdb -p `pidof mysqld`(gdb) p *(trx_sys->rw_trx_list->start->lock->trx_locks->start)
$1 = {trx = 0x23e9d68, trx_locks = {prev = 0x0, next = 0x23ea340}, type_mode = 17, hash = 0x8f8f8f8f8f8f8f8f, index = 0x8f8f8f8f8f8f8f8f, un_member = {tab_lock = {table = 0x231be08, locks = {prev = 0x0, next = 0x0}}, rec_lock = {space = 36814344, page_no = 0, n_bits = 0}}} (gdb) p trx_sys->rw_trx_list->start->lock->trx_locks->start->un_member->tab_lock->table->name $2 = 0x22d9ce0 "test/rr"
?
設斷點：
Alternatively, you can set breakpoints on locking related functions: lock_table(), lock_rec_lock(), row_lock_table_autoinc_for_mysql() etc:Breakpoint 1, lock_table (flags=0, table=0x7fb111bb2de8, mode=LOCK_IS,thr=0x7fb118f176f0) at /usr/src/debug/percona-server-5.6.23-72.1/storage/innobase/lock/lock0lock.cc:4426
(gdb) p table->name $1 = 0x7fb12dffe560 "test/t" We can also try to study record locks this way:
(gdb) set $trx_locklist = trx_sys->rw_trx_list->start->lock->trx_locks
(gdb) set $rowlock = $trx_locklist.start->trx_locks->next
(gdb) p *$rowlock $23 = {trx = 0x7fb111f6fc68, trx_locks = {prev = 0x7fb111f774e8, next = 0x0}, type_mode = 34, hash = 0x0, index = 0x7fb118fe7368, un_member = {tab_lock = { table = 0x33, locks = {prev = 0x3, next = 0x50}}, rec_lock = { space = 51, page_no = 3, n_bits = 80}}}
(gdb) x $rowlock + 1 0x7fb111f77578: 00000000000000000000000000111110
Table level AUTO_INC locks
? InnoDB uses a special lock called the table-level AUTO-INC lock for inserts into tables withAUTO_INCREMENT columns. This lock is normally held to the end of the statement (not tothe end of the transaction) ? innodb_autoinc_lock_mode (default 1, no lock when 2) matters a lot since MySQL 5.1 ? The manual is neither correct, nor complete. Check http://bugs.mysql.com/bug.php?id=76563
... TABLE LOCK table `test`.`t` trx id 69136 lock mode AUTO-INC waiting ---TRANSACTION 69135, ACTIVE 20 sec, thread declared inside InnoDB 4997 mysql tables in use 1, locked 1 2 lock struct(s), heap size 360, 0 row lock(s), undo log entries 4 MySQL thread id 3, OS thread handle 0x6010, query id 9 localhost ::1 root User sleep insert into t(val) select sleep(5) from mysql.user TABLE LOCK table `test`.`t` trx id 69135 lock mode AUTO-INC TABLE LOCK table `test`.`t` trx id 69135 lock mode IX Record (row) locks
?
Record (row) locks
?
Implicit and explicit record locks? There are two types of record locks in InnoDB – implicit (logical entity) and explicit
? The explicit record locks are the locks that make use of the global record lock hash table and the lock_t structures (we discussed only them so far)
? Implicit record locks do not have an associated lock_t object allocated. This is calculated based on the ID of the requesting transaction and the transaction ID available in each record
? If a transaction wants to acquire a record lock (implicit or explicit), then it needs to determine whether any other transaction has an implicit lock on the row before checking on the explicit lock
? If a transaction has modified or inserted an index record, then it owns an implicit x-lock on it
? For the clustered index, get the transaction id from the given record. If it is a valid transaction id, then that is the transaction which is holding the implicit exclusive lock on the row.
Implicit and explicit record locks, continued ? On a secondary index record, a transaction has an implicit x-lock also if it has modified the clustered index record, the max trx id of the page where the secondary index record resides is >= trx id of the transaction (or database recovery is running), and there are no explicit non-gaplock requests on the secondary index record.
? In the case of secondary indexes, we need to make use of the undo logs to determine if anytransactions have an implicit exclusive row lock on record.
? Check static trx_t* lock_sec_rec_some_has_impl(rec, index, offsets) for details
? Implicit lock can be and is converted to explicit (for example, when we wait for it) - check staticvoid lock_rec_convert_impl_to_expl(block, rec, index, offsets)
? Implicit record locks do not affect the gaps
? Read comments in the source code and great post by Annamalai:https://blogs.oracle.com/mysqlinnodb/entry/introduction_to_transaction_locks_in
Gap locks ? Gap lock is a on a gap between index records, or a lock on the gap before the first or after the last index record
? Usually gap locks are set as part of next-key lock, but may be set separately!
? Identified as “locks gap before rec”, you can see both “lock_mode X” and “lock mode S”:
RECORD LOCKS space id 513 page no 4 n bits 72 index `c1` of table `test`.`tt` trx id 74693 lock mode S locks gap before rec Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 4; hex 80000001; asc ;; 1: len 4; hex 80000002; asc ;;
? Check http://bugs.mysql.com/bug.php?id=71736 for the test case
? “Gap locking is not needed for statements that lock rows using a unique index to search for a unique row. (This does not include the case that the search condition includes only somecolumns of a multiple-column unique index; in that case, gap locking does occur.)”
? “A gap X-lock has the same effect as a gap S-lock” Next-key locks
? Next-key lock is a is a combination of a record lock on the index record and a gap lock on the gap before the index record
? “By default, InnoDB operates in REPEATABLE READ transaction isolation level and with the innodb_locks_unsafe_for_binlog system variable disabled. In this case, InnoDB uses next-key locks for searches and index scans, which prevents phantom rows”
? Identified as “lock_mode X” or “lock_mode S”: RECORD LOCKS space id 513 page no 3 n bits 72 index `PRIMARY` of table `test`.`tt`
trx id 74693 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;; Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 32 0: len 4; hex 80000001; asc ;; 1: len 6; hex 0000000123c5; asc # ;; 2: len 7; hex 3b00000190283e; asc ; (>;; 3: len 4; hex 80000001; asc ;;
?
Insert intention locks? “A type of gap lock called an insert intention gap lock is set by INSERT operations prior to rowinsertion. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the sameposition within the gap”
? We can use classic example from the manual (added as a fix for http://bugs.mysql.com/bug. php?id=43210) to see insert intention locks
? Identified as “insert intention”: RECORD LOCKS space id 515 page no 3 n bits 72 index `PRIMARY` of table `test`.`t` trx id 74772 lock_mode X insert intention Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0 0: len 8; hex 73757072656d756d; asc supremum;
?
MySQL 5.7: predicate locking for SPATIAL indexes? Read http://dev.mysql.com/doc/refman/5.7/en/innodb-predicate-locks.html
? As of MySQL 5.7.5, InnoDB supports SPATIAL indexing of columns containing spatial columns
? To enable support of isolation levels for tables with SPATIAL indexes, InnoDB uses predicate locks.
? A SPATIAL index contains minimum bounding rectangle (MBR) values, so InnoDB enforces consistent read on the index by setting a predicate lock on the MBR value used for a query.
? Other transactions cannot insert or modify a row that would match the query condition.
? Read storage/innobase/include/lock0prdt.h (breakpoints on lock_prdt_lock(),
lock_prdt_consistent())
? This is what you can get in gdb: Breakpoint 1, lock_prdt_lock (block=0x7f167f0a2368, prdt=0x7f167dde3280, index=0x7f1658942f10, mode=LOCK_S, type_mode=8192, thr=0x7f1658936240, mtr=0x7f167dde3480) Locks and SAVEPOINTs
?
Locks and SAVEPOINTs： 鎖并沒有回滾掉? Read http://dev.mysql.com/doc/refman/5.7/en/savepoint.html:
? “The ROLLBACK TO SAVEPOINT statement rolls back a transaction to the named savepoint without terminating the transaction. Modifications that the current transaction made to rows after the savepoint was set are undone in the rollback, but InnoDB does not release the row locks that were stored in memory after the savepoint.”
? “(For a new inserted row, the loc k information is carried by the transaction ID stored in the row; the lock is not separately stored in memory. In this case, the row lock is released in the undo.)” - this is probably the only clear mention of implicit locks
? Simple test case: start transaction; update t set val=5 where id=1; -- 1 row lock here, new data in 1 row savepoint a; update t set val=5 where id=2; -- 2 row locks here, new data in 2 rows select * from t; rollback to savepoint a; select * from t; -- 2 row locks here, new data in 1 row
?
EG
mysql> create table t ( id int,val int); Query OK, 0 rows affected (0.22 sec)mysql> insert into t select 1,3; Query OK, 1 row affected (0.18 sec) Records: 1 Duplicates: 0 Warnings: 0mysql> insert into t select 2,4; Query OK, 1 row affected (0.19 sec) Records: 1 Duplicates: 0 Warnings: 0mysql> begin; Query OK, 0 rows affected (0.00 sec)mysql> update t set val=5 where id=1; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0mysql> savepoint a; Query OK, 0 rows affected (0.00 sec) mysql> update t set val=5 where id=2; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0mysql> select * from t; +------+------+ | id | val | +------+------+ | 1 | 5 | | 2 | 5 | +------+------+ 2 rows in set (0.01 sec)mysql> rollback to savepoint a; Query OK, 0 rows affected (0.01 sec)mysql> select * from t; +------+------+ | id | val | +------+------+ | 1 | 5 | | 2 | 4 | +------+------+ 2 rows in set (0.09 sec)?
?
TRANSACTIONS ------------ Trx id counter 92961 Purge done for trx's n:o < 92960 undo n:o < 0 state: running but idle History list length 324 Total number of lock structs in row lock hash table 1 LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION 0, not started MySQL thread id 3, OS thread handle 0x2abdf142b940, query id 49 localhost root init show engine innodb status ---TRANSACTION 92960, ACTIVE 155 sec 2 lock struct(s), heap size 376, 3 row lock(s), undo log entries 1 MySQL thread id 1, OS thread handle 0x2abdf13ea940, query id 42 localhost root cleaning up Trx read view will not see trx with id >= 92961, sees < 92961TABLE LOCK table `test`.`t` trx id 92960 lock mode IX
RECORD LOCKS space id 219 page no 3 n bits 72 index `GEN_CLUST_INDEX` of table `test`.`t` trx id 92960 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 00: len 8; hex 73757072656d756d; asc supremum;;Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 00: len 6; hex 000000179102; asc ;;1: len 6; hex 000000016b20; asc k ;;2: len 7; hex 190000022c1545; asc , E;;3: len 4; hex 80000001; asc ;;4: len 4; hex 80000005; asc ;;Record lock, heap no 3 PHYSICAL RECORD: n_fields 5; compact format; info bits 00: len 6; hex 000000179103; asc ;;1: len 6; hex 000000016b1b; asc k ;;2: len 7; hex 960000014c0110; asc L ;;3: len 4; hex 80000002; asc ;;4: len 4; hex 80000004; asc ;;
鎖并沒有回滾掉
?
Table level IS and IX (intention) locks? Read the manual, http://dev.mysql.com/doc/refman/5.6/en/innodb-lock-modes.html ? Intention shared (IS): Transaction T intends to set S locks on individual rows in table t ? Intention exclusive (IX): Transaction T intends to set X locks on those rows ? Before a transaction can acquire an S lock on a row in table t, it must first acquire an IS or stronger lock on t ? Before a transaction can acquire an X lock on a row, it must first acquire an IX lock on t ? Intention locks do not block anything except full table requests (for example, LOCK TABLES ... WRITE or ALTER TABLE)
---TRANSACTION 85539, ACTIVE 15 sec 2 lock struct(s), heap size 360, 5 row lock(s) MySQL thread id 2, OS thread handle 0x7fb142bca700, query id 58 localhost root init show engine innodb status TABLE LOCK table `test`.`t` trx id 85539 lock mode IS RECORD LOCKS space id 53 page no 3 n bits 72 index `PRIMARY` of table `test`.`t` trx id 85539 lock mode S
?
Table level S and X locks? These are set by LOCK TABLES READ|WRITE if InnoDB is aware of them
? “In MySQL 5.6, innodb_table_locks = 0 has no effect for tables locked explicitly with LOCK TABLES ... WRITE. It does have an effect for tables locked for read or write by LOCK TABLES ... WRITE implicitly (for example, through triggers) or by LOCK TABLES ... READ. ”
? ALTER TABLE blocks reads (not just writes) at the point where it is ready to install a new version of the table .frm file, discard the old file, and clear outdated table structures from the table and table definition caches. At this point, it must acquire an exclusive (X) lock.
? In the output of SHOW ENGINE INNODB STATUS (when extra locks output is enabled): ---TRANSACTION 85520, ACTIVE 47 sec mysql tables in use 1, locked 1 1 lock struct(s), heap size 360, 0 row lock(s) MySQL thread id 2, OS thread handle 0x7fb142bca700, query id 48 localhost root init show engine innodb status TABLE LOCK table `test`.`t` trx id 85520 lock mode X
?
metadata locks：? MySQL (since 5.5.3) uses metadata locking to manage concurrent access to database objects and toensure data consistency. Metadata locking applies to schemas, tables and stored routines.
? Session can not perform a DDL statement on a table that is used in an uncompleted explicitly orimplicitly started transaction in another session. This is achieved by acquiring metadata locks ontables used within a transaction and deferring release of those locks until the transaction ends.
? Starting with 5.7.3 you can monitor metadata locks via metadata_locks table in P_S:
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME ='global_instrumentation'; UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME ='wait/lock/metadata/sql/mdl'; select * from performance_schema.metadata_locks\G
? https://dev.mysql.com/doc/refman/5.6/en/metadata-locking.html ? http://www.percona.com/blog/2013/02/01/implications-of-metadata-locking-changes-in-mysql-5-5/ ? http://www.percona.com/blog/2015/04/03/transactional-metadata-locks/ ? http://bugs.mysql.com/bug.php?id=76588
?
轉載于:https://www.cnblogs.com/zengkefu/p/5682020.html
總結
以上是生活随笔為你收集整理的锁大全与 GDB调试的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： tomcat 配置
- 下一篇： SpringMVC视图解析器