整合營(yíng)銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
一."SQL Server 不存在或訪問被拒絕"
這個(gè)是最復(fù)雜的,錯(cuò)誤發(fā)生的原因比較多,需要檢查的方面也比較多.
一般說來,有以下幾種可能性:
1,SQL Server名稱或IP地址拼寫有誤
2,服務(wù)器端網(wǎng)絡(luò)配置有誤
3,客戶端網(wǎng)絡(luò)配置有誤
要解決這個(gè)問題,我們一般要遵循以下的步驟來一步步找出導(dǎo)致錯(cuò)誤的原因.
首先,檢查網(wǎng)絡(luò)物理連接
ping
如果 ping 不成功,說明物理連接有問題,這時(shí)候要檢查硬件設(shè)備,如網(wǎng)卡,HUB,路由器等.
還有一種可能是由于客戶端和服務(wù)器之間安裝有防火墻軟件造成的,比如 ISA Server.防火墻軟件可能會(huì)屏蔽對(duì) ping,telnet 等的響應(yīng)
因此在檢查連接問題的時(shí)候,我們要先把防火墻軟件暫時(shí)關(guān)閉,或者打開所有被封閉的端口.
如果ping 成功而,ping 失敗
則說明名字解析有問題,這時(shí)候要檢查 DNS 服務(wù)是否正常.
有時(shí)候客戶端和服務(wù)器不在同一個(gè)局域網(wǎng)里面,這時(shí)候很可能無法直接使用服務(wù)器名稱來標(biāo)識(shí)該服務(wù)器,這時(shí)候我們可以使用HOSTS文件來進(jìn)行名字解析,
具體的方法是:
1.使用記事本打開HOSTS文件（一般情況下位于C:\WINNT\\drivers\etc）.
添加一條IP地址與服務(wù)器名稱的對(duì)應(yīng)記錄,如:
172.168.10.24
2.或在 SQL Server 的客戶端網(wǎng)絡(luò)實(shí)用工具里面進(jìn)行配置,后面會(huì)有詳細(xì)說明.
其次,使用 telnet 命令檢查SQL Server服務(wù)器工作狀態(tài)
telnet 1433
如果命令執(zhí)行成功,可以看到屏幕一閃之后光標(biāo)在左上角不停閃動(dòng),這說明 SQL Server 服務(wù)器工作正常,并且正在監(jiān)聽1433端口的 TCP/IP 連接
如果命令返回"無法打開連接"的錯(cuò)誤信息,則說明服務(wù)器端沒有啟動(dòng) SQL Server 服務(wù),
也可能服務(wù)器端沒啟用 TCP/IP 協(xié)議,或者服務(wù)器端沒有在 SQL Server 默認(rèn)的端口1433上監(jiān)聽.
接著,我們要到服務(wù)器上檢查服務(wù)器端的網(wǎng)絡(luò)配置,檢查是否啟用了命名管道.是否啟用了 TCP/IP 協(xié)議等等
可以利用 SQL Server 自帶的服務(wù)器網(wǎng)絡(luò)使用工具來進(jìn)行檢查.
點(diǎn)擊:程序 SQL Server 服務(wù)器網(wǎng)絡(luò)使用工具
打開該工具后,在"常規(guī)"中可以看到服務(wù)器啟用了哪些協(xié)議.
一般而言,我們啟用命名管道以及 TCP/IP 協(xié)議.
點(diǎn)中 TCP/IP 協(xié)議,選擇"屬性",我們可以來檢查 SQK Server 服務(wù)默認(rèn)端口的設(shè)置
一般而言,我們使用 SQL Server 默認(rèn)的1433端口.如果選中"隱藏服務(wù)器",則意味著客戶端無法通過枚舉服務(wù)器來看到這臺(tái)服務(wù)器,起到了保護(hù)的作用,但不影響連接.
接下來我們要到客戶端檢查客戶端的網(wǎng)絡(luò)配置
我們同樣可以利用 SQL Server 自帶的客戶端網(wǎng)絡(luò)使用工具來進(jìn)行檢查,
所不同的是這次是在客戶端來運(yùn)行這個(gè)工具.
點(diǎn)擊:程序 SQL Server 客戶端網(wǎng)絡(luò)使用工具
打開該工具后,在"常規(guī)"項(xiàng)中,可以看到客戶端啟用了哪些協(xié)議.
一般而言,我們同樣需要啟用命名管道以及 TCP/IP 協(xié)議.
點(diǎn)擊 TCP/IP 協(xié)議,選擇"屬性",可以檢查客戶端默認(rèn)連接端口的設(shè)置,該端口必須與服務(wù)器一致.
單擊"別名"選項(xiàng)卡,還可以為服務(wù)器配置別名.服務(wù)器的別名是用來連接的名稱,
連接參數(shù)中的服務(wù)器是真正的服務(wù)器名稱,兩者可以相同或不同.別名的設(shè)置與使用HOSTS文件有相似之處.
通過以上幾個(gè)方面的檢查,基本上可以排除第一種錯(cuò)誤.
二."無法連接到服務(wù)器,用戶xxx登陸失敗"
該錯(cuò)誤產(chǎn)生的原因是由于SQL Server使用了"僅 Windows"的身份驗(yàn)證方式,
因此用戶無法使用SQL Server的登錄帳戶（如 sa ）進(jìn)行連接.解決方法如下所示:
1.在服務(wù)器端使用企業(yè)管理器,并且選擇"使用 Windows 身份驗(yàn)證"連接上 SQL Server
2.展開"SQL Server組",鼠標(biāo)右鍵點(diǎn)擊SQL Server服務(wù)器的名稱,選擇"屬性",再選擇"安全性"選項(xiàng)卡
3.在"身份驗(yàn)證"下,選擇"SQL Server和 Windows ".
4.重新啟動(dòng)SQL Server服務(wù).
在以上解決方法中,如果在第 1 步中使用"使用 Windows 身份驗(yàn)證"連接 SQL Server 失敗,
那就通過修改注冊(cè)表來解決此問題:
1.點(diǎn)擊"開始""運(yùn)行",輸入regedit,回車進(jìn)入注冊(cè)表編輯器
2.依次展開注冊(cè)表項(xiàng),瀏覽到以下注冊(cè)表鍵:
[\\\\]
3.在屏幕右方找到名稱"",雙擊編輯雙字節(jié)值
4.將原值從1改為2,點(diǎn)擊"確定"
5.關(guān)閉注冊(cè)表編輯器
6.重新啟動(dòng)SQL Server服務(wù).
此時(shí),用戶可以成功地使用sa在企業(yè)管理器中新建SQL Server注冊(cè),
但是仍然無法使用Windows身份驗(yàn)證模式來連接SQL Server.
這是因?yàn)樵?SQL Server 中有兩個(gè)缺省的登錄帳戶:
BUILTIN\
\ 被刪除.
要恢復(fù)這兩個(gè)帳戶,可以使用以下的方法:
1.打開企業(yè)管理器,展開服務(wù)器組,然后展開服務(wù)器
2.展開"安全性",右擊"登錄",然后單擊"新建登錄"
3.在"名稱"框中,輸入 BUILTIN\
4.在"服務(wù)器角色"選項(xiàng)卡中,選擇"System "
5.點(diǎn)擊"確定"退出
6.使用同樣方法添加 \ 登錄.
說明:
以下注冊(cè)表鍵:
\\\\\
的值決定了SQL Server將采取何種身份驗(yàn)證模式.
1.表示使用"Windows 身份驗(yàn)證"模式
2.表示使用混合模式（Windows 身份驗(yàn)證和 SQL Server 身份驗(yàn)證）.
三.提示連接超時(shí)
如果遇到第三個(gè)錯(cuò)誤,一般而言表示客戶端已經(jīng)找到了這臺(tái)服務(wù)器,并且可以進(jìn)行連接,
不過是由于連接的時(shí)間大于允許的時(shí)間而導(dǎo)致出錯(cuò).
這種情況一般會(huì)發(fā)生在當(dāng)用戶在上運(yùn)行企業(yè)管理器來注冊(cè)另外一臺(tái)同樣在上的服務(wù)器,
并且是慢速連接時(shí),有可能會(huì)導(dǎo)致以上的超時(shí)錯(cuò)誤.有些情況下,由于局域網(wǎng)的網(wǎng)絡(luò)問題,也會(huì)導(dǎo)致這樣的錯(cuò)誤.
要解決這樣的錯(cuò)誤,可以修改客戶端的連接超時(shí)設(shè)置.
默認(rèn)情況下,通過企業(yè)管理器注冊(cè)另外一臺(tái)SQL Server的超時(shí)設(shè)置是 4 秒,
而查詢分析器是 15 秒（這也是為什么在企業(yè)管理器里發(fā)生錯(cuò)誤的可能性比較大的原因）.
具體步驟為:
企業(yè)管理器中的設(shè)置:
1.在企業(yè)管理器中,選擇菜單上的"工具",再選擇"選項(xiàng)"
2.在彈出的"SQL Server企業(yè)管理器屬性"窗口中,點(diǎn)擊"高級(jí)"選項(xiàng)卡
3.在"連接設(shè)置"下的"登錄超時(shí)（秒）"右邊的框中輸入一個(gè)比較大的數(shù)字,如 20.
查詢分析器中的設(shè)置:
工具 選項(xiàng) 連接 將登錄超時(shí)設(shè)置為一個(gè)較大的數(shù)字
連接超時(shí)改為0
1、先保證ping通
2、在dos下寫入telnet ip 1433不會(huì)報(bào)錯(cuò)
3、用ip連如企業(yè)管理器：
企業(yè)管理器>右鍵組>新建注冊(cè)>下一步>寫入遠(yuǎn)程實(shí)例名（IP,機(jī)器名）>下一步>選登陸>下一步>寫入登陸名與密碼（sa,pass）>下一步>下一步>完成
4、如果還不行：
服務(wù)器>開始菜單>>服務(wù)器網(wǎng)絡(luò)實(shí)用工具>啟用 WinSock代理>代理地址：(服務(wù)器IP)>代理端口>1433>OK了
5、如果還不行：
客戶端>開始菜單>>客戶端網(wǎng)絡(luò)實(shí)用工具>別名>添加>寫入別名如"大力">"網(wǎng)絡(luò)庫(kù)"選tcp/ip>服務(wù)器名稱寫入遠(yuǎn)程ip或?qū)嵗?OK了
深入解讀MySQL InnoDB存儲(chǔ)引擎Update語句執(zhí)行過程
一丶Mysql整體架構(gòu)#
MySQL 可以分為 Server 層和存儲(chǔ)引擎層兩部分
1.Server 層#
Server 層包括連接器、查詢緩存、分析器、優(yōu)化器、執(zhí)行器等，涵蓋 MySQL 的大多數(shù)核心服務(wù)功能，以及所有的內(nèi)置函數(shù)（如日期、時(shí)間、數(shù)學(xué)和加密函數(shù)等），所有跨存儲(chǔ)引擎的功能都在這一層實(shí)現(xiàn)，比如存儲(chǔ)過程、觸發(fā)器、視圖等。
2.存儲(chǔ)引擎層#
存儲(chǔ)引擎層負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和提取。其架構(gòu)模式是插件式的，支持 InnoDB、MyISAM、Memory 等多個(gè)存儲(chǔ)引擎。現(xiàn)在最常用的存儲(chǔ)引擎是 InnoDB，它從 MySQL 5.5.5 版本開始成為了默認(rèn)存儲(chǔ)引擎。下面我們對(duì)比兩個(gè)常用的存儲(chǔ)引擎
MyISAM
InnoDB
存儲(chǔ)結(jié)構(gòu)
Myisam 創(chuàng)建表后生成的文件有三個(gè)，分別為： frm:創(chuàng)建表的語句 MYD:表里面的數(shù)據(jù)文件（myisam data） MYI:表里面的索引文件（myisam index）
Innodb 創(chuàng)建表后生成的文件有兩個(gè)，分別為： frm:創(chuàng)建表的語句 idb:表里面的數(shù)據(jù)+索引文件
索引
非聚集索引，MyISAM 是非聚集索引，數(shù)據(jù)文件是分離的，索引保存的是數(shù)據(jù)文件的指針。主鍵索引和輔助索引是獨(dú)立的。
聚集索引，聚集索引的文件存放在主鍵索引的葉子節(jié)點(diǎn)上
事務(wù)支持
不提供事務(wù)支持
提供事務(wù)支持
鎖的粒度
只支持表級(jí)鎖
支持行級(jí)鎖。
存儲(chǔ)表的具體行數(shù)
保存表的總行數(shù)，如果select count() from table;會(huì)直接取出出該值。
沒有保存表的總行數(shù)，如果使用select count(*) from table；就會(huì)遍歷整個(gè)表，消耗相當(dāng)大，但是在加了wehre條件后，myisam和innodb處理的方式都一樣。
以下的分析針對(duì) update t set a='1' where 主鍵 = 1這條語句
二丶開啟事務(wù)#
在mysql中，無論用戶是否手動(dòng)開啟一個(gè)事務(wù)，sql都是在一個(gè)事務(wù)中進(jìn)行的。我們可以使用start 開啟一個(gè)事務(wù)，commit提交事務(wù)，回滾事務(wù)。
默認(rèn)情況下，mysql存在自動(dòng)提交(=1)，這時(shí)候即使我們沒有顯式開啟事務(wù)，直接執(zhí)行update語句，那么mysql會(huì)隱式的開啟一個(gè)事務(wù)，并在這條update執(zhí)行結(jié)束后自動(dòng)提交
如果set = 0 或者顯式開啟了一個(gè)事務(wù)，那么update執(zhí)行結(jié)束后不會(huì)自動(dòng)提交，而是需要手動(dòng)發(fā)起commit 或者
無論式顯式事務(wù)，還是隱式事務(wù)，mysql都會(huì)在事務(wù)內(nèi)部第一次執(zhí)行增刪改操作的時(shí)候，給事務(wù)分配一個(gè)事務(wù)號(hào)
三丶Sql解析，查詢計(jì)劃生成#
mysql服務(wù)器層會(huì)從連接中讀取sql語句，然后進(jìn)行詞法解析，語法解析，查詢優(yōu)化（為什么update語句需要查詢優(yōu)化？不查出來怎么知道修改哪些行數(shù)據(jù)昵）最終生成一個(gè)AST樹，這便是物理執(zhí)行計(jì)劃，執(zhí)行器會(huì)根據(jù)執(zhí)行計(jì)劃，調(diào)用存儲(chǔ)引擎的接口，
四丶查詢需要修改的數(shù)據(jù)#
Mysql InnoDB Buffer Pool
Mysql索引(究極無敵細(xì)節(jié)版
mysql innodb存儲(chǔ)引擎對(duì)磁盤的讀取是以頁為單位的，為了避免每次都從磁盤讀取數(shù)據(jù)，innodb存在buffer pool使用LRU鏈表維護(hù)最近訪問到的頁，為了更快的從buffer pool中查找到目標(biāo)頁，innodb 還使用表空間號(hào)和頁號(hào)作為key，頁作為value，形成Hash表。如果我們目標(biāo)頁已經(jīng)在buffer pool中那么直接返回目標(biāo)頁，如果不在那么需要進(jìn)行磁盤io加載目標(biāo)頁到內(nèi)存，然后緩存到buffer pool中
1.buffer pool是如何維護(hù)頁在內(nèi)存中的#
buffer poo中存在三個(gè)關(guān)鍵的鏈表結(jié)構(gòu)
2.怎么從16k的頁中找到目標(biāo)數(shù)據(jù)#
結(jié)合B+樹索引結(jié)構(gòu)，執(zhí)行引擎根據(jù)頁號(hào)找到根節(jié)點(diǎn)，然后根據(jù)根節(jié)點(diǎn)中的索引數(shù)據(jù)進(jìn)行比較，找到子節(jié)點(diǎn)，重復(fù)此過程直至找到葉子節(jié)點(diǎn)所在的頁。
到了葉子節(jié)點(diǎn)所在的頁后，根據(jù)葉子節(jié)點(diǎn)頁中的Page 中的槽找到目標(biāo)記錄所在的組，然后遍歷這一組中的記錄，找到目標(biāo)記錄。如果是范圍查詢，還需要根據(jù)B+樹葉子節(jié)點(diǎn)間的雙向指針繼續(xù)查找，直到找到不符合要求的記錄位置。（為了避免我們?cè)诒闅vB+樹的時(shí)候，其他線程修改了B+樹的結(jié)構(gòu)，此過程還需要對(duì)B+樹進(jìn)行加閂鎖）（詳細(xì)可看 Mysql索引(究極無敵細(xì)節(jié)版中的InnoDB索引方案一節(jié)）
五丶檢驗(yàn)鎖和加鎖#
Mysql 鎖
1.Mysql中的鎖#innodb 行鎖官方名稱
記錄鎖有S鎖和X鎖，S型記錄鎖之間可以共享，X型記錄鎖和S型記錄鎖，X型記錄鎖互斥innodb的可重復(fù)讀級(jí)別，使用詞鎖解決幻讀問題，前面我們說過，其難點(diǎn)在于，加鎖的時(shí)候幻影記錄還未出現(xiàn)。官方使用實(shí)現(xiàn)如下操作
此處的gap鎖可以反之其他事務(wù)在number為8記錄前面的間隙插入新的記錄，在區(qū)間（3，8）內(nèi)無法進(jìn)行插入操作，當(dāng)另外一個(gè)事務(wù)要插入number為4的記錄時(shí)，首先需要定位到該條記錄的下一條記錄，也就是number為8的記錄，此時(shí)number為8的記錄具備gap鎖，所以將阻塞插入操作，直到gap鎖被釋放，其他事務(wù)才能進(jìn)行插入。
gap鎖出現(xiàn)的目的，就是為了防止插入幻影記錄，如果對(duì)記錄上gap鎖，并不會(huì)限制其他事務(wù)對(duì)記錄加記錄鎖。innodb有兩個(gè)虛擬的記錄Infimum(虛擬最小)，(虛擬最大)當(dāng)我們想在(xx,正無窮)范圍鎖住幻影記錄時(shí)就可以對(duì)加gap鎖。Next-Key Lock = 記錄鎖 + gap鎖，既鎖住記錄，也鎖住記錄之前的間隙
插入意向鎖，表示事務(wù)想在某個(gè)間隙插入新的記錄，但是當(dāng)前處于等待狀態(tài)。比如事務(wù)A持有（4，8）范圍內(nèi)的gap鎖，事務(wù)B和C，想插入（4，8）范圍內(nèi)的記錄，就會(huì)在內(nèi)存中生成事務(wù)B，C對(duì)應(yīng)的插入意向鎖，當(dāng)前事務(wù)A釋放gap鎖的時(shí)候，將喚醒事務(wù)B和C，事務(wù)B和C可以同時(shí)獲取插入意向鎖，然后進(jìn)行插入。插入意向鎖并不會(huì)阻止對(duì)記錄繼續(xù)上鎖。為事務(wù)生成內(nèi)存中的鎖結(jié)構(gòu)并不是一個(gè)0成本的事情，為了節(jié)省這個(gè)成本，提出隱式鎖的概念。當(dāng)一個(gè)事務(wù)插入語一條記錄A，其他事務(wù)select xxx Lock in share mode讀取記錄A（獲取記錄A的S鎖），或者使用select xxx for update（獲取記錄A的X鎖）立即修改記錄A（獲取x鎖）對(duì)于聚簇索引來說，有一個(gè)隱藏列trx_id此列存儲(chǔ)著最后更改記錄的事務(wù)id，在當(dāng)前事務(wù)A插入記錄后，便是存儲(chǔ)著當(dāng)前事務(wù)A的id，其他事務(wù)B企圖獲取x鎖，s鎖的時(shí)候，就需要下先看一下，trx_id隱藏列對(duì)應(yīng)的事務(wù)是否存活，如果不是那么正常獲取，反之需要為當(dāng)前事務(wù)A創(chuàng)建一個(gè)x鎖內(nèi)存結(jié)構(gòu)，并標(biāo)記為false，然后事務(wù)B將為自己創(chuàng)建一個(gè)鎖結(jié)構(gòu)， 為true然后事務(wù)B進(jìn)入等待狀態(tài)對(duì)于二級(jí)索引來說，其不具備隱藏列trx_id但是在二級(jí)索引頁面的page header中的屬性，記錄了改動(dòng)頁面最大的事務(wù)id，如果其屬性值小于當(dāng)前最小的活躍事務(wù)id，那么說明對(duì)頁面的改動(dòng)事務(wù)已經(jīng)提交，否則需要定位到二級(jí)索引記錄，然后回表對(duì)聚簇索引進(jìn)行上述聚簇索引的操作。一個(gè)事務(wù)對(duì)新插入的記錄不需要顯示的加鎖，由于事務(wù)id的存在相當(dāng)于加了一個(gè)隱式鎖，別的事務(wù)需要加S鎖或者X鎖的時(shí)候，先幫之前的事務(wù)生成鎖結(jié)構(gòu)，然后為自己生成鎖結(jié)構(gòu)，再進(jìn)入阻塞狀態(tài)。隱式鎖起到了延遲加鎖的作用，也許別的事務(wù)不會(huì)獲取于隱式鎖沖突的鎖，這時(shí)候可以減少內(nèi)存中生成鎖結(jié)構(gòu)。2.一條Update語句涉及的鎖#
2.1加共享元數(shù)據(jù)鎖#
為了避免當(dāng)前事務(wù)操作的時(shí)候，存在另外的用戶對(duì)當(dāng)前表進(jìn)行DDL操作，mysql首先會(huì)為當(dāng)前操作的表加共享元數(shù)據(jù)鎖。這個(gè)過程可能存在阻塞的可能，如果當(dāng)前事務(wù)企圖加共享元數(shù)據(jù)鎖的時(shí)候，存在另外一個(gè)事務(wù)正在對(duì)表進(jìn)行DDL操作，這時(shí)候另外一個(gè)事務(wù)上了互斥元數(shù)據(jù)鎖，這時(shí)候會(huì)出現(xiàn)當(dāng)前事務(wù)阻塞的情況
2.2 加表級(jí)意向互斥鎖#
此階段也可能存在阻塞，但是由于innodb支持行鎖，基本上很少有人給表上鎖。如果執(zhí)行當(dāng)前事務(wù)之前存在另外一個(gè)事務(wù)給表上了表記共享鎖，表記互斥鎖，那么當(dāng)前操作也會(huì)被阻塞。
加表記意向鎖的好處在于，若沒有意向鎖，那么其他事務(wù)對(duì)表加鎖的時(shí)候，需要遍歷表中所有記錄確保當(dāng)前行中的記錄沒有被上鎖
2.3 行鎖#
innodb中的行鎖，其實(shí)是在內(nèi)存中，為當(dāng)前行生成一個(gè)鎖結(jié)構(gòu)，記錄事務(wù)id，索引信息，鎖信息，鎖類型等.如果當(dāng)前事務(wù)加鎖的時(shí)候，記錄并沒有加鎖，那么會(huì)生成一個(gè)鎖結(jié)構(gòu)存儲(chǔ)于內(nèi)存中。如果鎖已經(jīng)被占用那么會(huì)掛起當(dāng)前事務(wù)，直到鎖被釋放后喚醒當(dāng)前事務(wù)。
六丶修改數(shù)據(jù)和生成日志#
在成功上鎖之后，就可以放心的更新數(shù)據(jù)了，innodb將寫三部分內(nèi)容
1.寫緩沖頁#
不進(jìn)行需要修改sql中指定的字段，還需要更新trx_id=當(dāng)前事務(wù)的id, = 指向undo log
buffer pool中臟頁的刷盤依賴于后臺(tái)定時(shí)任務(wù)線程定時(shí)進(jìn)行刷新，如果修改到此為止將存在數(shù)據(jù)丟失的問題，為此innodb存儲(chǔ)引擎還需要寫入以下兩種日志
2.寫undo log#
Mysql InnoDB多版本并發(fā)控制MVCC
undo log是為了記錄行數(shù)據(jù)修改前的結(jié)果，用于回滾和mvcc。undo log 可以分為兩種——記錄insert undo log，和 update/delete undo log，生成的undo log會(huì)寫入到undo log buffer。
2.1.mvcc#
如圖多個(gè)版本的數(shù)據(jù)，在undo log中進(jìn)行了記錄，并且使用,進(jìn)行串聯(lián)，形成版本鏈。快照讀查詢語句執(zhí)行前，或者使用start with （立即生成read view）會(huì)生成一個(gè)read view（一致性視圖，如下）
read view包含如下幾個(gè)字段
2.2如何利用一致性視圖判斷數(shù)據(jù)是否可見#如果被訪問版本的trx_id和相同，意味著當(dāng)前事務(wù)在訪問自己修改的記錄，自然可見如果訪問版本的trx_id屬性值小于read view中的 表明此版本是生成read view之前已經(jīng)提交的事務(wù)，那么自然可見如果訪問版本的trx_id,大于等于read view中的說明，當(dāng)前版本數(shù)據(jù)是生成read view后開啟事務(wù)產(chǎn)生的，那么自然不可見如果訪問版本的trx_id 介于和之間，需要判斷trx_id是否位于m_ids列表中，如果在說明創(chuàng)建read view時(shí)生成該版本的事務(wù)還是活躍的，那么該版本，不可被訪問，如果不在說明創(chuàng)建read view 時(shí)生成該版本的事務(wù)已經(jīng)提交，可以被訪問到2.3Read 和 Read的不同#3.寫redo log#
Mysql InnoDB Redo log
redo log 記錄事務(wù)修改了哪個(gè)表空間（space id屬性），哪個(gè)頁（page number 屬性），修改后的值（data屬性）
即使是非常簡(jiǎn)單的一條變更sql，往往涉及到多出的改動(dòng)，比如需改sql數(shù)據(jù)的字符數(shù)發(fā)生了變更，需要先刪除，后插入。并且需要對(duì)上一條行記錄的 屬性進(jìn)行修改，頁中行數(shù)據(jù)的修改，往往同樣需要修改page header，page 等內(nèi)容，并且可能伴隨著B+樹節(jié)點(diǎn)分裂和合并。為了解決存在多種不同修改的問題，innodb存在多種類型的redo log。
3.1 mini-#
innodb 把一次變更分為多個(gè)mini-（MTR）一個(gè)MTR包含一組redo log，這一組redo log以一個(gè)特殊類型的redo log作為類型，恢復(fù)的時(shí)候，這一組redo log具備原子性，只有檢測(cè)到特殊類型的redo log才任何一組redo log是完整的才會(huì)進(jìn)行恢復(fù)（B+樹葉子節(jié)點(diǎn)的分裂，不能說分裂一半）
3.2 log buffer#
生成redo log，會(huì)寫入到log buffer，log buffer是一塊連續(xù)的內(nèi)存空間，由一個(gè)個(gè)大小為512B的log block組成，默認(rèn)16mb大小。生成的redo log會(huì)找最小的一個(gè)redo log block 順序?qū)懭?/p>
3.3 redo log 刷盤的時(shí)機(jī)：#事務(wù)提交log buffer 空間低于50%后臺(tái)線程周期性刷盤mysql服務(wù)正常關(guān)閉做.4 redo log 進(jìn)行崩潰恢復(fù)#
從位置開始讀取redo log，來恢復(fù)臟頁和undo log，然后通過undo log把所有未提交的事務(wù)的臟頁進(jìn)行回滾
七丶本地提交#
提交階段 innodb存儲(chǔ)引擎需要落盤redo log，mysql服務(wù)器層需要落盤binlog
1.binlog#
二進(jìn)制邏輯日志，在邏輯備份和主備復(fù)制中發(fā)揮重要作用，具備三種格式
2.怎么保證binlog 和redo log狀態(tài)一致#
mysql采用了內(nèi)部XA事務(wù)的機(jī)制保證binlog，和redo log的狀態(tài)順序一致，通過兩階段提交的方式實(shí)現(xiàn)，兩階段提交存在一個(gè)協(xié)調(diào)者和多個(gè)參與者，在mysql中binlog是協(xié)調(diào)者，redo log是參與者
2.1mysql的兩階段提交#prepare階段innodb刷redo log到磁盤，redo log刷盤完成后，修改事務(wù)狀態(tài)為如果失敗，那么事務(wù)會(huì)回滾，而prepare成功那么進(jìn)入commit階段commit階段mysql服務(wù)器層寫入binlog，寫入完成后，修改事務(wù)狀態(tài)為,表示事務(wù)已經(jīng)成功提交2.2宕機(jī)的處理#3.redo log 和binlog 物理落盤策略#3.1 空置redo log的落盤#3.2 控制binlog的落盤#八丶主備復(fù)制#
主庫(kù)寫入binlog之后，備庫(kù)的io線程會(huì)讀取主庫(kù)的binlog，并轉(zhuǎn)存為本地的中繼日志relay log，備庫(kù)上的sql線程讀取relay log并在本地執(zhí)行
1.主備復(fù)制的策略#
不同的策略，其性能和一致性要求不同，也影響到主庫(kù)能否返回
九丶返回提交成功#
至此mysql會(huì)給客戶端返回成功
十丶臟頁刷盤#
innodb后臺(tái)有專門的線程負(fù)責(zé)將buffer pool中的臟頁刷新到磁盤
如果后臺(tái)線程刷新的很慢，且有新的頁面需要進(jìn)行緩存，這時(shí)候會(huì)從LRU鏈表尾部看看是否有可以直接釋放的非臟頁，如果不存在那么需要刷盤然后緩存新的頁。
原文鏈接：
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
