mysql怎么解決雙寫 MySQL 雙寫

linux下解決mysql區(qū)分大小寫問題怎么解決

具體操作如下：

我們提供的服務(wù)有：成都做網(wǎng)站、網(wǎng)站設(shè)計、外貿(mào)營銷網(wǎng)站建設(shè)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、路北ssl等。為上1000+企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學管理、有技術(shù)的路北網(wǎng)站制作公司

一、linux中mysql大小寫詳情：

1、數(shù)據(jù)庫名嚴格區(qū)分大小寫

2、表名嚴格區(qū)分大小寫的

3、表的別名嚴格區(qū)分大小寫

4、變量名嚴格區(qū)分大小寫

5、列名在所有的情況下均忽略大小寫

6、列的別名在所有的情況下均忽略大小寫

二、設(shè)置mysql表名不區(qū)分大小寫

1、切換到root用戶

root

2、修改/etc/my.cof配置文件，

sed

-i

'/\[mysqld\]/a\lower_case_table_names=1'

/etc/my.cnf

lower_case_table_names參數(shù)詳解：

0：區(qū)分大小寫

1：不區(qū)分大小寫

3、重啟mysql

service

mysqld

restart

MySQL innodb引擎深入講解

表空間(ibd文件),一個MySQL實例可以對應(yīng)多個表空間，用于存儲記錄，索引等數(shù)據(jù)。

段，分為數(shù)據(jù)段、索引段、回滾段，innodb是索引組織表，數(shù)據(jù)段就是B+Tree的葉子節(jié)點，索引段為非葉子節(jié)點，段用來管理多個區(qū)。

區(qū)，表空間的單元結(jié)構(gòu)，每個區(qū)的大小為1M,默認情況下，innodb存儲引擎頁大小為16K，即一個區(qū)中一共有64個連續(xù)的頁。

頁，是innodb存儲引擎磁盤管理的最小單元，每個頁的大小為16K，為了保證頁的連續(xù)性，innodb存儲引擎每次從磁盤申請4~5個區(qū)。

行，innodb存儲引擎數(shù)據(jù)是按行進行存儲的。Trx_id 最后一次事務(wù)操作的id、roll_pointer滾動指針。

i nnodb的內(nèi)存結(jié)構(gòu) ，由Buffer Pool、Change Buffer和Log Buffer組成。

Buffer Pool : 緩沖池是主內(nèi)存中的一個區(qū)域，里面可以緩存磁盤上經(jīng)常操作的真實數(shù)據(jù)，在執(zhí)行增刪改查操作時，先操作緩沖池中的數(shù)據(jù)(若緩沖池么有數(shù)據(jù)，則從磁盤加載并緩存)，然后再以一定頻率刷新磁盤，從而減少磁盤IO，加快處理速度。

緩沖池以page頁為單位，底層采用鏈表數(shù)據(jù)結(jié)構(gòu)管理page，根據(jù)狀態(tài)，將page分為三種類型:

1、free page 即空閑page，未被使用。

2、clean page 被使用page，數(shù)據(jù)沒有被修改過。

3、dirty page 臟頁，被使用page，數(shù)據(jù)被修改過，這個page當中的數(shù)據(jù)和磁盤當中的數(shù)據(jù) 不一致。說得簡單點就是緩沖池中的數(shù)據(jù)改了，磁盤中的沒改，因為還沒刷寫到磁盤。

Change Buffer ：更改緩沖區(qū)(針對于非唯一二級索引頁)，在執(zhí)行DML語句時，如果這些數(shù)據(jù)page沒有在Buffer Pool中，不會直接操作磁盤，而會將數(shù)據(jù)變更存在更改緩沖區(qū)Change Buffer中，在未來數(shù)據(jù)被讀取時。再將數(shù)據(jù)合并恢復(fù)到Buffer Pool中，再將合并后的數(shù)據(jù)刷新到磁盤中。

二級索引通常是非唯一的，并且以相對隨機的順序插入二級索引頁，同樣，刪除和更新可能會影響索引樹中不相鄰的二級索引頁。如果每一次都操作磁盤，會造成大量磁盤IO，有了Change Buffer之后，我們可以在緩沖池中進行合并處理，減少磁盤IO。

Adaptive Hash Index：自適應(yīng)hash索引，用于優(yōu)化對Buffer Pool數(shù)據(jù)的查詢，InnoDB存儲引擎會監(jiān)控對表上各索引頁的查詢，如果觀察到hash索引可以提升速度，則建立hash索引，稱之為自適應(yīng)hash索引。無需人工干預(yù)，系統(tǒng)根據(jù)情況自動完成。

參數(shù)：innodb_adaptive_hash_index

Log Buffer: 日志緩沖區(qū)，用來保存要寫入到磁盤中的log日志數(shù)據(jù)(redo log、undo log)，默認大小為16M，日志緩沖區(qū)的日志會定期刷新到磁盤中，如果需要更新，插入或刪除許多行的事務(wù)，增加日志緩沖區(qū)的大小可以節(jié)省磁盤IO。

參數(shù): innodb_log_buffer_size 緩沖區(qū)大小

innodb_flush_log_at_trx_commit 日志刷新到磁盤時機

innodb_flush_log_at_trx_commit=1 表示日志在每次事務(wù)提交時寫入并刷新到磁盤

2 表示日志在每次事務(wù)提交后寫入，并每秒刷新到磁盤一次

0 表示每秒將日志寫入并刷新到磁盤一次。

InnoDB 的磁盤結(jié)構(gòu)，由系統(tǒng)表空間(ibdata1)，獨立表空間(*.ibd),通用表空間，撤銷表空間(undo tablespaces), 臨時表空間(Temporary Tablespaces), 雙寫緩沖區(qū)(Doublewrite Buffer files), 重做日志(Redo Log).

系統(tǒng)表空間(ibdata1)：系統(tǒng)表空間是更改緩沖區(qū)的存儲區(qū)域，如果表是在系統(tǒng)表空間而不是每個表文件或者通用表空間中創(chuàng)建的，它也可能包含表和索引數(shù)據(jù)。

參數(shù)為: innodb_data_file_path

獨立表空間(*.ibd): 每個表的文件表空間包含單個innodb表的數(shù)據(jù)和索引，并存儲在文件系統(tǒng)上的單個數(shù)據(jù)文件中。參數(shù): innodb_file_per_table

通用表空間: 需要通過create tablespace 語法創(chuàng)建，創(chuàng)建表時可以指定該表空間。

create tablespace xxx add datafile 'file_name' engine=engine_name

create table table_name .... tablespace xxx

撤銷表空間(undo tablespaces): MySQL實例在初始化時會自動創(chuàng)建兩個默認的undo表空間(初始大小16K，undo_001,undo_002)，用于存儲undo log 日志

臨時表空間(Temporary Tablespaces)： innodb使用會話臨時表空和全局表空間，存儲用戶創(chuàng)建的臨時表等數(shù)據(jù)。

雙寫緩沖區(qū)(Doublewrite Buffer files)： innodb引擎將數(shù)據(jù)頁從Buffer Pool刷新到磁盤前，先將數(shù)據(jù)頁寫入緩沖區(qū)文件中，便于系統(tǒng)異常時恢復(fù)數(shù)據(jù)。

重做日志(Redo Log)：是用來實現(xiàn)事務(wù)的持久性，該日志文件由兩部分組成，重做日志緩沖區(qū)(redo log buffer)以及重做日志文件(redo log)，前者是在內(nèi)存中，后者在磁盤中，當事務(wù)提交之后會把修改信息都會存儲到該日志中，用于在刷新臟頁到磁盤時，發(fā)送錯誤時，進行數(shù)據(jù)恢復(fù)使用。以循環(huán)方式寫入重做日志文件，涉及兩個文件ib_logfile0,ib_logfile1。

那內(nèi)存結(jié)構(gòu)中的數(shù)據(jù)是如何刷新到磁盤中的? 在MySQL中有4個線程負責刷新日志到磁盤。

1、Master Thread， mysql核心后臺線程，負責調(diào)度其它線程，還負責將緩沖池中的數(shù)據(jù)異步刷新到磁盤中，保持數(shù)據(jù)的一致性，還包括臟頁的刷新，合并插入緩沖、undo頁的回收。

2、IO Thread，在innodb存儲引擎中大量使用了AIO來處理IO請求，這樣可以極大地提高數(shù) 據(jù)庫的性能，而IO Thead主要負責這些IO請求的回調(diào)。

4個讀線程 Read thread負責讀操作

4個寫線程write thread負責寫操作

1個Log thread線程負責將日志緩沖區(qū)刷新到磁盤

1個insert buffer線程負責將寫入緩沖區(qū)內(nèi)容刷新到磁盤

3、Purge Thread，主要用于回收事務(wù)已經(jīng)提交了的undo log，在事務(wù)提交之后，undo log 可能不用了，就用它來回收。

4、Page Cleaner Thread，協(xié)助Master Thread 刷新臟頁到磁盤的線程，它可以減輕主線程的壓力，減少阻塞。

事務(wù)就是一組操作的集合，它是一個不可分割的工作單位，事務(wù)會把所有的操作作為一個整體一起向系統(tǒng)提交或撤銷操作請求，即這些操作要么同時成功，要么同時失效。

事務(wù)的4大特性分為:

如何保證事務(wù)的4大特性，原子性，一致性和持久性是由innodb存儲引擎底層的兩份日志來保證的，分別是redo log和undo log。對于隔離性是由鎖機制和MVCC(多版本并發(fā)控制)來實現(xiàn)的。

redo log，稱為重做日志，記錄的是事務(wù)提交時數(shù)據(jù)頁的物理修改，是用來實現(xiàn)事務(wù)的持久性。該日志文件由兩部分組成: 重做日志緩沖redo log buffer及重做日志文件redo log file，前者是在內(nèi)存中，后者是在磁盤中，當事務(wù)提交之后會把所有修改信息都存到該日志文件中，用于在刷新臟頁到磁盤，發(fā)送錯誤時，進行數(shù)據(jù)的恢復(fù)使用，從而保證事務(wù)的持久性。

具體的操作流程是：

1、客戶端發(fā)起事務(wù)操作，包含多條DML語句。首先去innodb中的buffer pool中的數(shù)據(jù)頁去查找有沒有我們要更新的這些數(shù)據(jù)，如果沒有則通過后臺線程從磁盤中加載到buffer pool對應(yīng)的數(shù)據(jù)頁中，然后就可以在緩沖池中進行數(shù)據(jù)操作了。

2、此時緩沖池中的數(shù)據(jù)頁發(fā)生了變更，還沒刷寫到磁盤，這個數(shù)據(jù)頁稱為臟頁。臟頁不是實時刷新到磁盤的，而是根據(jù)你配置的刷寫策略進行刷寫到磁盤的（innodb_flush_log_at_trx_commit，0,1,2三個值）。如果臟頁在往磁盤刷新的時候出現(xiàn)了故障，會丟失數(shù)據(jù)，導致事務(wù)的持久性得不到保證。為了避免這種現(xiàn)象，當對緩沖池中的數(shù)據(jù)進行增刪改操作時，會把增刪改記錄到redo log buffer當中，redo log buffer會把數(shù)據(jù)頁的物理變更持久化到磁盤文件中(ib_logfile0/ib_logfile1)。如果臟頁刷新失敗，就可以通過這兩個日志文件進行恢復(fù)。

undo log，它是用來解決事務(wù)的原子性的，也稱為回滾日志。用于記錄數(shù)據(jù)被修改前的信息，作用包括:提供回滾和MVCC多版本并發(fā)控制。

undo log和redo log的記錄物理日志不一樣，它是邏輯日志?？梢哉J為當delete一條記錄時，undo log中會記錄一條對應(yīng)的insert記錄，當update一條記錄時，它記錄一條對應(yīng)相反的update記錄，當執(zhí)行rollback時，就可以從undo log中的邏輯記錄讀取到相應(yīng)的內(nèi)容并進行回滾。

undo log銷毀: undo log 在事務(wù)執(zhí)行時產(chǎn)生，事務(wù)提交時，并不會立即刪除undo log，因為這些日子可能用于MVCC。

undo log存儲: undo log 采用段的方式進行管理和記錄，存放在前面介紹的rollback segment回滾段中，內(nèi)部包含1024個undo log segment。

mvcc(multi-Version Concurrency Control),多版本并發(fā)控制，指維護一個數(shù)據(jù)的多個版本，使得讀寫操作沒有沖突，快照讀為MySQL實現(xiàn)MVCC提供了一個非阻塞讀功能，MVCC的具體實現(xiàn)，還需要依賴于數(shù)據(jù)庫記錄中的三個隱式字段，undo log日志、readView。

read committed 每次select 都生成一個快照讀

repeatable read 開啟事務(wù)后第一個select語句才是快照讀的地方

serializable 快照讀會退化為當前讀。

mvcc的實現(xiàn)原理

DB_TRX_ID: 最近修改事務(wù)ID，記錄插入這條記錄或最后一次修改該記錄的事務(wù)ID

DB_ROLL_PTR: 回滾指針，指向這條記錄的上一個版本，用于配合undo log，指向上一個版本

DB_ROW_ID: 隱藏主鍵，如果表結(jié)構(gòu)沒有指定主鍵，將會生成該隱藏字段。

m_ids當前活躍的事務(wù)ID集合

min_trx_id: 最小活躍事務(wù)id

max_trx_id: 預(yù)分配事務(wù)ID，當前最大事務(wù)id+1，因為事務(wù)id是自增的

creator_trx_id: ReadView創(chuàng)建者的事務(wù)ID

版本鏈數(shù)據(jù)訪問規(guī)則:

trx_id: 表示當前的事務(wù)ID

1、trx_id == creator_trx_id? 可以訪問讀版本--成立的話,說明數(shù)據(jù)是當前這個事務(wù)更改的

2、trx_id 成立,說明數(shù)據(jù)已經(jīng)提交了。

3、trx_idmax_trx_id？不可用訪問讀版本- 成立的話，說明該事務(wù)是在ReadView生成后才開啟的。

4、min_trx_id

如何修復(fù)mysql里面的ibdata1

當你啟用了 innodb_file_per_table，表被存儲在他們自己的表空間里，但是共享表空間仍然在存儲其它的 InnoDB 內(nèi)部數(shù)據(jù)：

數(shù)據(jù)字典，也就是 InnoDB 表的元數(shù)據(jù)

變更緩沖區(qū)

雙寫緩沖區(qū)

撤銷日志

其中的一些在 Percona 服務(wù)器上可以被配置來避免增長過大的。例如你可以通過 innodb_ibuf_max_size 設(shè)置最大變更緩沖區(qū)，或設(shè)置 innodb_doublewrite_file 來將雙寫緩沖區(qū)存儲到一個分離的文件。

MySQL的Binlog與主從復(fù)制

在MySQL中，可以使用多種存儲引擎。其中最常用的InnoDB引擎支持事務(wù)，Redo Log和Undo Log就是InnoDB里面的工具，用于實現(xiàn)事務(wù)。而Binlog是MySQL層面的東西，用于實現(xiàn)主從復(fù)制，與使用的存儲引擎無關(guān)。

通過監(jiān)聽并解析Mater的Binlog，也可以實現(xiàn)將MySQL中的數(shù)據(jù)同步到其他應(yīng)用組件中（比如更新緩存）的效果。

在不發(fā)生宕機的情況下，未提交的事務(wù)和已回滾的事務(wù)是不寫入Binlog日志中的，只有提交成功的事務(wù)才寫入Binlog日志。這一點和Redo Log不一樣，Redo Log中會記錄未提交、已回滾的事務(wù)內(nèi)容。

Binlog是一種邏輯日志——例如Binlog的statement格式記錄原始SQL語句、RAW格式記錄某一行修改前后的值——且一個事務(wù)的日志在Binlog中是連續(xù)排列的，因此要求每個事務(wù)都要串行地寫入，這意味著每個事務(wù)在寫B(tài)inlog之前都要排他地鎖住Binlog，這會導致寫的效率很低。MySQL5.6之后，通過pipline技術(shù)異步地批量化將已提交的事務(wù)內(nèi)容寫入Binlog。

一個事務(wù)的提交既要寫B(tài)inlog日志又要寫Redo Log日志，如何保證雙寫的原子性？一個寫成功，寫另外一個時發(fā)生宕機，重啟后如何處理？在討論這個問題之前，先說下Binlog自身寫入的原子性問題：Binlog刷盤到一半，出現(xiàn)宕機，這個問題和Redo Log的寫入原子性是同樣的問題，通過類似于checksum的辦法或者Binlog中的結(jié)束標記來判斷出某個事務(wù)的Binlog這是不是不完整的Binlog，從而把不完整的部分截掉。對于客戶端來說，此時宕機，事務(wù)肯定是沒有提交成功的，所以截掉也沒問題。下面來講如何保證雙寫B(tài)inlog和Redo Log的原子性。由于雙寫B(tài)inlog和Redo Log發(fā)生在同一臺機器上，這其實是一個內(nèi)部分布式事務(wù)，可以使用兩階段提交法來實現(xiàn)雙寫的原子性。簡單來說就是：

1）第一階段（準備階段）：MySQL Server要求innoDB完成將事務(wù)內(nèi)容寫入Redo Log中的工作，只等事務(wù)提交；以及，MySQL Server完成Binlog內(nèi)容寫入內(nèi)存的工作，只等刷盤。兩個都準備好之后，會向MySQL Server發(fā)送OK反饋，MySQL Server緊接著執(zhí)行第二階段。

2）第二階段（提交階段）：收到客戶端的Commit指令，MySQL Server先將內(nèi)存中的Binlog刷盤，然后讓innoDB執(zhí)行事務(wù)的提交。兩個都完成之后，會向MySQL Server發(fā)送OK反饋，兩階段提交結(jié)束。

若雙寫B(tài)inlog和Redo Log的過程中發(fā)生宕機，處理思路為：

1）若宕機發(fā)生在第一階段，此時Binlog還在內(nèi)存中，宕機導致全部消失。而Redo Log記錄了未提交的日志，MySQL Server重啟后感知到Binlog中不存在Redo Log中記錄的未提交事務(wù)，會自行回滾未提交事務(wù)的Redo Log日志；

2）若宕機發(fā)生在第二階段，Binlog寫了一半，innoDB還未執(zhí)行提交，MySQL Server重啟后會對Binlog做截斷，對Redo Log中記錄的未提交事務(wù)做回滾；

3）若宕機發(fā)生在第二階段，Binlog寫入成功，innoDB還未執(zhí)行提交，MySQL Server重啟后會通過checksum的辦法或者Binlog中的結(jié)束標記感知到Binlog寫入成功，緊接著對Binlog中存在的、但Redo Log未提交的事務(wù)發(fā)起提交。

在MySQL的Master / Slave集群模式中，有三種主從復(fù)制模式：

1）同步復(fù)制：所有的Slave都收到Master發(fā)送的Binlog，并且接收完，Master才認為事務(wù)提交成功，再對客戶端返回成功。這種方式最安全，但是性能很差；

2）異步復(fù)制：只要Master事務(wù)提交成功，就對客戶端返回成功。后臺線程異步地將Binlog發(fā)送給Slave，然后Slave回放Binlog。這種方式性能最好，但是可能會導致數(shù)據(jù)丟失；

3）半同步復(fù)制：Master事務(wù)提交后，同時把Binlog同步給Slave，只要有部分（數(shù)量可以配置）Slave收到了Binlog，就認為事務(wù)提交成功，對客戶端返回。

對于半異步復(fù)制，如果Slave超時后還未返回，也會退化為異步復(fù)制。所以無論是異步復(fù)制還是半異步復(fù)制，都無法嚴格保證主從中的數(shù)據(jù)完全一致，主從復(fù)制的延遲會導致主節(jié)點宕機后部分數(shù)據(jù)未來得及同步到從節(jié)點，從而丟失數(shù)據(jù)。但是主節(jié)點宕機后，還是要立即切換到從節(jié)點，保證服務(wù)的可用（犧牲一致性保證可用性），數(shù)據(jù)的丟失可以通過后續(xù)的人工干預(yù)來補償。

inndodb系列之雙寫

原因

mysql buffer中每頁數(shù)據(jù)16k，文件系統(tǒng)一頁4k 刷磁盤時，會遇到頁數(shù)據(jù)損壞問題

架構(gòu)

內(nèi)存+磁盤兩層結(jié)構(gòu)

磁盤大小2M 16k*128個頁

雙寫步驟

第一步：頁數(shù)據(jù)先memcopy到DWB的內(nèi)存里；

第二步：DWB的內(nèi)存里，會先刷到DWB的磁盤上；

第三步：DWB的內(nèi)存里，再刷到數(shù)據(jù)磁盤存儲上；

性能評估

（1）第一步，頁數(shù)據(jù)memcopy到DWB的內(nèi)存，速度很快；

（2）第二步，DWB的內(nèi)存fsync刷到DWB的磁盤，屬于順序追加寫，速度也很快；

（3）第三步，刷磁盤，隨機寫，本來就需要進行，不屬于額外操作；

參數(shù)

Innodb_dblwr_writes 記錄DWB寫操作的次數(shù)。

Innodb_dblwr_pages_written 記錄寫入DWB中頁的數(shù)量。

SQL show global status like "%dblwr%"

數(shù)據(jù)庫的事務(wù)機制是什么

回答的有點多請耐心看完。

希望能幫助你還請及時采納謝謝

1事務(wù)的原理

事務(wù)就是將一組SQL語句放在同一批次內(nèi)去執(zhí)行，如果一個SQL語句出錯,則該批次內(nèi)的所有SQL都將被取消執(zhí)行。MySQL事務(wù)處理只支持InnoDB和BDB數(shù)據(jù)表類型。

1事務(wù)的ACID原則

** 1（Atomicity）原子性**：事務(wù)是最小的執(zhí)行單位，不允許分割。原子性確保動作要么全部完成，要么完全不起作用；

2（Consistency）一致性：執(zhí)行事務(wù)前后，數(shù)據(jù)保持一致；

3（Isolation）隔離性：并發(fā)訪問數(shù)據(jù)庫時，一個事務(wù)不被其他事務(wù)所干擾。

4（Durability）持久性: 一個事務(wù)被提交之后。對數(shù)據(jù)庫中數(shù)據(jù)的改變是持久的，即使數(shù)據(jù)庫發(fā)生故障。

1緩沖池（Buffer Pool）

Buffer Pool中包含了磁盤中部分數(shù)據(jù)頁的映射。當從數(shù)據(jù)庫讀取數(shù)據(jù)時，會先從Buffer Pool中讀取數(shù)據(jù)，如果Buffer Pool中沒有，則從磁盤讀取后放入到Buffer Pool中。當向數(shù)據(jù)庫寫入數(shù)據(jù)時，會先寫入到Buffer Pool中，Buffer Pool中更新的數(shù)據(jù)會定期刷新到磁盤中（此過程稱為刷臟）。

2日志緩沖區(qū)（Log Buffer）

當在MySQL中對InnoDB表進行更改時，這些更改命令首先存儲在InnoDB日志緩沖區(qū)（Log Buffer）的內(nèi)存中，然后寫入通常稱為重做日志（redo logs）的InnoDB日志文件中。

3雙寫機制緩存（DoubleWrite Buffer）

Doublewrite Buffer是共享表空間的物理文件的 buffer,其大小是2MB.是一個一分為二的2MB空間。

刷臟操作開始之時,先進行臟頁**‘備份’**操作.將臟頁數(shù)據(jù)寫入 Doublewrite Buffer.

將Doublewrite Buffer(順序IO)寫入磁盤文件中(共享表空間) 進行刷臟操作.

4回滾日志(Undo Log)

Undo Log記錄的是邏輯日志.記錄的是事務(wù)過程中每條數(shù)據(jù)的變化版本和情況.

在Innodb 磁盤架構(gòu)中Undo Log 默認是共享表空間的物理文件的Buffer.

在事務(wù)異常中斷,或者主動(Rollback)回滾的過程中 ,Innodb基于 Undo Log進行數(shù)據(jù)撤銷回滾,保證數(shù)據(jù)回歸至事務(wù)開始狀態(tài).

5重做日志(Redo Log)

Redo Log通常指的是物理日志，記錄的是數(shù)據(jù)頁的物理修改.并不記錄行記錄情況。（也就是只記錄要做哪些修改，并不記錄修改的完成情況）當數(shù)據(jù)庫宕機重啟的時候，會將重做日志中的內(nèi)容恢復(fù)到數(shù)據(jù)庫中。

1原子性

Innodb事務(wù)的原子性保證,包含事務(wù)的提交機制和事務(wù)的回滾機制.在Innodb引擎中事務(wù)的回滾機制是依托回滾日志(Undo Log) 進行回滾數(shù)據(jù)，保證數(shù)據(jù)回歸至事務(wù)開始狀態(tài).

2那么不同的隔離級別，隔離性是如何實現(xiàn)的，為什么不同事物間能夠互不干擾？答案是鎖和 MVCC。

3持久性

基于事務(wù)的提交機制流程有可能出現(xiàn)三種場景.

1 數(shù)據(jù)刷臟正常.一切正常提交，Redo Log 循環(huán)記錄.數(shù)據(jù)成功落盤.持久性得以保證

2數(shù)據(jù)刷臟的過程中出現(xiàn)的系統(tǒng)意外導致頁斷裂現(xiàn)象 (部分刷臟成功)，針對頁斷裂情況,采用Double write機制進行保證頁斷裂數(shù)據(jù)的恢復(fù).

3數(shù)據(jù)未出現(xiàn)頁斷裂現(xiàn)象,也沒有刷臟成功，MySQL通過Redo Log 進行數(shù)據(jù)的持久化即可

4一致性

從數(shù)據(jù)庫層面，數(shù)據(jù)庫通過原子性、隔離性、持久性來保證一致性

2事務(wù)的隔離級別

Mysql 默認采用的 REPEATABLE_READ隔離級別 Oracle 默認采用的 READ_COMMITTED隔離級別

臟讀：指一個事務(wù)讀取了另外一個事務(wù)未提交的數(shù)據(jù)。

不可重復(fù)讀：在一個事務(wù)內(nèi)讀取表中的某一行數(shù)據(jù)，多次讀取結(jié)果不同

虛讀(幻讀)：是指在一個事務(wù)內(nèi)讀取到了別的事務(wù)插入的數(shù)據(jù)，導致前后讀取不一致。

2基本語法

-- 使用set語句來改變自動提交模式

SET autocommit = 0; /*關(guān)閉*/

SET autocommit = 1; /*開啟*/

-- 注意:

--- 1.MySQL中默認是自動提交

--- 2.使用事務(wù)時應(yīng)先關(guān)閉自動提交

-- 開始一個事務(wù),標記事務(wù)的起始點

START TRANSACTION

-- 提交一個事務(wù)給數(shù)據(jù)庫

COMMIT

-- 將事務(wù)回滾,數(shù)據(jù)回到本次事務(wù)的初始狀態(tài)

ROLLBACK

-- 還原MySQL數(shù)據(jù)庫的自動提交

SET autocommit =1;

-- 保存點

SAVEPOINT 保存點名稱 -- 設(shè)置一個事務(wù)保存點

ROLLBACK TO SAVEPOINT 保存點名稱 -- 回滾到保存點

RELEASE SAVEPOINT 保存點名稱 -- 刪除保存點

課堂測試題目

A在線買一款價格為500元商品,網(wǎng)上銀行轉(zhuǎn)賬.

A的銀行卡余額為2000,然后給商家B支付500.

商家B一開始的銀行卡余額為10000

創(chuàng)建數(shù)據(jù)庫shop和創(chuàng)建表account并插入2條數(shù)據(jù)

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)

-- 轉(zhuǎn)賬實現(xiàn)

SET autocommit = 0; -- 關(guān)閉自動提交

START TRANSACTION; -- 開始一個事務(wù),標記事務(wù)的起始點

UPDATE account SET cash=cash-500 WHERE `name`='A';

UPDATE account SET cash=cash+500 WHERE `name`='B';

COMMIT; -- 提交事務(wù)

# rollback;

SET autocommit = 1; -- 恢復(fù)自動提交

3事務(wù)實現(xiàn)方式-MVCC

1什么是MVCC

MVCC是mysql的的多版本并發(fā)控制即multi-Version Concurrency Controller，mysql的innodb引擎支持MVVC。MVCC是為了實現(xiàn)事務(wù)的隔離性，通過版本號，避免同一數(shù)據(jù)在不同事務(wù)間的競爭，你可以把它當成基于多版本號的一種樂觀鎖。當然，這種樂觀鎖只在事務(wù)級別為RR（可重復(fù)讀）和RC（讀提交）生效。MVCC最大的好處，相信也是耳熟能詳：讀不加鎖，讀寫不沖突，極大的增加了系統(tǒng)的并發(fā)性能。

2MVCC的實現(xiàn)機制

InnoDB在每行數(shù)據(jù)都增加兩個隱藏字段，一個記錄創(chuàng)建的版本號，一個記錄刪除的版本號。

在多版本并發(fā)控制中，為了保證數(shù)據(jù)操作在多線程過程中，保證事務(wù)隔離的機制，降低鎖競爭的壓力，保證較高的并發(fā)量。在每開啟一個事務(wù)時，會生成一個事務(wù)的版本號，被操作的數(shù)據(jù)會生成一條新的數(shù)據(jù)行（臨時），但是在提交前對其他事務(wù)是不可見的；對于數(shù)據(jù)的更新（包括增刪改）操作成功，會將這個版本號更新到數(shù)據(jù)的行中；事務(wù)提交成功，新的版本號也就更新到了此數(shù)據(jù)行中。這樣保證了每個事務(wù)操作的數(shù)據(jù)，都是互不影響的，也不存在鎖的問題。

3MVCC下的CRUD

SELECT：

當隔離級別是REPEATABLE READ時select操作，InnoDB每行數(shù)據(jù)來保證它符合兩個條件：

** 1 事務(wù)的版本號大于等于創(chuàng)建行版本號**

　 ** 2 行數(shù)據(jù)的刪除版本未定義或者大于事務(wù)版本號**

　【行創(chuàng)建版本號事務(wù)版本號行刪除版本號】

INSERT：

InnoDB為這個新行記錄當前的系統(tǒng)版本號。

DELETE：

InnoDB將當前的系統(tǒng)版本號設(shè)置為這一行的刪除版本號。

UPDATE：

InnoDB會寫一個這行數(shù)據(jù)的新拷貝，這個拷貝的版本為當前的系統(tǒng)版本號。它同時也會將這個版本號寫到舊行的刪除版本里。

————————————————

版權(quán)聲明：本文為CSDN博主「@Autowire」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。

原文鏈接：

文章題目：mysql怎么解決雙寫 MySQL 雙寫
分享路徑：http://www.ekvhdxd.cn/article6/dodipig.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計公司、品牌網(wǎng)站設(shè)計、商城網(wǎng)站、云服務(wù)器、網(wǎng)站營銷、軟件開發(fā)

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容