寫在前面：在個(gè)別時(shí)候可能需要查看當(dāng)前最新的事務(wù) ID，以便做一些業(yè)務(wù)邏輯上的判斷（例如利用事務(wù) ID 變化以及前后時(shí)差，統(tǒng)計(jì)每次事務(wù)的響應(yīng)時(shí)長等用途）。
通常地，我們有兩種方法可以查看當(dāng)前的事務(wù) ID：
1、執(zhí)行 SHOW ENGINE INNODB STATUS，查看事務(wù)相關(guān)信息
=====================================
150303 17:16:11 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 15 seconds
...
------------
TRANSACTIONS
Trx id counter 3359877657 -- 當(dāng)前最大事務(wù) ID
Purge done for trx's n:o 3359877468 undo n:o 0 state: running
History list length 324
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started -- 該會(huì)話中執(zhí)行 SHOW ENGINE INNODB STATUS，不會(huì)產(chǎn)生事務(wù)，所以事務(wù) ID 為 0
MySQL thread id 4692367, OS thread handle 0x51103940, query id 677284426 xx.173ops.com 10.x.x.x yejr init
SHOW /*!50000 ENGINE*/ INNODB STATUS
---TRANSACTION 3359877640, not started --非活躍事務(wù)，還未開始
mysql tables in use 1, locked 0
MySQL thread id 4678384, OS thread handle 0x41a57940, query id 677284427 xx.173ops.com 10.x.x.x yejr System lock
select polinfo0_.Fid as Fid39_0_, ...
---TRANSACTION 3359877652, not started
MySQL thread id 4678383, OS thread handle 0x50866940, query id 677284420 xx.173ops.com 10.x.x.x yejr cleaning up
---TRANSACTION 3359877635, ACTIVE 1358 sec, thread declared inside InnoDB 5000 --活躍長事務(wù)，運(yùn)行了 1358 秒還未結(jié)束，要引起注意，可能會(huì)導(dǎo)致大量鎖等待發(fā)生
mysql tables in use 1, locked 1
1 lock struct(s), heap size 376, 0 row lock(s), undo log entries 1
MySQL thread id 3120717, OS thread handle 0x529b4940, query id 677284351 xx.173ops.com 10.x.x.x yejr query end
insert into t_live_room ...
2、查看 INFORMATION_SCHEMA.INNODB_TRX、INNODB_LOCKS、INNODB_LOCK_WAITS 三個(gè)表，通過這些信息能快速發(fā)現(xiàn)哪些事務(wù)在阻塞其他事務(wù)
先查詢 INNODB_TRX 表，看看都有哪些事務(wù)
mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX\G
*************************** 1. row ***************************
trx_id: 17778 -- 當(dāng)前事務(wù) ID
trx_state: LOCK WAIT -- 處于鎖等待狀態(tài)，也就是等待其他會(huì)話釋放鎖資源
trx_started: 2015-03-04 10:40:26
trx_requested_lock_id: 17778:82:3:6 -- 欲請(qǐng)求的鎖
trx_wait_started: 2015-03-04 10:40:26
trx_weight: 2 -- 大意是該鎖影響了 2 行記錄
trx_mysql_thread_id: 657 -- processlist 中的線程 ID
trx_query: update trx_fee set fee=rand()*1000 where id= 4
trx_operation_state: starting index read
trx_tables_in_use: 1
trx_tables_locked: 1
trx_lock_structs: 2
trx_lock_memory_bytes: 360
trx_rows_locked: 1
trx_rows_modified: 0
trx_concurrency_tickets: 0
trx_isolation_level: REPEATABLE READ
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_adaptive_hash_latched: 0
trx_adaptive_hash_timeout: 10000
trx_is_read_only: 0
trx_autocommit_non_locking: 0
*************************** 2. row ***************************
trx_id: 17773
trx_state: RUNNING
trx_started: 2015-03-04 10:40:23
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 10
trx_mysql_thread_id: 656
trx_query: NULL
trx_operation_state: NULL
trx_tables_in_use: 0
trx_tables_locked: 0
trx_lock_structs: 2
trx_lock_memory_bytes: 360
trx_rows_locked: 9
trx_rows_modified: 8
trx_concurrency_tickets: 0
trx_isolation_level: REPEATABLE READ
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_adaptive_hash_latched: 0
trx_adaptive_hash_timeout: 10000
trx_is_read_only: 0
trx_autocommit_non_locking: 0
再看 INNODB_LOCKS 表，看看都有什么鎖
mysql> select * from information_schema.INNODB_LOCKS\G
*************************** 1. row ***************************
lock_id: 17778:82:3:6 --當(dāng)前鎖 ID
lock_trx_id: 17778 --該鎖對(duì)應(yīng)的事務(wù) ID
lock_mode: X -- 鎖類型，排它鎖 X
lock_type: RECORD --鎖范圍，記錄鎖：record lock，其他鎖范圍：間隙鎖：gap lock，或者 next-key lock（記錄鎖+間隙鎖）
lock_table: `test`.`trx_fee`
lock_index: PRIMARY --加載在哪個(gè)索引上的鎖
lock_space: 82
lock_page: 3
lock_rec: 6
lock_data: 4
*************************** 2. row ***************************
lock_id: 17773:82:3:6
lock_trx_id: 17773
lock_mode: X
lock_type: RECORD
lock_table: `test`.`trx_fee`
lock_index: PRIMARY
lock_space: 82
lock_page: 3
lock_rec: 6
lock_data: 4
最后看 INNODB_LOCK_WAITS 表，看看當(dāng)前都有哪些鎖等待
mysql> select * from information_schema.INNODB_LOCK_WAITS\G
*************************** 1. row ***************************
requesting_trx_id: 17778 --請(qǐng)求鎖的事務(wù) ID（等待方）
requested_lock_id: 17778:82:3:6 -- 請(qǐng)求鎖 ID
blocking_trx_id: 17773 -- 阻塞該鎖的事務(wù) ID（當(dāng)前持有方，待釋放）
blocking_lock_id: 17773:82:3:6 -- 持有的鎖 ID
關(guān)于 INFORMATION_SCHEMA 中和 InnoDB 有關(guān)的表用途描述，可以查看手冊(cè)：21.29 INFORMATION_SCHEMA Tables for InnoDB
3、利用 percona 分支的特性，查看當(dāng)前最新事務(wù) ID，該特性從 5.6.11-60.3 版本開始引入，執(zhí)行下面的 2 個(gè)命令即可查看
mysqladmin ext | grep Innodb_max_trx_id
或者
mysql> show global status like 'Innodb_max_trx_id';
最后，交代下問題的來源其實(shí)是這樣的，有位朋友和我討論問題，說在 java 連接池中，發(fā)現(xiàn) 2 個(gè)事務(wù)的事務(wù) ID 是一樣的，測試的 SQL 代碼：
begin;update trx set un=rand() where id=round(rand()*10)+1;select * from information_schema.INNODB_TRX; commit;select sleep(0.01);begin;update trx set un=rand() where id=round(rand()*10)+1;select * from information_schema.INNODB_TRX;commit;
這串代碼不能折行，中間的 sleep 停留 不能太大，也就是模擬足夠快的情況下，檢查 2 次事務(wù)的 ID 是否有變化。可以發(fā)現(xiàn)，時(shí)間足夠短的話，2 次查詢到的事務(wù) ID 是一樣的，并沒有發(fā)生變化。大家也可以在自己的環(huán)境下試試。
以上就是MySQL 如何查詢當(dāng)前最新事務(wù)ID的詳細(xì)內(nèi)容，更多關(guān)于MySQL查詢事務(wù)ID的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！
您可能感興趣的文章:- MySQL如何實(shí)現(xiàn)事務(wù)的ACID
- MySQL為什么要避免大事務(wù)以及大事務(wù)解決的方法
- 解析MySQL8.0新特性——事務(wù)性數(shù)據(jù)字典與原子DDL
- MySQL事務(wù)及Spring隔離級(jí)別實(shí)現(xiàn)原理詳解
- MySQL 事務(wù)概念與用法深入詳解
- MySQL查看和修改事務(wù)隔離級(jí)別的實(shí)例講解
- Mysql數(shù)據(jù)庫高級(jí)用法之視圖、事務(wù)、索引、自連接、用戶管理實(shí)例分析
- MySql 索引、鎖、事務(wù)知識(shí)點(diǎn)小結(jié)
- MySql 知識(shí)點(diǎn)之事務(wù)、索引、鎖原理與用法解析
- MySQL 如何使用事務(wù)
