innodb中的REDO解析
INNODB存储引擎的预写日志方式来保证事务的完整性。这意味着磁盘上的存储的数据页和内存缓冲池中的页是不同步的,对于内粗缓冲中
在innodb存储引擎中,事务日志通过重做(redo)日志文件和innodb存储引擎的日志缓冲(innodb log buffer)来实现;当开始一个事务时,会记录该事务的一个LSN(Log sequence number),当事务执行是,会往innodb存储引擎的缓冲池里插入事务日志,当事务提交是,必须将innodb粗才能引擎的日志缓冲写入磁盘(默认的实现,即innodb_flush_log_at_trx_commit=1),也就是写数据前,需要先写日志,这种方式为预写日志方式(write-ahead logging,WAL).
INNODB存储引擎的预写日志方式来保证事务的完整性。这意味着磁盘上的存储的数据页和内存缓冲池中的页是不同步的,对于内粗缓冲中的页的修改,首先是写入重做日志文件,,然后再写入磁盘。因此是一种异步的方式。可以通过show engine innodb status来观察当前的磁盘和日志的差距;
mysql> create table z(a int,primary key(a)) engine=innodb;
Query OK, 0 rows affected (0.01 sec)
mysql>
mysql> create procedure load_test(count int) begin declare i int unsigned default 0;
-> start transaction;
-> while i
-> set i=i+1;
-> end while;
-> commit;
-> end;
-> $$
Query OK, 0 rows affected (0.05 sec)
mysql> delimiter ;
mysql> show engine innodb status\G;
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
121130 15:41:01 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 12 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 224 1_second, 224 sleeps, 18 10_second, 66 background, 66 flush
srv_master_thread log flush and writes: 228
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 114, signal count 113
Mutex spin waits 6, rounds 180, OS waits 2
RW-shared spins 99, rounds 2970, OS waits 99
RW-excl spins 0, rounds 390, OS waits 13
Spin rounds per wait: 30.00 mutex, 30.00 RW-shared, 390.00 RW-excl
------------------------
LATEST DETECTED DEADLOCK
------------------------
121130 14:17:47
*** (1) TRANSACTION:
TRANSACTION 11F40, ACTIVE 71 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 320, 2 row lock(s)
MySQL thread id 80, OS thread handle 0x33d62740, query id 4152 localhost root statistics
select * from t3 where a=2 for update
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 3132 n bits 80 index `PRIMARY` of table `test`.`t3` trx id 11F40 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 4; hex 80000002; asc ;;
1: len 6; hex 000000011f35; asc 5;;
2: len 7; hex e00000013a011d; asc : ;;
*** (2) TRANSACTION:
TRANSACTION 11F41, ACTIVE 42 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 320, 2 row lock(s)
MySQL thread id 79, OS thread handle 0x33d62600, query id 4153 localhost root statistics
select * from t3 where a=1 for update
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 3132 n bits 80 index `PRIMARY` of table `test`.`t3` trx id 11F41 lock_mode X locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 4; hex 80000002; asc ;;
1: len 6; hex 000000011f35; asc 5;;
2: len 7; hex e00000013a011d; asc : ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 3132 n bits 80 index `PRIMARY` of table `test`.`t3` trx id 11F41 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 4; hex 80000001; asc ;;
1: len 6; hex 000000011f35; asc 5;;
2: len 7; hex e00000013a0110; asc : ;;
*** WE ROLL BACK TRANSACTION (2)
------------
TRANSACTIONS
------------
Trx id counter 11F45
Purge done for trx's n:o History list length 1433
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 11F41, not started
MySQL thread id 79, OS thread handle 0x33d62600, query id 4162 localhost root
show engine innodb status
---TRANSACTION 11F36, not started
MySQL thread id 77, OS thread handle 0x33d61e80, query id 4118 localhost root
---TRANSACTION 11F2B, not started
MySQL thread id 75, OS thread handle 0x33d61d40, query id 4077 192.168.0.69 root
---TRANSACTION 0, not started
MySQL thread id 74, OS thread handle 0x33d61fc0, query id 4070 192.168.0.69 root
---TRANSACTION 0, not started
MySQL thread id 23, OS thread handle 0x33d62380, query id 114 192.168.0.69 root
---TRANSACTION 11F40, ACTIVE 5065 sec
3 lock struct(s), heap size 320, 2 row lock(s)
MySQL thread id 80, OS thread handle 0x33d62740, query id 4152 localhost root
--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (read thread)
I/O thread 4 state: waiting for i/o request (read thread)
I/O thread 5 state: waiting for i/o request (read thread)
I/O thread 6 state: waiting for i/o request (write thread)
I/O thread 7 state: waiting for i/o request (write thread)
I/O thread 8 state: waiting for i/o request (write thread)
I/O thread 9 state: waiting for i/o request (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
691 OS file reads, 1923 OS file writes, 1010 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 553253, node heap has 6 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 594246629
Log flushed up to 594246629
Last checkpoint at 594246629
0 pending log writes, 0 pending chkp writes
649 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 135987200; in additional pool allocated 0
Dictionary memory allocated 281610
Buffer pool size 8192
Free buffers 4305
Database pages 3881
Old database pages 1418
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 5, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 633, created 3248, written 5875
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 3881, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread id 869673728, state: waiting for server activity
Number of rows inserted 105750, updated 0, deleted 0, read 59717
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
1 row in set (0.00 sec)
ERROR:
No query specified
mysql>
mysql> call load_test(10000);
Query OK, 0 rows affected (0.50 sec)

熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

Video Face Swap
使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

熱工具

記事本++7.3.1
好用且免費的程式碼編輯器

SublimeText3漢化版
中文版,非常好用

禪工作室 13.0.1
強大的PHP整合開發環境

Dreamweaver CS6
視覺化網頁開發工具

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)

蘋果公司最新發布的iOS18、iPadOS18以及macOSSequoia系統為Photos應用程式增添了一項重要功能,旨在幫助用戶輕鬆恢復因各種原因遺失或損壞的照片和影片。這項新功能在Photos應用的"工具"部分引入了一個名為"已恢復"的相冊,當用戶設備中存在未納入其照片庫的圖片或影片時,該相冊將自動顯示。 "已恢復"相簿的出現為因資料庫損壞、相機應用未正確保存至照片庫或第三方應用管理照片庫時照片和視頻丟失提供了解決方案。使用者只需簡單幾步

Hibernate多態映射可映射繼承類別到資料庫,提供以下映射類型:joined-subclass:為子類別建立單獨表,包含父類別所有欄位。 table-per-class:為子類別建立單獨資料表,僅包含子類別特有列。 union-subclass:類似joined-subclass,但父類別表聯合所有子類別列。

如何在PHP中使用MySQLi建立資料庫連線:包含MySQLi擴充(require_once)建立連線函數(functionconnect_to_db)呼叫連線函數($conn=connect_to_db())執行查詢($result=$conn->query())關閉連線( $conn->close())

PHP處理資料庫連線報錯,可以使用下列步驟:使用mysqli_connect_errno()取得錯誤代碼。使用mysqli_connect_error()取得錯誤訊息。透過擷取並記錄這些錯誤訊息,可以輕鬆識別並解決資料庫連接問題,確保應用程式的順暢運作。

透過Go標準庫database/sql包,可以連接到MySQL、PostgreSQL或SQLite等遠端資料庫:建立包含資料庫連接資訊的連接字串。使用sql.Open()函數開啟資料庫連線。執行SQL查詢和插入操作等資料庫操作。使用defer關閉資料庫連線以釋放資源。

在Golang中使用資料庫回呼函數可以實現:在指定資料庫操作完成後執行自訂程式碼。透過單獨的函數新增自訂行為,無需編寫額外程式碼。回調函數可用於插入、更新、刪除和查詢操作。必須使用sql.Exec、sql.QueryRow或sql.Query函數才能使用回呼函數。

可以透過使用gjson函式庫或json.Unmarshal函數將JSON資料儲存到MySQL資料庫中。 gjson函式庫提供了方便的方法來解析JSON字段,而json.Unmarshal函數需要一個目標類型指標來解組JSON資料。這兩種方法都需要準備SQL語句和執行插入操作來將資料持久化到資料庫中。

在C++中使用DataAccessObjects(DAO)函式庫連接和操作資料庫,包括建立資料庫連線、執行SQL查詢、插入新記錄和更新現有記錄。具體步驟為:1.包含必要的函式庫語句;2.開啟資料庫檔案;3.建立Recordset物件執行SQL查詢或操作資料;4.遍歷結果或依照特定需求更新記錄。
