點(diǎn)擊藍(lán)字之后，我們就是好朋友了啦

15

???數(shù)據(jù)庫篇(一)?

01事務(wù)概念及應(yīng)用場(chǎng)景

事務(wù)是一組不可分割的mysql語句組，這些語句組要么全部執(zhí)行成功，要么全部執(zhí)行失敗。事務(wù)的提出主要是為了解決并發(fā)情況下保持?jǐn)?shù)據(jù)一致性的問題。

02事務(wù)四大特性

原子性：事務(wù)是指不可分割的工作單位??

一致性：指在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫的完整性約束沒有被破壞?

隔離性：多個(gè)事務(wù)并發(fā)訪問時(shí)，事務(wù)之間是隔離的，一個(gè)事務(wù)不應(yīng)該影響其它事務(wù)運(yùn)行效果

持久性：事務(wù)一旦提交，它對(duì)數(shù)據(jù)庫中的改變就是永久性的

03數(shù)據(jù)庫三大范式

目前關(guān)系數(shù)據(jù)庫有六種范式：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF，又稱完美范式)。? 而通常我們用的最多的就是第一范式(1NF)、第二范式(2NF)、第三范式(3NF)。

第一范式(1NF)：要求數(shù)據(jù)庫表的每一列都是不可分割的原子數(shù)據(jù)項(xiàng)。

第二范式(2NF)：在1NF的基礎(chǔ)上，非碼屬性必須完全依賴于候選碼，需要確保數(shù)據(jù)庫表中的每一列都和主鍵相關(guān)，而不能只與主鍵的某一部分相關(guān)。

第三范式(3NF)：在2NF基礎(chǔ)上，任何非主屬性不依賴于其它非主屬性，需要確保數(shù)據(jù)表中的每一列數(shù)據(jù)都和主鍵直接相關(guān)，而不能間接相關(guān)。

04數(shù)據(jù)庫查詢慢的原因

1、沒有索引或者沒有用到索引?

2、I/O吞吐量小，形成了瓶頸效應(yīng)?

3、沒有創(chuàng)建計(jì)算列導(dǎo)致查詢不優(yōu)化

4、內(nèi)存不足??

5、網(wǎng)絡(luò)速度慢??

6、查詢出的數(shù)據(jù)量過大(可以采用多次查詢，其他的方法降低數(shù)據(jù)量)? 7、鎖或者死鎖(這也是查詢慢最常見的問題，是程序設(shè)計(jì)的缺陷)??

8、sp_lock,sp_who,活動(dòng)的用戶查看,原因是讀寫競(jìng)爭(zhēng)資源

05悲觀鎖和樂觀鎖

悲觀鎖(Pessimistic Lock)，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人會(huì)修改，所以每次在拿數(shù)據(jù)的時(shí)候都會(huì)上鎖，這樣別人想拿這個(gè)數(shù)據(jù)就會(huì)block直到它拿到鎖。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫里邊就用到了很多這種鎖機(jī)制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。(實(shí)現(xiàn):在sql語句后面加上for update)?

樂觀鎖(Optimistic Lock)，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改，所以不會(huì)上鎖，但是在更新的時(shí)候會(huì)判斷一下在此期間別人有沒有去更新這個(gè)數(shù)據(jù)，可以使用版本號(hào)等機(jī)制。樂觀鎖適用于多讀的應(yīng)用類型，這樣可以提高吞吐量，像數(shù)據(jù)庫如果提供類似于write_condition機(jī)制的其實(shí)都是提供的樂觀鎖。(實(shí)現(xiàn)：在表上加version)

△ ?

Hard Work Pays Off

06索引優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

1、通過創(chuàng)建唯一性索引，可以保證數(shù)據(jù)庫表中每一行數(shù)據(jù)的唯一性。??

2、可以大大加快數(shù)據(jù)的檢索速度，這也是創(chuàng)建索引的最主要的原因。??

3、可以加速表和表之間的連接，特別是在實(shí)現(xiàn)數(shù)據(jù)的參考完整性方面特別有意義。?

缺點(diǎn)：

1、創(chuàng)建索引和維護(hù)索引要耗費(fèi)時(shí)間

2、索引需要占物理空間

3、當(dāng)對(duì)表中的數(shù)據(jù)進(jìn)行增加、刪除和修改的時(shí)候，索引也要?jiǎng)討B(tài)的維護(hù)，這樣就降低了數(shù)據(jù)的維護(hù)速度。

07索引種類

1、普通索引：最基礎(chǔ)的索引，沒有任何限制

2、唯一索引：唯一索引是不允許其中任何兩行具有相同索引值的索引?

3、聚簇索引：表中行的物理順序與鍵值的邏輯(索引)順序相同

4、非聚簇索引：數(shù)據(jù)庫表中記錄的物理順序與索引順序可以不相同

08聚簇索引與非聚簇索引

聚簇索引：將數(shù)據(jù)存儲(chǔ)與索引放到了一塊，找到索引也就找到了數(shù)據(jù)。

非聚簇索引：將數(shù)據(jù)存儲(chǔ)于索引分開結(jié)構(gòu)，索引結(jié)構(gòu)的葉子節(jié)點(diǎn)指向了數(shù)據(jù)的對(duì)應(yīng)行，把索引先緩存到內(nèi)存中，當(dāng)需要訪問數(shù)據(jù)時(shí)(通過索引訪問數(shù)據(jù))，在內(nèi)存中直接搜索索引，然后通過索引找到磁盤相應(yīng)數(shù)據(jù)，這也就是為什么索引不在key buffer命中時(shí)，速度慢的原因。

09B+樹和hash索引

Hash索引底層是哈希表，哈希表是一種以key-value存儲(chǔ)數(shù)據(jù)的結(jié)構(gòu)，所以多個(gè)數(shù)據(jù)在存儲(chǔ)關(guān)系上是完全沒有任何順序關(guān)系的，所以，哈希索引只適用于等值查詢的場(chǎng)景。如果有大量重復(fù)鍵值的情況下，哈希索引的效率會(huì)很低，因?yàn)榇嬖诠Ｅ鲎矄栴}。

B+樹是一種多路平衡查詢樹，所以他的節(jié)點(diǎn)是天然有序的(左子節(jié)點(diǎn)小于父節(jié)點(diǎn)、父節(jié)點(diǎn)小于右子節(jié)點(diǎn))，所以對(duì)于范圍查詢的時(shí)候不需要做全表掃描 。

10MySQL數(shù)據(jù)表的切分原則

水平切分：將某個(gè)訪問極其平凡的表再按照某個(gè)字段的某種規(guī)則來分散到多個(gè)表之中，每個(gè)表中包含一部分?jǐn)?shù)據(jù)。就是按照數(shù)據(jù)行的切分，就是將表中的某些行切分到一個(gè)數(shù)據(jù)庫，而另外的某些行又切分到其他的數(shù)據(jù)庫中。

垂直切分：將不同的表分散到不同的數(shù)據(jù)庫主機(jī)中。

當(dāng)命運(yùn)遞給我一個(gè)酸的檸檬時(shí)，

讓我們?cè)O(shè)法把它制造成甜的檸檬汁。

——雨果

End

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

總結(jié)

以上是生活随笔為你收集整理的使用t-sql语句修改表中的某些数据及数据类型。_测试开发工程师数据库篇（一）...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。