7、E-R圖

E-R圖也稱實體-聯系圖(Entity Relationship Diagram)，提供了表示實體類型、屬性和聯系的方法，用來描述現實世界的概念模型。

E-R方法是“實體-聯系方法”（Entity-Relationship Approach）的簡稱。它是描述現實世界概念結構模型的有效方法，是表示概念模型的一種方式，用矩形表示實體型，矩形框內寫明實體名；用橢圓表示實體的屬性，并用無向邊將其與相應的實體型連接起來；用菱形表示實體型之間的聯系，在菱形框內寫明聯系名，并用無向邊分別與有關實體型連接起來，同時在無向邊旁標上聯系的類型（1:1,1:n或m:n）。

在ER圖中有如下四個成分：

矩形框： 表示實體，在框中記入實體名。

菱形框： 表示聯系，在框中記入聯系名。

橢圓形框： 表示實體或聯系的屬性，將屬性名記入框中。對于主屬性名，則在其名稱下劃一下劃線。

連線： 實體與屬性之間；實體與聯系之間；聯系與屬性之間用直線相連，并在直線上標注聯系的類型。（對于一對一聯系，要在兩個實體連線方向各寫1；對于一對多聯系，要在一的一方寫1，多的一方寫N；對于多對多關系，則要在兩個實體連線方向各寫N,M。)

實體型(Entity)： 具有相同屬性的實體具有相同的特征和性質，用實體名及其屬性名集合來抽象和刻畫同類實體;在E-R圖中用矩形表示，矩形框內寫明實體名；比如學生張三豐、學生李尋歡都是實體。如果是弱實體的話，在矩形外面再套實線矩形。

屬性(Attribute)： 實體所具有的某一特性，一個實體可由若干個屬性來刻畫。在E-R圖中用橢圓形表示，并用無向邊將其與相應的實體連接起來；比如學生的姓名、學號、性別、都是屬性。如果是多值屬性的話，在橢圓形外面再套實線橢圓，如果是派生屬性則用虛線橢圓表示。

聯系(Relationship)： 聯系也稱關系，信息世界中反映實體內部或實體之間的聯系。實體內部的聯系通常是指組成實體的各屬性之間的聯系；實體之間的聯系通常是指不同實體集之間的聯系。在E-R圖中用菱形表示，菱形框內寫明聯系名，并用無向邊分別與有關實體連接起來，同時在無向邊旁標上聯系的類型（1 : 1，1 : n或m : n），比如老師給學生授課存在授課關系，學生選課存在選課關系。如果是弱實體的聯系則在菱形外面再套菱形。

聯系可分為以下 3 種類型：

• 一對一聯系(1 ∶1)

例如，一個班級有一個班長，而每個班長只在一個班級任職，則班級與班長的聯系是一對一的。

• 一對多聯系(1 ∶N)

例如，某校教師與課程之間存在一對多的聯系“教”，即每位教師可以教多門課程，但是每門課程只能由一位教師來教。

• 多對多聯系(M ∶N)

例如，學生與課程間的聯系(“學 ”)是多對多的，即一個學生可以學多門課程，而每門課程可以有多個學生來學。聯系也可能有屬性。例如，學生“ 學” 某門課程所取得的成績，既不是學生的屬性也不是課程的屬性。由于“ 成績” 既依賴于某名特定的學生又依賴于某門特定的課程，所以它是學生與課程之間的聯系“ 學”的屬性。

作圖步驟：

1. 確定所有的實體集合。
2. 選擇實體集應包含的屬性。
3. 確定實體集之間的聯系。
4. 確定實體集的關鍵字，用下劃線在屬性上表明關鍵字的屬性組合。
5. 確定聯系的類型，在用線將表示聯系的菱形框聯系到實體集時，在線旁注明聯系的類型。

8、數據庫的七種鎖

1. 行鎖（Record Locks） ：行鎖一定是作用在索引上的。
2. 間隙鎖（Gap Locks）：鎖在本質上是不區分共享間隙鎖或互斥間隙鎖的，而且間隙鎖是不互斥的，即兩個事務可以同時持有包含共同間隙的間隙鎖。這里的共同間隙包括兩種場景：其一是兩個間隙鎖的間隙區間完全一 樣；其二是一個間隙鎖包含的間隙區間是另一個間隙鎖包含間隙區間的 子集 。間隙鎖本質上是用于 阻止其他事務在該間隙內插入新記錄 ，而 自身事務是允許在該間隙內插入數據的 。也就是說間隙鎖的應用場景包括并發 讀取 、并發 更新 、并發刪除和并發 插入 。在RU和RC兩種隔離級別下，即使你使用select ... in share mode或select ... for update，也無法防止 幻讀 （讀后寫的場景）。因為這兩種隔離級別下只會有 行鎖 ，而不會有 間隙鎖 。這也是為什么示例中要規定隔離級別為RR的原因。
3. 臨鍵鎖（Next-key Locks）：臨鍵鎖是行鎖+間隙鎖，即臨鍵鎖是是一個左開右閉的區間，比如（3，5]。InnoDB的默認事務隔離級別是RR，在這種級別下，如果你使用select ... in share mode或者select ... for update語句，那么InnoDB會使用臨鍵鎖，因而可以防止 幻讀 ；但即使你的隔離級別是RR，如果你這是使用普通的select語句，那么InnoDB將是快照讀，不會使用任何鎖，因而還是無法防止 幻讀 。
4. 共享鎖/排他鎖（Shared and Exclusive Locks） ：共享鎖/排他鎖都只是 行鎖 ，與間隙鎖無關，這一點很重要，后面還會強調這一點。其中共享鎖是一個事務并發讀取某一行記錄所需要持有的鎖，比如select ... in share mode；排他鎖是一 個事務并發更新或刪除某一行記錄所需要持有的鎖，比如select ... for update。不過這里需要重點說明的是，盡管共享鎖/排他鎖是行鎖，與間隙鎖無關，但一個事務在請求共享鎖/排他鎖時，獲取到的結果卻可能是 行鎖 ，也可能是 間隙鎖 ，也可能是 臨鍵鎖 ，這取決于數據庫的隔離級別以及查詢的 數據是否存在 。關于這一點，后面分析場景一和場景二的時候還會提到。
5. 意向共享鎖/意向排他鎖（Intention Shared and Exclusive Locks） ：意向共享鎖/意向排他鎖屬于 表鎖 ，且取得意向共享鎖/意向排他鎖是取得共享鎖/排他鎖的 前置條件 。
6. 插入意向鎖（Insert Intention Locks） ：插入意向鎖是一種特殊的間隙鎖，但不同于間隙鎖的是，該鎖只用于并發插入操作。如果說間隙鎖鎖住的是一個區間，那么插入意向鎖鎖住的就是一個點。因而從這個角度來說，插入意向鎖確實是一種特殊的間隙鎖。與間隙鎖的另一個非常重要的差別是：盡管插入意向鎖也屬于 間隙鎖 ，但兩個事務卻不能在同一時間內一個擁有間隙鎖，另一個擁有該間隙區間內的插入意向鎖（當然，插入意向鎖如果不在間隙鎖區間內則是可以的）。這里我們再回顧一下共享鎖和排他鎖：共享鎖用于讀取操作，而排他鎖是用于更新或刪除操作。也就是說插入意向鎖、共享鎖和排他鎖涵蓋了常用的增刪改查四個動作。
7. 自增鎖（Auto-inc Locks） ：增鎖是一種特殊的表級鎖，主要用于事務中插入自增字段，也就是我們最常用的自增主鍵id。通過innodb_autoinc_lock_mode參數可以設置自增主鍵的生成策略。為了便于介紹innodb_autoinc_lock_mode參數，我們先將需要用到自增鎖的Insert語句進行分類：

9、數據庫高并發的解決方案

1. 在web服務框架中加入緩存。在服務器與數據庫層之間加入緩存層，將高頻訪問的數據存入緩存中，減少數據庫的讀取負擔。
2. 增加數據庫索引。提高查詢速度。（不過索引太多會導致速度變慢，并且數據庫的寫入會導致索引的更新，也會導致速度變慢）
3. 主從讀寫分離，讓主服務器負責寫，從服務器負責讀。
4. 將數據庫進行拆分，使得數據庫的表盡可能小，提高查詢的速度。
5. 使用分布式架構，分散計算壓力。

10、SQL語句的內部致性過程

• 連接器：客戶端先通過連接器連接到 MySQL 服務器。
• 緩存：連接器權限驗證通過之后，先查詢是否有查詢緩存，如果有緩存（之前執行過此語句）則直接返回緩存數據，如果沒有緩存則進入分析器。
• 分析器：分析器會對查詢語句進行語法分析和詞法分析，判斷 SQL 語法是否正確，如果查詢語法錯誤會直接返回給客戶端錯誤信息，如果語法正確則進入優化器。
• 優化器：優化器是對查詢語句進行優化處理，例如一個表里面有多個索引，優化器會判別哪個索引性能更好。
• 執行器：優化器執行完就進入執行器，執行器就開始執行語句進行查詢比對了，直到查詢到滿足條件的所有數據，然后進行返回。

11、為什么要分庫分表

數據庫中的數據量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的數據量也會越來越大，相應地，數據操作，增刪改查的開銷也會越來越大；另外，由于無法進行分布式式部署，而一臺服務器的資源（CPU、磁盤、內存、IO等）是有限的，最終數據庫所能承載的數據量、數據處理能力都將遭遇瓶頸。

12、分布式事務

分布式事務用于在分布式系統中保證不同節點之間的數據一致性。分布式事務的實現有很多種，最具有代表性的是由Oracle Tuxedo系統提出的XA分布式事務協議。

XA協議包含兩階段提交（2PC）和三階段提交（3PC）兩種 ：

1. 2PC: 在XA分布式事務的第一階段，作為事務協調者的節點會首先向所有的參與者節點發送Prepare請求。在接到Prepare請求之后，每一個參與者節點會各自執行與事務有關的數據更新，寫入Undo Log和Redo Log。如果參與者執行成功，暫時不提交事務，而是向事務協調節點返回“完成”消息。

   當事務協調者接到了所有參與者的返回消息，整個分布式事務將會進入第二階段。
   在XA分布式事務的第二階段，如果事務協調節點在之前所收到都是正向返回，那么它將會向所有事務參與者發出Commit請求。
   接到Commit請求之后，事務參與者節點會各自進行本地的事務提交，并釋放鎖資源。當本地事務完成。提交后，將會向事務協調者返回“完成”消息。

當事務協調者接收到所有事務參與者的“完成”反饋，整個分布式事務完成。

注意:

在XA的第一階段，如果某個事務參與者反饋失敗消息，說明該節點的本地事務執行不成功，必須回滾。于是在第二階段，事務協調節點向所有的事務參與者發送Abort請求。接收到Abort請求之后，各個事務參與者節點需要在本地進行事務的回滾操作，回滾操作依照Undo Log來進行。

XA兩階段提交的不足

1. 性能問題

XA協議遵循強一致性。在事務執行過程中，各個節點占用著數據庫資源，只有當所有節點準備完畢，事務協調者才會通知提交，參與者提交后釋放資源。這樣的過程有著非常明顯的性能問題。

2. 協調者單點故障問題

事務協調者是整個XA模型的核心，一旦事務協調者節點掛掉，參與者收不到提交或是回滾通知，參與者會一直處于中間狀態無法完成事務。

3. 丟失消息導致的不一致問題。

在XA協議的第二個階段，如果發生局部網絡問題，一部分事務參與者收到了提交消息，另一部分事務參與者沒收到提交消息，那么就導致了節點之間數據的不一致。

為了解決上訴問題，提供下面幾重分布式事務解決方案

1. XA三階段提交

XA三階段提交在兩階段提交的基礎上增加了CanCommit階段，并且引入了超時機制。一旦事物參與者遲遲沒有接到協調者的commit請求，會自動進行本地commit。這樣有效解決了協調者單點故障的問題。但是性能問題和不一致的問題仍然沒有根本解決。

2. MQ事務

利用消息中間件來異步完成事務的后一半更新，實現系統的最終一致性。這個方式避免了像XA協議那樣的性能問題。

3. TCC事務

TCC事務是Try、Commit、Cancel三種指令的縮寫，其邏輯模式類似于XA兩階段提交，但是實現方式是在代碼層面來人為實現。

既然能看到文末，我相信你一定是個非常有潛力的選手，你的耐心和你的專注度已經超過了同齡人，點贊收藏，需要用到的時候翻出來再好好復習復習。

如果這樣看起來不爽的話，你也可以后臺私信我，發你PDF版的，下載下來慢慢看哈哈。