疫情最新資訊seo費(fèi)用
目錄
索引的作用 與 概念
MySQL有哪幾種索引類(lèi)型
如何提高查找效率
聚簇索引與非聚簇索引
覆蓋索引
索引的優(yōu)點(diǎn)和缺點(diǎn)
索引的一些基本操作
索引優(yōu)化
B樹(shù)、B+樹(shù)、Hash、紅黑樹(shù)的區(qū)別
B樹(shù)與B+樹(shù)的區(qū)別
MySQL為什么使用B+樹(shù)作為索引
聯(lián)合索引中的順序
MySQL的最左前綴原則
查看表的索引信息
怎么判斷要不要加索引
所有的字段都適合建索引嗎
如何評(píng)估一個(gè)索引創(chuàng)建的是否合理？?索引在哪些情況下會(huì)失效？?如何避免索引失效？
如何判斷數(shù)據(jù)庫(kù)的索引有沒(méi)有生效？
索引是用來(lái)干什么的
索引的使用的場(chǎng)景
事務(wù)的概念
事務(wù)原子性如何保證
MySQL 事務(wù)的 ACID 特性
?事務(wù)的使用
MySQL中事務(wù)的隔離級(jí)別
臟讀、不可重復(fù)讀、幻讀
索引的作用 與 概念
索引就相當(dāng)于書(shū)的目錄，主要作用就是提高查找效率。
MySQL有哪幾種索引類(lèi)型
1、從存儲(chǔ)結(jié)構(gòu)上來(lái)劃分：BTree索引（B-Tree或B+Tree索引），Hash索引，full-index全文索引。這里所描述的是索引存儲(chǔ)時(shí)保存的形式。
2、從應(yīng)用層次來(lái)分：普通索引，唯一索引，復(fù)合索引。
- 普通索引：即一個(gè)索引只包含單個(gè)列，一個(gè)表可以有多個(gè)單列索引
- 唯一索引：索引列的值必須唯一，但允許有空值
- 復(fù)合索引：多列值組成一個(gè)索引，專(zhuān)門(mén)用于組合搜索，其效率大于索引合并
- 聚簇索引(聚集索引)：并不是一種單獨(dú)的索引類(lèi)型，而是一種數(shù)據(jù)存儲(chǔ)方式。具體細(xì)節(jié)取決于不同 的實(shí)現(xiàn)，InnoDB的聚簇索引其實(shí)就是在同一個(gè)結(jié)構(gòu)中保存了B-Tree索引(技術(shù)上來(lái)說(shuō)是B+Tree)和 數(shù)據(jù)行。
- 非聚簇索引： 不是聚簇索引，就是非聚簇索引。
如何提高查找效率
當(dāng)從數(shù)據(jù)庫(kù)中進(jìn)行查找操作時(shí)，比如根據(jù)條件 id=3 查找：可以遍歷表進(jìn)行查詢(xún)，但是這種方式效率比較低。 如何提高效率呢？
這就需要想辦法盡量避免遍歷，可以通過(guò)一些特殊的數(shù)據(jù)結(jié)構(gòu)來(lái)表示一些記錄的特征，通過(guò)這些特征來(lái)減少比較次數(shù)，加快比較的速率。
當(dāng)查找效率提高時(shí)，也將會(huì)付出一些代價(jià)：
就相當(dāng)于與給書(shū)加上目錄會(huì)費(fèi)一些紙，即加上索引就會(huì)消耗一定的存儲(chǔ)空間，數(shù)據(jù)量越大，消耗的空間就越大?
書(shū)的目錄確定了，后續(xù)每次對(duì)書(shū)的內(nèi)容進(jìn)行調(diào)整時(shí)，都可能會(huì)影響到目錄的準(zhǔn)確性，就需要重新調(diào)整目錄，同理，數(shù)據(jù)庫(kù)的索引也是一樣的，當(dāng)進(jìn)行增刪查改時(shí)，往往也需要同步的調(diào)整索引的結(jié)構(gòu)?
聚簇索引與非聚簇索引
在 InnoDB 里，索引B+ Tree的葉子節(jié)點(diǎn)存儲(chǔ)了整行數(shù)據(jù)的是主鍵索引，也被稱(chēng)之為聚簇索引，即將數(shù)據(jù) 存儲(chǔ)與索引放到了一塊，找到索引也就找到了數(shù)據(jù)。 而索引B+ Tree的葉子節(jié)點(diǎn)存儲(chǔ)了主鍵的值的是非主鍵索引，也被稱(chēng)之為非聚簇索引、二級(jí)索引。
- 對(duì)于InnoDB來(lái)說(shuō)，想要查找數(shù)據(jù)我們還需要根據(jù)主鍵再去聚集索引中進(jìn)行查找，這個(gè)再根據(jù)聚集 索引查找數(shù)據(jù)的過(guò)程，我們稱(chēng)為回表。第一次索引一般是順序IO，回表的操作屬于隨機(jī)IO。需要回表的次數(shù)越多，即隨機(jī)IO次數(shù)越多，我們就越傾向于使用全表掃描 。
- 通常情況下，主鍵索引（聚簇索引）查詢(xún)只會(huì)查一次，而非主鍵索引（非聚簇索引）需要回表查詢(xún)多次。當(dāng)然，如果是覆蓋索引的話，查一次即可 。
- 注意：MyISAM無(wú)論主鍵索引還是二級(jí)索引都是非聚簇索引，而InnoDB的主鍵索引是聚簇索引，二級(jí)索引是非聚簇索引。我們自己建的索引基本都是非聚簇索引。
覆蓋索引
覆蓋索引是指一個(gè)索引包含了查詢(xún)所需的所有列數(shù)據(jù)，因此在查詢(xún)時(shí)可以直接使用索引返回結(jié)果，而不需要回到數(shù)據(jù)表中查找數(shù)據(jù)行，從而大幅提高查詢(xún)性能。
舉個(gè)例子，假設(shè)有一張訂單表，包含了訂單編號(hào)、訂單金額、訂單日期等列，如果我們需要查詢(xún)某個(gè)日期范圍內(nèi)的所有訂單金額，我們可以在訂單日期列上創(chuàng)建一個(gè)索引，如果該索引還包含了訂單金額列，那么查詢(xún)時(shí)就可以直接使用這個(gè)索引返回查詢(xún)結(jié)果，而不需要再回到訂單表中查找對(duì)應(yīng)的訂單金額，這就是覆蓋索引。
可以看出，覆蓋索引可以大幅提高查詢(xún)性能，尤其是在大數(shù)據(jù)量的情況下。但是，在創(chuàng)建覆蓋索引時(shí)需要注意，索引需要包含查詢(xún)所需的所有列數(shù)據(jù)，因此索引的大小可能會(huì)比較大，從而增加讀取磁盤(pán)的成本，也需要權(quán)衡創(chuàng)建索引的成本和查詢(xún)性能的提高。
索引的優(yōu)點(diǎn)和缺點(diǎn)
索引帶來(lái)的好處：提高了查找得速度
索引帶來(lái)得壞處：占用了更多的空間，拖慢了增刪查改的速度
從表面來(lái)上看，似乎索引的壞處 比 索引帶來(lái)的好處要多。但！這不必意味著 弊大于利！！
因?yàn)樵趯?shí)際需求的場(chǎng)景中，查詢(xún)操作往往是最高頻率的操作。
相對(duì)于“增刪改” 的使用頻率則低的可憐。
因此，查詢(xún)作為一個(gè)高頻操作，索引對(duì)其來(lái)說(shuō)是不可缺少的，
?
另外，有了索引之后對(duì)于查詢(xún)的效率的提升使非常巨大的！！！
當(dāng)MySQL里面的數(shù)據(jù)量級(jí) 達(dá)到千萬(wàn)級(jí)別的時(shí)候（一個(gè)表里就有幾千萬(wàn)，甚至破億的數(shù)據(jù)）再去遍歷表，就會(huì)非常非常的低效！！！
?
在另一方面：MySQL在進(jìn)行數(shù)據(jù)比較的時(shí)候，不是像我們編程那樣，一個(gè)for循環(huán)（這樣的想法是錯(cuò)誤的）。
編程上的查詢(xún)是在內(nèi)存中的比較；MySQL 中的比較是在硬盤(pán)上比較。
也就是說(shuō)：在MySQL中的每一次比較都會(huì)涉及到硬盤(pán)的 IO 操作。
索引的一些基本操作
1.查看索引：show index from 表名
有些約束是自動(dòng)帶索引的，比如：primary ，unique
2.給指定列創(chuàng)建索引create index 索引名字 on 表名(列名);
例如：create index class_index on student(class);-- 給class這一列加上索引
注意：創(chuàng)建索引是一個(gè)非常低效的事情，尤其是當(dāng)前表里面已經(jīng)有很多數(shù)據(jù)的時(shí)候
所以，當(dāng)你針對(duì)線上的數(shù)據(jù)庫(kù)的時(shí)候，如果這個(gè)表沒(méi)有索引的時(shí)候，不要貿(mào)然去加上索引…
3.刪除索引drop index 索引名字 on student 表名
例如：drop index class_index on student;
注意：刪除索引和創(chuàng)建索引一樣，都是效率比較低的操作,也容易把數(shù)據(jù)庫(kù)搞掛
因此，在創(chuàng)建表的時(shí)候，就應(yīng)該把索引規(guī)劃好。
索引優(yōu)化
確定需要?jiǎng)?chuàng)建的索引的列：
可以通過(guò)查詢(xún)SQL語(yǔ)句的執(zhí)行計(jì)劃，找出哪些SQL語(yǔ)句的查詢(xún)效率比較低，然后確定需要?jiǎng)?chuàng)建索引的列。
確定索引類(lèi)型：
不同的索引類(lèi)型在不同的場(chǎng)景下具有不同的優(yōu)勢(shì)，需要根據(jù)具體的業(yè)務(wù)需求和場(chǎng)景來(lái)選擇合適的索引類(lèi)型。
避免在索引列上使用函數(shù)或者表達(dá)式：
在索引列上使用函數(shù)或者表達(dá)式會(huì)導(dǎo)致索引失效，從而降低查詢(xún)性能。
避免使用 OR 連接條件：
在查詢(xún)語(yǔ)句中使用 OR 連接條件會(huì)導(dǎo)致索引失效，從而降低查詢(xún)性能。
避免在表達(dá)式左側(cè)使用運(yùn)算符：
在查詢(xún)語(yǔ)句中，將運(yùn)算符放在表達(dá)式的左側(cè)會(huì)導(dǎo)致索引失效，從而降低查詢(xún)性能。
B樹(shù)、B+樹(shù)、Hash、紅黑樹(shù)的區(qū)別
BTree：
B樹(shù)是一棵多路平衡查找樹(shù)
- B樹(shù)的每個(gè)節(jié)點(diǎn)都存儲(chǔ)索引和數(shù)據(jù)（key和data）
- 每個(gè)節(jié)點(diǎn)中的關(guān)鍵字都按照從小到大的順序排列
- 所有葉子節(jié)點(diǎn)都位于同一層，或者說(shuō)根節(jié)點(diǎn)到每個(gè)葉子節(jié)點(diǎn)的長(zhǎng)度都相同
?B+Tree：
B+樹(shù)也是一棵多路平衡查找樹(shù)
- B+樹(shù)中非葉子節(jié)點(diǎn)不存儲(chǔ)數(shù)據(jù)，只存儲(chǔ)索引。對(duì)于非葉子節(jié)點(diǎn)中key都按照從小到大的順序排列， 非葉子節(jié)點(diǎn)中的每一個(gè)key，都會(huì)出現(xiàn)在子節(jié)點(diǎn)中，是子節(jié)點(diǎn)中最大或最小元素。所有的非葉子節(jié)點(diǎn)起到了索引作用。
- 只有葉子節(jié)點(diǎn)存儲(chǔ)data，葉子節(jié)點(diǎn)包含了這棵樹(shù)的所有數(shù)據(jù)。
- 葉子節(jié)點(diǎn)依據(jù)關(guān)鍵字的大小從小到大順序鏈接，形成一個(gè)有序鏈表。便于區(qū)間查找和遍歷。
- 所有葉子節(jié)點(diǎn)都位于同一層，或者說(shuō)根節(jié)點(diǎn)到每個(gè)葉子節(jié)點(diǎn)的長(zhǎng)度都相同。
Hash索引：
雖然可以快速定位，但是沒(méi)有順序，IO復(fù)雜度高；
適合等值查詢(xún)，如=、in()，不支持范圍查詢(xún) ；
因?yàn)椴皇前凑账饕淀樞虼鎯?chǔ)的，就不能像B+Tree索引一樣利用索引完成排序 ；
如果有大量重復(fù)鍵值得情況下，哈希索引的效率會(huì)很低，因?yàn)榇嬖诠Ｅ鲎矄?wèn)題 。
紅黑樹(shù)：
樹(shù)的高度隨著數(shù)據(jù)量增加而增加，IO代價(jià)高。
B樹(shù)與B+樹(shù)的區(qū)別
B+樹(shù)的優(yōu)勢(shì)：
- IO次數(shù)更少
- 查詢(xún)性能很穩(wěn)定
- 范圍查詢(xún)更簡(jiǎn)便
1.B樹(shù)的每個(gè)節(jié)點(diǎn)都存儲(chǔ)key和data，B+樹(shù)只有葉子節(jié)點(diǎn)存儲(chǔ)data，葉子節(jié)點(diǎn)包含了這棵樹(shù)的所有數(shù)據(jù)，這樣一個(gè)葉子節(jié)點(diǎn)可以存儲(chǔ)更多的key,可以使樹(shù)更矮，所以 IO操作的次數(shù)更少。
2.B+樹(shù)中所有的葉子節(jié)點(diǎn)構(gòu)成一個(gè)有序鏈表，可以按照關(guān)鍵子碼排序的次序遍歷全部記錄，由于數(shù)據(jù)順序排列并相連，所以編譯區(qū)間查找和搜索。而B(niǎo)樹(shù)則需要進(jìn)行每一層的遍歷，相鄰的元素可能在內(nèi)存中并不相鄰。
3.在B樹(shù)中，當(dāng)要查找的值恰好在一個(gè)非葉子節(jié)點(diǎn)時(shí)，查找到該節(jié)點(diǎn)就會(huì)成功并結(jié)束查詢(xún)，而B(niǎo)+樹(shù)由于非葉子節(jié)點(diǎn)只是索引部分，這些節(jié)點(diǎn)中只含有其子樹(shù)中最大或最小關(guān)鍵字，當(dāng)非終端節(jié)點(diǎn)的關(guān)鍵字等于給定值時(shí)，查找并不終止，而是繼續(xù)向下查找直到葉子節(jié)點(diǎn)。因此，在B+樹(shù)中，無(wú)論是否查找成功，都是走了一條從根節(jié)點(diǎn)到葉子節(jié)點(diǎn)的路徑。
MySQL為什么使用B+樹(shù)作為索引
（1）B+樹(shù)的磁盤(pán)讀寫(xiě)代價(jià)更低：B+樹(shù)的內(nèi)部節(jié)點(diǎn)并沒(méi)有指向關(guān)鍵字具體信息的指針，因此其內(nèi)部節(jié)點(diǎn)相對(duì)B樹(shù)更小，如果把所有同一內(nèi)部節(jié)點(diǎn)的關(guān)鍵字存放在同一盤(pán)塊中，那么盤(pán)塊所能容納的關(guān)鍵字?jǐn)?shù)量也越多，一次性讀入內(nèi)存的需要查找的關(guān)鍵字也就越多，相對(duì)IO讀寫(xiě)次數(shù)就降低了。
（2）B+樹(shù)的查詢(xún)效率更加穩(wěn)定：由于非終結(jié)點(diǎn)并不是最終指向文件內(nèi)容的結(jié)點(diǎn)，而只是葉子結(jié)點(diǎn)中關(guān)鍵字的索引。所以任何關(guān)鍵字的查找必須走一條從根結(jié)點(diǎn)到葉子結(jié)點(diǎn)的路。所有關(guān)鍵字查詢(xún)的路徑長(zhǎng)度相同，導(dǎo)致每一個(gè)數(shù)據(jù)的查詢(xún)效率相當(dāng)。
（3）B+樹(shù)更便于遍歷：由于B+樹(shù)的數(shù)據(jù)都存儲(chǔ)在葉子結(jié)點(diǎn)中，分支結(jié)點(diǎn)均為索引，方便掃庫(kù)，只需要掃一遍葉子結(jié)點(diǎn)即可，但是B樹(shù)因?yàn)槠浞种ЫY(jié)點(diǎn)同樣存儲(chǔ)著數(shù)據(jù)，我們要找到具體的數(shù)據(jù)，需要進(jìn)行一次中序遍歷按序來(lái)掃，所以B+樹(shù)更加適合在區(qū)間查詢(xún)的情況，所以通常B+樹(shù)用于數(shù)據(jù)庫(kù)索引。
B+樹(shù)更適合基于范圍的查詢(xún)：B樹(shù)在提高了IO性能的同時(shí)并沒(méi)有解決元素遍歷的我效率低下的問(wèn)題，正是為了解決這個(gè)問(wèn)題，B+樹(shù)應(yīng)用而生。B+樹(shù)只需要去遍歷葉子節(jié)點(diǎn)就可以實(shí)現(xiàn)整棵樹(shù)的遍歷。而且在數(shù)據(jù)庫(kù)中基于范圍的查詢(xún)是非常頻繁的，而B(niǎo)樹(shù)不支持這樣的操作或者說(shuō)效率太低。
聯(lián)合索引中的順序
MySQL可以使用多個(gè)字段同時(shí)建立一個(gè)索引，叫做聯(lián)合索引。在聯(lián)合索引中，如果想要命中索引，需要 按照建立索引時(shí)的字段順序挨個(gè)使用，否則無(wú)法命中索引。
具體原因?yàn)? MySQL使用索引時(shí)需要索引有序，假設(shè)現(xiàn)在建立了"name，age，school"的聯(lián)合索引，那么索引的排序?yàn)? 先按照name排序，如果name相同，則按照age排序，如果age的值也相等，則按照school進(jìn)行排序。
當(dāng)進(jìn)行查詢(xún)時(shí)，此時(shí)索引僅僅按照name嚴(yán)格有序，因此必須首先使用name字段進(jìn)行等值查詢(xún)，之后對(duì)于匹配到的列而言，其按照age字段嚴(yán)格有序，此時(shí)可以使用age字段用做索引查找，以此類(lèi)推。因此在 建立聯(lián)合索引的時(shí)候應(yīng)該注意索引列的順序，一般情況下，將查詢(xún)需求頻繁或者字段選擇性高的列放在前面。此外可以根據(jù)特例的查詢(xún)或者表結(jié)構(gòu)進(jìn)行單獨(dú)的調(diào)整。
MySQL的最左前綴原則
最左前綴原則就是最左優(yōu)先，在創(chuàng)建多列索引時(shí)，要根據(jù)業(yè)務(wù)需求，where子句中使用最頻繁的一列放在最左邊。
- mysql會(huì)一直向右匹配直到遇到范圍查詢(xún)(>、 3 and d = 4 如果建立(a,b,c,d)順序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引則都可以用 到，a,b,d的順序可以任意調(diào)整。
- =和in可以亂序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意順序，mysql的查詢(xún)優(yōu)化器會(huì)幫 你優(yōu)化成索引可以識(shí)別的形式。
在設(shè)計(jì)索引時(shí)要考慮使用最左前綴原則，將最常用的列放在最左邊。這樣可以使索引更加高效，查詢(xún)速度更快。
查看表的索引信息
SHOW INDEX FROM 表名;怎么判斷要不要加索引
- 當(dāng)唯一性是某種數(shù)據(jù)特征的時(shí)候加唯一索引。需要判斷定義列的完整性，以此提高查詢(xún)速度。
- 在頻繁的進(jìn)行分組或者排序時(shí)（即建立group by / order by ）的列上建立索引，如果待排序的列有多個(gè)，可以進(jìn)行組合索引。
所有的字段都適合建索引嗎
- 數(shù)據(jù)較少的表
- 頻繁更新的字段
- 數(shù)據(jù)比較重復(fù)的字段，比如性別、真假值
- where條件中用不到的字段不需要建立索引
- 參與列計(jì)算的列
如何評(píng)估一個(gè)索引創(chuàng)建的是否合理？?索引在哪些情況下會(huì)失效？?如何避免索引失效？
（1）對(duì)列進(jìn)行計(jì)算或者是使用函數(shù)，則該列的索引會(huì)失效
（2）不匹配數(shù)據(jù)類(lèi)型，會(huì)造成索引失效
（3）where語(yǔ)句中使用了IS NULL或者IS NOT NULL，會(huì)造成索引失效
（4）使用了反向操作，該索引將不起作用
（5）使用了link操作，索引就將不起作用
（6）在WHERE中使用OR時(shí)，有一個(gè)列沒(méi)有索引，那么其它列的索引將不起作用
如何判斷數(shù)據(jù)庫(kù)的索引有沒(méi)有生效？
通過(guò)explain
索引是用來(lái)干什么的
給信息分配一個(gè)id，方便能夠快速找尋到該數(shù)據(jù)
索引的使用的場(chǎng)景
通常情況下，應(yīng)該為需要經(jīng)常進(jìn)行查詢(xún)的列創(chuàng)建索引，特別是那些數(shù)據(jù)量較大的列。使用索引可以顯著提高查詢(xún)效率。但是，在創(chuàng)建索引的時(shí)候，需要注意索引會(huì)增加數(shù)據(jù)表的存儲(chǔ)空間和數(shù)據(jù)修改的成本，因此不能為所有列都創(chuàng)建索引。
以下是創(chuàng)建索引的一些建議：
- 主鍵應(yīng)該是唯一的，且自動(dòng)遞增的，因此默認(rèn)會(huì)創(chuàng)建主鍵索引。
- 對(duì)經(jīng)常用于搜索條件的列進(jìn)行索引，如where和join語(yǔ)句中使用的列。
- 列值不重復(fù)或者重復(fù)很少的列上創(chuàng)建索引，如性別、狀態(tài)等列。
- 對(duì)經(jīng)常需要排序的列進(jìn)行索引。
需要注意的是，索引并不是萬(wàn)能的，也并不是越多越好。在數(shù)據(jù)量比較小的情況下，無(wú)索引查詢(xún)的效率可能比使用索引還要高；在數(shù)據(jù)修改和寫(xiě)入比較頻繁的表中，創(chuàng)建過(guò)多的索引會(huì)影響數(shù)據(jù)的修改和寫(xiě)入性能，因此需要權(quán)衡索引的使用和維護(hù)成本，選擇合適的索引策略。
事務(wù)的概念
MySQL 事務(wù)是指一組操作，是一個(gè)不可分割的工作單位，可以確保一組數(shù)據(jù)庫(kù)操作要么全部執(zhí)行，要么全部不執(zhí)行。換句話說(shuō)，事務(wù)是 MySQL 中保證數(shù)據(jù)一致性和完整性的機(jī)制。
在 MySQL 中，事務(wù)可以用來(lái)保證數(shù)據(jù)庫(kù)中數(shù)據(jù)的一致性和完整性，例如在向數(shù)據(jù)庫(kù)中插入或更新一組數(shù)據(jù)時(shí)，要么所有數(shù)據(jù)插入或更新成功，要么所有操作全部回滾，保持?jǐn)?shù)據(jù)的原樣。
事務(wù)原子性如何保證
在執(zhí)行到第二個(gè)SQL之前，是無(wú)法預(yù)料這次執(zhí)行會(huì)失敗（假設(shè)執(zhí)行到第二個(gè)會(huì)失敗）
因此，當(dāng)出現(xiàn)執(zhí)行失敗后，有數(shù)據(jù)庫(kù)執(zhí)行一些“還原”操作，來(lái)消除前面SQL帶來(lái)的影響。這個(gè)還原性的操作，叫做“回滾”。
因而外面看起來(lái)：當(dāng)執(zhí)行失敗時(shí)，一個(gè)都沒(méi)有執(zhí)行。
MySQL 事務(wù)的 ACID 特性
ACID 是事務(wù)處理中的關(guān)鍵概念，它指的是：
- 原子性：指事務(wù)中的操作要么全部執(zhí)行成功、要么全部失敗回滾，不會(huì)出現(xiàn)部分執(zhí)行的情況。
- 一致性：指在事務(wù)開(kāi)始和結(jié)束后，數(shù)據(jù)庫(kù)的完整性約束沒(méi)有被破壞，也就是說(shuō)事務(wù)執(zhí)行前后都需要滿足一些預(yù)定義的約束條件。
- 隔離性：指一個(gè)事務(wù)中的執(zhí)行不受其他并發(fā)事務(wù)的影響，它們之間是相互隔離的。
- 持久性：指在事務(wù)提交之后，對(duì)數(shù)據(jù)的更新就被永久寫(xiě)入數(shù)據(jù)庫(kù)，即使數(shù)據(jù)庫(kù)出現(xiàn)故障也能夠恢復(fù)。
?事務(wù)的使用
- 開(kāi)啟事務(wù)：start transaction;
- 執(zhí)行多條SQL
- 回滾或提交：rollback ，commit
說(shuō)明：rollback即是全部失敗，commit即是全部成功
MySQL中事務(wù)的隔離級(jí)別
隔離級(jí)別是指在并發(fā)情況下，不同事務(wù)之間對(duì)數(shù)據(jù)庫(kù)操作數(shù)據(jù)的可見(jiàn)性和影響范圍的規(guī)定。 MySQL 支持以下四種隔離級(jí)別：
- 讀未提交：一個(gè)事務(wù)所做的修改，即使沒(méi)有提交，對(duì)其他事務(wù)也是可見(jiàn)的。在這種隔離級(jí)別下可能會(huì)出現(xiàn)臟讀和不可重復(fù)讀問(wèn)題。
- 讀已提交：一個(gè)事務(wù)所做的修改，在提交后才會(huì)對(duì)其他事務(wù)可見(jiàn)，同樣可能會(huì)出現(xiàn)不可重復(fù)讀問(wèn)題。
- 可重復(fù)讀：保證了在同一個(gè)事務(wù)中對(duì)同一數(shù)據(jù)的讀取是一致的，不受其他事務(wù)的影響。但是，可能會(huì)出現(xiàn)幻讀問(wèn)題。
- 序列化：最嚴(yán)格的隔離級(jí)別，它通過(guò)對(duì)所有事務(wù)進(jìn)行串行化執(zhí)行來(lái)保證事務(wù)的隔離性。這種隔離級(jí)別能夠避免所有并發(fā)問(wèn)題，但是會(huì)對(duì)數(shù)據(jù)庫(kù)性能產(chǎn)生較大影響。
在選擇隔離級(jí)別時(shí)，需要根據(jù)應(yīng)用的實(shí)際情況和數(shù)據(jù)安全性要求來(lái)選擇，即需要權(quán)衡數(shù)據(jù)安全性和數(shù)據(jù)庫(kù)性能。通常情況下，可重復(fù)讀已經(jīng)能夠滿足大部分應(yīng)用需求。
臟讀、不可重復(fù)讀、幻讀
處理臟讀：在寫(xiě)的過(guò)程中，別人就不能讀了（加鎖的狀態(tài)）等修改完了之后，別人才能讀（解除加鎖）?
處理不可重復(fù)讀：給讀加鎖，讀的時(shí)候不能寫(xiě)，就解決了不可重復(fù)讀的問(wèn)題。?
?處理幻讀：串行化完成事務(wù)，即：寫(xiě)——>讀——>寫(xiě)——>讀