① informix 邏輯日誌與物理日誌分配多大
1．物理日誌
物理日誌的作用在於保持一批dbspace頁的前映象。這些「前映象」代表了所有數據在物理上與邏輯上都保持一致的這樣一個時刻。將物理日誌中的前映象與邏輯日誌中的邏輯日誌記錄結合起來，可以恢復資料庫自上一次已知的一致點以來發生的所有事務。這樣的已知的一致點稱為檢查點。在快速恢復過程中，第一步首先用到物理日誌，將整個系統恢復在Online中最近一次檢查點時所處的物理一致的狀態。
1） 物理日誌的存放地址
當IDS初始化時，將會在rootdbs中創建物理日誌。
當IDS處於靜止方式時，用戶可將物理日誌從一個dbspace移到另一個dbspace中。用戶這樣做的目的是想盡量提高效率。
物理日誌的位置由配置文件中的PHYSDBS參數指定。這個參數僅當用戶決定將物理日誌從 rootdbs中移到另一個dbspace中才必須被改變；否則，該參數在預設情況下，仍包含著rootdbs的名稱。
物理日誌的大小由配置參數PHYSFILE指定，以kb為單位。用戶可以修改物理日誌文件的位置和大小。
2） 物理日誌的內容
物理日誌是一組連續的磁碟頁面，每一個都包含有一個特別的Online頁的副本。物理日誌中的頁面可以是除了blobspace中blobpage以外的其它任何Online頁面。甚至可對應於系統開銷頁，例如chunk空閑鏈頁、blobspace空閑映象頁、blobspace點陣圖頁等等，這些頁也必須在其上的數據被修改並刷新到磁碟上之前被復制到物理日誌中去。
Blobspace blobpage並不出現在物理日誌中，這是因為blob採用與其它數據類型不同方法記錄日誌。
3） 物理日誌前映象
在某一次檢查點後，某個頁面第一次被修改時，該頁的「前映象」將被寫入共享內存中的物理日誌緩沖區。在該被修改的頁從共享內存刷新到磁碟上之前，該頁的「前映象」應首先被刷新到磁碟上物理日誌中。需要注意的是，僅當對頁面的第一次修改才會導致往物理日誌中寫「前映象」。先寫日誌文件原則是為快速恢復所必需的。
4） 檢查點操作邏輯地清空物理日誌
每次Online檢查點操作以後，物理日誌中逐漸被填上發生修改的「前映象」。當再一次檢查點操作發生以後的瞬間，這時Online中的數據在物理上是一致的，這時也就再不需要原來的Online物理日誌中的「前映象」了。（這對於繼續執行的事務也同樣適用。如果某一個這樣的事務需要執行回滾操作，則執行回滾所需的信息都已包含在邏輯日誌文件中了。）在檢查點操作完成時，Online將邏輯上清空邏輯日誌，Online僅僅重置物理日誌中的指針，標明下一組「前映象」所存儲的起始位置。Online 循環使用物理日誌，不斷地覆蓋那些已過時的數據。
檢查點操作是唯一可以清空物理日誌的機制。如果物理日誌75%的空間已被佔用，則Online將啟動一次檢查點操作。
2．邏輯日誌
邏輯日誌文件的作用在於自上一次Online archive以來，對Online數據所發生的變化進行記錄。Online把邏輯日誌分成三個或更多個相互分離的磁碟空間，每磁碟空間稱為一個邏輯日誌文件。相應於每一個邏輯日誌文件有一個唯一標識號。
1） 邏輯日誌與快速恢復
Online使用邏輯日誌可以恢復自上一次已知的物理一致點以來發生的所有事務。這一已知的物理一致點在Online系統中稱為檢查點。快速恢復中，當Online使用物理日誌將整個系統恢復到上一次檢查點時所處的狀態以後，Online將使用邏輯日誌記錄將整個系統恢復到最近一次邏輯日誌記錄時刻的邏輯一致性狀態，這實際上是快速恢復的第二步驟。
2） 邏輯日誌與數據恢復
將邏輯日誌文件的備份磁帶與最近一次的Online的archive結合在一起，可以將Online系統重新恢復到最近一次邏輯日誌記錄時的狀態。
3） 邏輯日誌文件被循環使用
Online通過標識一個邏輯日誌文件為used（使用）狀態來保護邏輯日誌文件不被覆蓋，直至該文件被備份到磁帶上並且快速恢復已不再需要該邏輯日誌文件時為止。當一個邏輯日誌文件中的所有記錄對應的事務都已完成時，快速恢復過程將不再需要該邏輯日誌文件。如果上面所說的兩個重要條件都已被滿足，即邏輯日誌文件已被備份到磁帶上，並且快速恢復也已不再需要該邏輯日誌文件，這時Online將該邏輯日誌文件標記為free（空閑）狀態，該文件也就可以被再次用以填如邏輯日誌記錄。
在 Online處理過程中，Online按數字順序依次填充空閑的（即狀態為free）的邏輯日誌文件。當第一個邏輯日誌文件變滿時，Online接著開始填充下一個邏輯日誌文件，如果下一次邏輯日誌的狀態為「used」而不是「free」，則正常的Online處理將被掛起。Online不能跳過該標記為「used」狀態的邏輯日誌文件而去填充別的空閑的日誌文件。保證空閑的邏輯日誌文件在Online處理過程中總可以被得到，這是Online管理員的職責。
Online至少需要三個邏輯日誌文件以便循環使用邏輯日誌文件，當一個邏輯日誌文件在接收當前記錄時，Online有可能正將另一個日誌文件往磁帶上備份，第三個日誌文件是當前日誌文件已滿，而備份另一個日誌文件的工作尚未完成時所需要的。（這個使用三個邏輯日誌緩沖區的考慮是類似的）。
4） 邏輯日誌文件：標識號與備份
邏輯日誌備份帶以邏輯日誌所包含的唯一數值標記。每當一個日誌文件填滿時，邏輯日誌標識號就增加數值1。例如，如果一個Online系統包含三個邏輯日誌文件，則相應的三個日誌文件的標識號為1、2、3。當邏輯日誌文件1第一次被釋放以便循環使用時，它將變為邏輯日誌文件4，第二次它又將變為邏輯日誌文件7。
5） 邏輯日誌文件的內容
邏輯日誌文件中包含下述五種類型的記錄：
所有資料庫的SQL定義語句。
檢查點記錄。
有關配置修改的記錄。
對於那些創建時使用日誌登錄的資料庫的SQL數據操縱語句。
有關某個資料庫日誌登錄狀態變化的記錄。
即使沒有一個資料庫創建時使用了事務日誌登錄，在處理過程中，Online也會將前面三種類型的記錄寫入邏輯日誌文件。邏輯日誌記錄可以跨越Online的整個頁面，但它們卻不能跨越邏輯日誌文件。
6） 邏輯日誌文件的配置
當Online初始化時將會在rootdbs中創建邏輯日誌文件。在Online處於靜止方式以後，用戶可以從rootdbs中刪除一個或多個邏輯日誌文件，也可以往另一個dbspace中增加一個或多個邏輯日誌文件。用戶有可能為了提高效率而這樣做。
在Online磁碟空間初始化以後，用戶就不能再修改邏輯日誌文件的大小了。如果一邏輯日誌文件被刪除，則由該邏輯日誌文件占據的空間將被釋放掉，並被鏈入chunk空閑鏈頁。
7） 大小與數目方面的限制
Online管理員決定每一個邏輯日誌文件的大小，以及分配給整個邏輯日誌的磁碟空間的大小。每個邏輯日誌文件至少要被分配到200K的磁碟空間。
邏輯日誌文件的最小數目為3，最大數目則由一頁上可容納的邏輯日誌描述字的數目所決定。對於一個2K大小的頁，最大的日誌文件數目為60。
8） 影響邏輯日誌文件填充速度的因素
下列四個因素會影響一個事務的大小與持續時間：
邏輯日誌文件記錄的大小
事務打開時間的長度
CPU與邏輯日誌的活動級別（Actirity Level）
事務回滾的頻率（Freqency）
邏輯日誌記錄的長度隨處理操作與當前Online的環境而變化。一般來講，數據行越長，邏輯日誌記錄也就越大。
不僅如此，其它一些因素還會影響單一事務的大小與操作時間。例如，一條Alter table語句將會為每一次往新修改了的表中的插入操作生成一條邏輯日誌記錄。數據行的大小與表的大小都將會影響生成的邏輯日誌記錄的數目與大小。然而在一些情況下，數據行大小是無關緊要的。例如，邏輯日誌中的一條檢查點記錄將包含對應於所有檢查點發生時刻仍處於打開狀態的事務的項目。檢查點記錄的大小僅僅反映了當前的資料庫活動的級別與類型，而不涉及到任何特定的行的大小。
事務的持續時間也是一個不能為用戶所控制的主要的變化量。一個應用，也許並不需要過多的邏輯日誌記錄空間，但如果用戶允許事務在很長時間內保持打開，這時就可能造成生成長事務錯誤。在保證不產生長事務錯誤的前提下，可用的邏輯日誌空間越多，就有可能允許越長的事務保持打開狀態。
CPU的能力可能影響Online伺服器進程完成事務的能力。重復地往邏輯日誌文件寫，增加了每個伺服器進程完成事務所需的CPU時間。邏輯日誌操作的增加，可能還隱含著同時增加了對邏輯日誌鎖與latch的競爭。（也正是這個原因，用戶才有可能需要將邏輯日誌文件從rootdbs移到另一個不太活躍的dbspace中去）。
回滾的頻率也影響著邏輯日誌被填充的速率。盡管回滾記錄很小，但回滾本身也需要邏輯日誌文件空間。而且，回滾也增加對邏輯日誌的操作。
② 汗顏！工作10年去面試，被「MySQL怎麼保證事物一致性」難倒了
阿牛去一家中意的公司面試，本以為憑藉以往豐富的經驗，肯定手到擒來，結果第一個問題，我就「出門右拐」了。
問題就是：MySQL是怎麼保證事務一致性的？
回到家阿牛翻閱資料，終於搞懂了，在這里分享給大家。
定義
在搞清楚問題答案之前，先搞清楚以下幾個名詞以及大致的用處
redo log：
通常是物理日誌，記錄的是數據頁的物理修改，而不是某一行或某幾行修改成怎樣怎樣，它用來恢復提交後的物理數據頁(恢復數據頁，且只能恢復到最後一次提交的位置)、Innodb特有的，他在存儲引擎層。循環寫的，空間固定會用完。作用是crash-safe能力
binlog：
是邏輯日誌，記錄的是這個語句的原始邏輯，比如「給 ID=2 這一行的 c 欄位加 1 」 是 MySQL 的 Server 層實現的，所有引擎都可以使用。是可以追加寫入的,「追加寫」是指 binlog 文件寫到一定大小後會切換到下一個，並不會覆蓋以前的日誌。作用是數據歸檔
undo log：
有兩個作用：提供回滾和多個行版本控制(MVCC)。
在數據修改的時候，不僅記錄了redo，還記錄了相對應的undo，如果因為某些原因導致事務失敗或回滾了，可以藉助該undo進行回滾。
SQL執行的過程
了解了以上名詞之後，讓我們看一下「一條更新SQL語句執行的過程是什麼？」
如圖1有幾個關鍵步驟：
1、先查找記錄所在的Innodb頁在不在內存里；如果不在內存里則將記錄所在的頁載入在內存里；根據SQL語句在內存中將記錄更新
2、將更新前的記錄寫入undolog
3、根據記錄的更新值將變更寫入redolog（buffer）中，並將狀態變更為prepare
4、將變更記錄到邏輯日誌
5、redolog日誌中的狀態修改為commit，返回結束
至此：一條更新語句的過程結束
上面的步驟中有些同學可能會有一些疑問：為什麼更新一條記錄要把一整頁數據載入到內存里答：因為Innodb引擎中，最小的存儲單位是頁為什麼一定要載入到內存里？答：因為所有的計算操作都是在內存里，操作完成後最終才寫回磁碟為什麼要寫入redolog，直接寫入磁碟，然後寫入binlog就好了啊？答：這將在下面會提到，請往後看
為了加深理解，准備了下面2張圖輔助理解
以圖3為例，讓我們看看在每個步驟出現異常的時候，到底怎麼保證事物一致性的吧！1、步驟123，所有的操作最多還只是內存里，如果出現宕機、斷電等異常， 記錄不會有任何變動，事物是一致的2、步驟4剛執行完，斷電了，因為redolog還處在prepare狀態， 這時候事物也是一致的3、步驟5記錄binlog的過程中斷電了，這時候要保證主從一致性， 事物也是不生效的，最終也是一致的4、步驟6、7如果中間任何一個時刻斷電了，這時候情況就不一樣了，事物是生效的，因為redolog、binlog的數據都是完整的，伺服器重啟後可以按照xid來去查看binlog、redolog中是否都存在， 都存在該事物就是生效的。上面就是怎麼保證事務一致性的根本原因
為什麼要使用redolog？
回答這個問題之前，我們先看看redolog用圖形表示的
圖4是redolog的形象一點的表現，並不是說redolog 長這個樣子，只是為了更形象；一般情況下redolog一組4個文件，每個文件1個G，其中write pos是指redolog當前寫到什麼位置了，check point是指上次刷臟結束的位置，當write log和check point重合時，所有的進程停止，開始新一輪的刷臟操作。刷完後redolog清空開始下一輪的寫入，往返重復。
可能這樣表示有點抽象，讓我們看下圖5
從上圖中可以看的更形象一點，在sql執行的時候，會有磁碟IO將數據頁載入到內存，然後在內存中將數據修改，修改後的數據頁在內存中叫做臟頁（叫臟頁因為和磁碟中的數據不一致啊），又因為在內存中容易丟失，所以將數據頁的變更記錄如redolog中，隨著記錄插入、更新等操作的增多，redolog空間慢慢的滿了，這時候就開始刷臟操作了，page cleaner thread線程會將所有的臟頁數據刷新到磁碟，使得變更最終被持久化到磁碟。
講到這里一定還會有人不太理解，刷臟之前斷電了咋辦？
這就是redolog的另一個重要的作用，crash-safe能力，實現的邏輯是這樣的，斷電後內存的數據都沒了，重啟後讀取redolog文件，因為redolog文件記錄的是在Innodb頁x的m處做了y的修改，所以根據redolog將涉及到的Innodb頁重新載入到內存，根據redolog的記錄將內存中的數據重新修改，這樣就能恢復斷電前的數據了。
完
下期預告：還是MySQL，敬請期待
本文首發自： 程序員阿牛
③ 資料庫的事務機制是什麼
回答的有點多請耐心看完。
希望能幫助你還請及時採納謝謝
1事務的原理
事務就是將一組SQL語句放在同一批次內去執行，如果一個SQL語句出錯,則該批次內的所有SQL都將被取消執行。MySQL事務處理只支持InnoDB和BDB數據表類型。
1事務的ACID原則
** 1（Atomicity）原子性**： 事務是最小的執行單位，不允許分割。原子性確保動作要麼全部完成，要麼完全不起作用；
2（Consistency）一致性： 執行事務前後，數據保持一致；
3（Isolation）隔離性： 並發訪問資料庫時，一個事務不被其他事務所干擾。
4（Durability）持久性: 一個事務被提交之後。對資料庫中數據的改變是持久的，即使資料庫發生故障。
1緩沖池（Buffer Pool）
Buffer Pool中包含了磁碟中部分數據頁的映射。當從資料庫讀取數據時，會先從Buffer Pool中讀取數據，如果Buffer Pool中沒有，則從磁碟讀取後放入到Buffer Pool中。當向資料庫寫入數據時，會先寫入到Buffer Pool中，Buffer Pool中更新的數據會定期刷新到磁碟中（此過程稱為刷臟）。
2日誌緩沖區（Log Buffer）
當在MySQL中對InnoDB表進行更改時，這些更改命令首先存儲在InnoDB日誌緩沖區（Log Buffer）的內存中，然後寫入通常稱為重做日誌（redo logs）的InnoDB日誌文件中。
3雙寫機制緩存（DoubleWrite Buffer）
Doublewrite Buffer是共享表空間的物理文件的 buffer,其大小是2MB.是一個一分為二的2MB空間。
刷臟操作開始之時,先進行臟頁**『備份』**操作.將臟頁數據寫入 Doublewrite Buffer.
將Doublewrite Buffer(順序IO)寫入磁碟文件中(共享表空間) 進行刷臟操作.
4回滾日誌(Undo Log)
Undo Log記錄的是邏輯日誌.記錄的是事務過程中每條數據的變化版本和情況.
在Innodb 磁碟架構中Undo Log 默認是共享表空間的物理文件的Buffer.
在事務異常中斷,或者主動(Rollback)回滾的過程中 ,Innodb基於 Undo Log進行數據撤銷回滾,保證數據回歸至事務開始狀態.
5重做日誌(Redo Log)
Redo Log通常指的是物理日誌，記錄的是數據頁的物理修改.並不記錄行記錄情況。（也就是只記錄要做哪些修改，並不記錄修改的完成情況） 當資料庫宕機重啟的時候，會將重做日誌中的內容恢復到資料庫中。
1原子性
Innodb事務的原子性保證,包含事務的提交機制和事務的回滾機制.在Innodb引擎中事務的回滾機制是依託 回滾日誌(Undo Log) 進行回滾數據，保證數據回歸至事務開始狀態.
2那麼不同的隔離級別，隔離性是如何實現的，為什麼不同事物間能夠互不幹擾？ 答案是 鎖 和 MVCC。
3持久性
基於事務的提交機制流程有可能出現三種場景.
1 數據刷臟正常.一切正常提交，Redo Log 循環記錄.數據成功落盤.持久性得以保證
2數據刷臟的過程中出現的系統意外導致頁斷裂現象 (部分刷臟成功)，針對頁斷裂情況,採用Double write機制進行保證頁斷裂數據的恢復.
3數據未出現頁斷裂現象,也沒有刷臟成功，MySQL通過Redo Log 進行數據的持久化即可
4一致性
從資料庫層面，資料庫通過原子性、隔離性、持久性來保證一致性
2事務的隔離級別
Mysql 默認採用的 REPEATABLE_READ隔離級別 Oracle 默認採用的 READ_COMMITTED隔離級別
臟讀： 指一個事務讀取了另外一個事務未提交的數據。
不可重復讀： 在一個事務內讀取表中的某一行數據，多次讀取結果不同
虛讀(幻讀)： 是指在一個事務內讀取到了別的事務插入的數據，導致前後讀取不一致。
2基本語法
-- 使用set語句來改變自動提交模式
SET autocommit = 0; /*關閉*/
SET autocommit = 1; /*開啟*/
-- 注意:
--- 1.MySQL中默認是自動提交
--- 2.使用事務時應先關閉自動提交
-- 開始一個事務,標記事務的起始點
START TRANSACTION
-- 提交一個事務給資料庫
COMMIT
-- 將事務回滾,數據回到本次事務的初始狀態
ROLLBACK
-- 還原MySQL資料庫的自動提交
SET autocommit =1;
-- 保存點
SAVEPOINT 保存點名稱 -- 設置一個事務保存點
ROLLBACK TO SAVEPOINT 保存點名稱 -- 回滾到保存點
RELEASE SAVEPOINT 保存點名稱 -- 刪除保存點
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
/*
課堂測試題目
A在線買一款價格為500元商品,網上銀行轉賬.
A的銀行卡余額為2000,然後給商家B支付500.
商家B一開始的銀行卡余額為10000
創建資料庫shop和創建表account並插入2條數據
*/
CREATE DATABASE `shop`CHARACTER SET utf8 COLLATE utf8_general_ci;
USE `shop`;
CREATE TABLE `account` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`name` VARCHAR(32) NOT NULL,
`cash` DECIMAL(9,2) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=INNODB DEFAULT CHARSET=utf8
INSERT INTO account (`name`,`cash`)
VALUES('A',2000.00),('B',10000.00)
-- 轉賬實現
SET autocommit = 0; -- 關閉自動提交
START TRANSACTION; -- 開始一個事務,標記事務的起始點
UPDATE account SET cash=cash-500 WHERE `name`='A';
UPDATE account SET cash=cash+500 WHERE `name`='B';
COMMIT; -- 提交事務
# rollback;
SET autocommit = 1; -- 恢復自動提交
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
3事務實現方式-MVCC
1什麼是MVCC
MVCC是mysql的的多版本並發控制即multi-Version Concurrency Controller，mysql的innodb引擎支持MVVC。MVCC是為了實現事務的隔離性，通過版本號，避免同一數據在不同事務間的競爭，你可以把它當成基於多版本號的一種樂觀鎖。當然，這種樂觀鎖只在事務級別為RR（可重復讀）和RC（讀提交）生效。MVCC最大的好處，相信也是耳熟能詳：讀不加鎖，讀寫不沖突，極大的增加了系統的並發性能。
2MVCC的實現機制
InnoDB在每行數據都增加兩個隱藏欄位，一個記錄創建的版本號，一個記錄刪除的版本號。
在多版本並發控制中，為了保證數據操作在多線程過程中，保證事務隔離的機制，降低鎖競爭的壓力，保證較高的並發量。在每開啟一個事務時，會生成一個事務的版本號，被操作的數據會生成一條新的數據行（臨時），但是在提交前對其他事務是不可見的；對於數據的更新（包括增刪改）操作成功，會將這個版本號更新到數據的行中；事務提交成功，新的版本號也就更新到了此數據行中。這樣保證了每個事務操作的數據，都是互不影響的，也不存在鎖的問題。
3MVCC下的CRUD
SELECT：
當隔離級別是REPEATABLE READ時select操作，InnoDB每行數據來保證它符合兩個條件：
** 1 事務的版本號 大於等於 創建行版本號**
** 2 行數據的刪除版本 未定義 或者大於 事務版本號**
【行創建版本號 事務版本號 行刪除版本號】
INSERT：
InnoDB為這個新行 記錄 當前的系統版本號。
DELETE：
InnoDB將當前的系統版本號 設置為 這一行的刪除版本號。
UPDATE：
InnoDB會寫一個這行數據的新拷貝，這個拷貝的版本為 當前的系統版本號。它同時也會將這個版本號 寫到 舊行的刪除版本里。
————————————————
版權聲明：本文為CSDN博主「@Autowire」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/zs18753479279/article/details/113933252