MySQL 如何查詢當(dāng)前最新事務(wù)ID
寫在前面:在個(gè)別時(shí)候可能需要查看當(dāng)前最新的事務(wù) ID,以便做一些業(yè)務(wù)邏輯上的判斷(例如利用事務(wù) ID 變化以及前后時(shí)差,統(tǒng)計(jì)每次事務(wù)的響應(yīng)時(shí)長(zhǎng)等用途)。
通常地,我們有兩種方法可以查看當(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 --活躍長(zhǎng)事務(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è)表,通過(guò)這些信息能快速發(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';
最后,交代下問(wèn)題的來(lái)源其實(shí)是這樣的,有位朋友和我討論問(wèn)題,說(shuō)在 java 連接池中,發(fā)現(xiàn) 2 個(gè)事務(wù)的事務(wù) ID 是一樣的,測(cè)試的 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 是否有變化??梢园l(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)文章!
相關(guān)文章
SQL中CONVERT轉(zhuǎn)換函數(shù)的簡(jiǎn)單使用方法
CONVERT()函數(shù)對(duì)于簡(jiǎn)單類型轉(zhuǎn)換,CONVERT()函數(shù)和CAST()函數(shù)的功能相同,只是語(yǔ)法不同,下面這篇文章主要給大家介紹了關(guān)于SQL中CONVERT轉(zhuǎn)換函數(shù)的簡(jiǎn)單使用方法,需要的朋友可以參考下2024-01-01
一文教你快速學(xué)會(huì)使用DDL對(duì)數(shù)據(jù)庫(kù)和表的操作
SQL是一種操作關(guān)系型數(shù)據(jù)庫(kù)的結(jié)構(gòu)化查詢語(yǔ)言,今天這篇文章將詳細(xì)講述數(shù)據(jù)定義語(yǔ)言DDL對(duì)數(shù)據(jù)庫(kù)和表的相關(guān)操作,有感興趣的同學(xué)跟著小編一起來(lái)學(xué)習(xí)吧2023-07-07
MySQL 數(shù)據(jù)庫(kù)定時(shí)備份的幾種方式(全面)
在操作數(shù)據(jù)過(guò)程中,可能會(huì)導(dǎo)致數(shù)據(jù)錯(cuò)誤,甚至數(shù)據(jù)庫(kù)奔潰,而有效的定時(shí)備份能很好地保護(hù)數(shù)據(jù)庫(kù)。本篇文章主要講述了幾種方法進(jìn)行 MySQL 定時(shí)備份數(shù)據(jù)庫(kù)。2021-09-09
MySQL外鍵類型及應(yīng)用場(chǎng)景總結(jié)
這篇文章主要介紹了?MySQL?外鍵的類型(RESTRICT、CASCADE、SET?NULL、NO?ACTION)及其應(yīng)用場(chǎng)景、優(yōu)缺點(diǎn)和使用注意事項(xiàng),通過(guò)創(chuàng)建和測(cè)試外鍵,闡述了不同類型外鍵在主表刪除或更新數(shù)據(jù)時(shí)子表的變化,需要的朋友可以參考下2024-12-12
基于Redo Log和Undo Log的MySQL崩潰恢復(fù)解析
這篇文章主要介紹了基于Redo Log和Undo Log的MySQL崩潰恢復(fù)流程,點(diǎn)進(jìn)來(lái)的小伙伴不要錯(cuò)過(guò)奧2021-08-08

