數據庫知識要點，面試向

數據知識要點

數據庫原理、sql語句、mysql數據庫、數據庫優化、redis

數據庫原理

知識點：事務、範式、多粒度和意向鎖、XS鎖、封鎖協議、兩段鎖協議、死鎖、隔離級別

事務ACID

事務就是指數據庫的要作的一件事情，能夠是一條sql語句，能夠是一系列操做。把這些操做整體看成一個要麼完成要麼不完成的事情來看，完成就是commit，不完成就是rollback

事務的四個特性：

A 原子性 要麼完成，要麼rollback

C 一致性 事物之行先後保持一致性

I 隔離性 事務之間不影響也不可見

D 持久性 修改是永久的，即便系統奔潰，也不能夠出問題

### 併發一致性問題

髒數據、不可重複讀、修改丟失、幻影讀

髒數據：就是讀出來的數據，因爲被別人修改了，可是丟改又取消了，其實沒有修改，可是讀出來的數據是修改的，因此是髒數據

不可重複讀：讀了兩次數據，可是讀的時候，別的事務修改了數據的值，致使讀的不對

修改丟失：多個事務同時讀取數據，而後修改，可是先寫入的被後修改的覆蓋了

幻影讀：範圍讀取的時候，因爲別的事務的修改，致使兩次讀取結果不同

鎖

寫鎖X：加了以後，只有我能夠讀改數據，其餘程序不能夠讀寫

讀鎖S：加了以後，只有我和其餘加了讀鎖讀事務能夠讀，不能夠寫也不能夠加X鎖，只能夠加S鎖

封鎖協議

一級、二級、三級封鎖協議

一級封鎖協議：寫入以前加X鎖，直到事務結束，釋放X。防止丟失修改，同時只有一個事務能夠修改數據

二級封鎖協議：一的基礎上，在讀取以前加S，讀完釋放S。防止讀取髒數據，由於A修改x的值的時候，沒辦法第二次讀取，若是回滾了，讀取到的數據是髒數據。

三級封鎖協議：一的基礎上，讀以前加S，事務結束釋放S。防止不可重複讀。

多粒度鎖和意向鎖

鎖的粒度能夠是表級也能夠是行級別，mysql中myisam就是表，innoDB就是行級別

意向鎖：爲了更好的支持多粒度鎖

IX鎖：獲取某個行的X鎖以前，須要得到表的IX鎖

IS鎖：獲取某個行的S鎖以前，須要得到表的IS鎖及更強鎖

表的IX鎖和X鎖不兼容，就是說加了IX，不能夠加表的X，只能加行的X

原理：

沒有意向鎖的話，若是想獲取一個表的X鎖，就須要對錶的X鎖和每一行的X鎖進行檢測，很是消耗資源。

可是有了意向鎖就不同了，若是有一個事務得到了行的X鎖，那它必定得到了表的IX鎖，其餘事務若是想來獲取這個表的鎖，就不能夠，只能得到行的X鎖

兩段鎖協議

就是說加鎖和解鎖分爲兩段來執行，能夠對不一樣事務中的全部加鎖解鎖操做串行，判斷是否能夠衝突可串行化調度

衝突可串行化調度，就是說按照一個串行順序調度，不會出現死鎖

死鎖

預防：一次封鎖法：一次得到全部資源，順序封鎖法：按照一個合理的順序封鎖

診斷和解除：超時法，等待圖法（檢測迴路），從一個最小事務，釋放它的全部資源

隔離級別

未提交讀：修改未提交就能夠讀，不能防任何

已提交讀：只能讀取已經提交的結果，能夠防止髒數據

可重複讀：事務屢次讀取結果同樣，防止不可重複讀，不防幻影

可串行化 ：事務串行執行，不會互相干擾，不會出現一致性問題，須要加鎖實現

多版本併發控制MVCC

InnoDB實現提交讀和可重複讀的一種實現。可串行沒法實現。

基本實現：

數據有版本快照，只能夠讀取已經提交的快照，從而防止髒數據和不重複讀，髒數據和不重複讀是因爲讀取了爲提交的修改致使的。

多版本指的是多個版本的快照，儲存在Undo日誌中。

每個事務會有一個版本號。日誌就記錄了操做這些數據的版本號等信息。

ReadView結構，裏保存了未提交的事務列表的版本號，經過比較快找的版本號和列表的版本號，若是快照小，則修改成提交，可使用，若是快照大，則不能使用，若是在列表中間，則須要判斷在列表中就表示沒提交，提交讀不可，不在就能夠提交讀。可重複讀不能夠。

 

MVCC不能夠解決幻影讀，因此使用nextkeylocks解決幻影讀

recordlocks和gaplocks結合，鎖定索引的一個區間

 MCVV詳解參考：https://www.codercto.com/a/88775.html

範式

第1、第2、第三範式

第一範式：屬性不可分

第二範式：非主屬性只依賴鍵碼

第三範式：不存在非主屬性的函數依賴傳遞

BCNF：每一個決定因素都包含碼（個人理解是都在碼內）

第四範式：沒有非平凡的非函數依賴的多值依賴

多值依賴：就是說ABC三屬性，AC雖然決定B，可是B中不少組值（B1B二、B3B4B5）只取決於A。

好比課程、老師、書本，不一樣老師用不一樣的書，一門課好幾個老師，課程能夠決定一坨老師和書，

因此老師和書都是對課程多值依賴的。

非平凡就是C不爲空，例子裏就是有課本。

mysql數據庫

對比

以前是myisam，如今是InnoDB

InnoDB：支持事務，支持行級鎖、支持外鍵、聚簇索引、多版本控制、commit和rollback、熱備份

myisam：不支持事務，表級鎖、不支持外鍵、非聚簇索引

索引實現

B+Tree索引或者哈希索引

哈希索引：O1複雜度，查詢速度快，只支持單個條目查詢

B+tree索引：支持範圍查找

全文索引：倒排索引實現，記錄關鍵字到文檔的映射。用於全文查找關鍵字

空間數據索引：myisam支持，用於地理數據存儲。空間數據索引會從全部維度來索引數據，能夠有效地使用任意維度來進行組合查詢。

BTree比紅黑好：1由於出度大，因此查找快。2磁盤預讀，索引和文件放在一塊兒

索引種類

單列索引、多列索引、前綴索引、覆蓋索引

覆蓋索引：索引包含須要查詢的字段的值

索引使用

優勢：加快查詢速度，隨機IO變順序IO，避免排序和分組創立臨時表

使用：中大型表，特大表代價太大，小表直接掃描

索引總結

https://github.com/Snailclimb/JavaGuide/blob/master/docs/database/%E6%95%B0%E6%8D%AE%E5%BA%93%E7%B4%A2%E5%BC%95.md

https://github.com/Snailclimb/JavaGuide/blob/master/docs/database/MySQL%20Index.md

鎖

InnoDB

• Record lock：單個行記錄上的鎖

• Gap lock：間隙鎖，鎖定一個範圍，不包括記錄自己

• Next-key lock：record+gap 鎖定一個範圍，包含記錄自己

 

數據庫優化

大表優化

限定數據的取值範圍

讀寫分離，主庫寫，從庫讀

垂直分區：按照相關性和列拆分乘多個表，優勢：減小讀取數據量，缺：增長了冗餘和鏈接

水平分區：水平拆分能夠支持海量的數據

分區要謹慎使用，否則跨區會有很大代價

索引優化

限制索引數量

最左側原則

頻繁查詢和使用的列索引

頻繁更新的列不要索引

避免冗餘的索引

 

 

其餘優化和規範

https://github.com/Snailclimb/JavaGuide/blob/master/docs/database/MySQL%E9%AB%98%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%E8%A7%84%E8%8C%83%E5%BB%BA%E8%AE%AE.md

 

 

 

redis數據庫

redis是一個內存中的Nosql數據庫，普遍用於緩存方向。也常常用來作分佈式鎖。此外還支持事務，支持LUA腳本，支持持久化和集羣方案。高性能，高併發。

線程模型

單線程，單線程實際上是指他的文件事務分派器是單線程的。

redis是因爲：

多個socket

IO多路複用程序

文件事務分派器

時間處理器

組成。

流程：多個socket併發產生多個操做，而後IO多路複用程序從socket中監聽，將socket中時間放在一個隊列中，文件事務分派器按照事務將事件一個一個派發給事件處理器。

redis和memcached區別

類型：redis是數據庫，而memcached是緩存系統

數據類型：redis五種，string、set、map、list、Zset

集羣：redis原生支持，memcached不支持，須要程序支持

線程：redis是單線程的非阻塞IO複用，memcached是多線程的多路IO複用

持久化：redis支持持久化，memcached只是一個緩存系統

操做：redis：批量操做、假事務、不一樣類型不一樣curd，memcached支持curd和其餘少許操做

內存淘汰

能夠設置過時時間。

按期刪除：按期掃描必定數量的設置了過時時間的key，過時則刪除。不所有掃描，由於開銷太大。

惰性刪除：按期刪除確定長時間會存在不少沒有被刪掉的過時變量，須要惰性刪除，就是說檢查一下這個key，而後刪除。

由於刪除還會致使大量過時的變量，因此引入淘汰機制

6種

設置了過時中最近最少使用

設置了過時中最快過時

設置了過時中隨機

全部中最近最少使用

全部中隨機

不刪除

4.0後加了兩種：

設置了過時中最少使用

所有中最少使用

持久化

快照持久化：按期產生快照，而後對快照進行備份

AOF持久化（只追加文件持久化）：每執行一條會更改Redis中的數據的命令，Redis就會將該命令寫入硬盤中的AOF文件。每秒同步一次，最多損失一秒的數據。實時性很好，是目前對主流方案。

4.0後支持混合持久化

事務

事務提供了一種將多個命令請求打包，而後一次性、按順序地執行多個命令的機制，而且在事務執行期間，服務器不會中斷事務而改去執行其餘客戶端的命令請求，它會將事務中的全部命令都執行完畢，而後纔去處理其餘客戶端的命令請求。redis支持事務的方式就是一塊兒作，順序執行。

緩存穿透和緩存雪崩

緩存穿透：大量的請求不在緩存中，須要請求數據庫

解決方法：處理無效key過時、布隆過濾器（相似於白名單，判斷key是否合法）

緩存雪崩；短期緩存大量失效，致使請求直接交給數據庫

解決方法：事前：保證redia集羣的高可用性，選擇合適的淘汰機制，事中：ehcache緩存 + hystrix限流&降級，避免MySQL崩掉，過後：持久化機制快速回復。

 

 

sql語句

 略