客戶端、連接層、服務層、引擎層
㈡ 資料庫存儲引擎的是什麼概念
資料庫好像汽車，引擎就是發動機。
就是將數據存儲到磁碟得介面～MySQL有SQL語句分析層和存儲引擎層，當分析出SQL語句需要執行什麼操作後，調用存儲引擎的介面既可。leveldb就可以看成一個存儲引擎～個人理解！
㈢ 資料庫架構選型與落地，看這篇就夠了
隨著時間和業務的發展，資料庫中的數據量增長是不可控的，庫和表中的數據會越來越大，隨之帶來的是更高的 磁碟 、 IO 、 系統開銷 ，甚至 性能 上的瓶頸，而單台伺服器的 資源終究是有限 的。
因此在面對業務擴張過程中，應用程序對資料庫系統的 健壯性 ， 安全性 ， 擴展性 提出了更高的要求。
以下，我從資料庫架構、選型與落地來讓大家入門。
資料庫會面臨什麼樣的挑戰呢？
業務剛開始我們只用單機資料庫就夠了，但隨著業務增長，數據規模和用戶規模上升，這個時候資料庫會面臨IO瓶頸、存儲瓶頸、可用性、安全性問題。
為了解決上述的各種問題，資料庫衍生了出不同的架構來解決不同的場景需求。
將資料庫的寫操作和讀操作分離，主庫接收寫請求，使用多個從庫副本負責讀請求，從庫和主庫同步更新數據保持數據一致性，從庫可以水平擴展，用於面對讀請求的增加。
這個模式也就是常說的讀寫分離，針對的是小規模數據，而且存在大量讀操作的場景。
因為主從的數據是相同的，一旦主庫宕機的時候，從庫可以 切換為主庫提供寫入 ，所以這個架構也可以提高資料庫系統的 安全性 和 可用性 ；
優點：
缺點：
在資料庫遇到 IO瓶頸 過程中，如果IO集中在某一塊的業務中，這個時候可以考慮的就是垂直分庫，將熱點業務拆分出去，避免由 熱點業務 的 密集IO請求 影響了其他正常業務，所以垂直分庫也叫 業務分庫 。
優點：
缺點：
在資料庫遇到存儲瓶頸的時候，由於數據量過大造成索引性能下降。
這個時候可以考慮將數據做水平拆分，針對數據量巨大的單張表，按照某種規則，切分到多張表裡面去。
但是這些表還是在同一個庫中，所以庫級別的資料庫操作還是有IO瓶頸（單個伺服器的IO有上限）。
所以水平分表主要還是針對 數據量較大 ，整體業務 請求量較低 的場景。
優點：
缺點：
四、分庫分表
在資料庫遇到存儲瓶頸和IO瓶頸的時候，數據量過大造成索引性能下降，加上同一時間需要處理大規模的業務請求，這個時候單庫的IO上限會限制處理效率。
所以需要將單張表的數據切分到多個伺服器上去，每個伺服器具有相應的庫與表，只是表中數據集合不同。
分庫分表能夠有效地緩解單機和單庫的 性能瓶頸和壓力 ，突破IO、連接數、硬體資源等的瓶頸。
優點：
缺點：
註：分庫還是分表核心關鍵是有沒有IO瓶頸 。
分片方式都有什麼呢？
RANGE（范圍分片）
將業務表中的某個 關鍵欄位排序 後，按照順序從0到10000一個表，10001到20000一個表。最常見的就是 按照時間切分 （月表、年表）。
比如將6個月前，甚至一年前的數據切出去放到另外的一張表，因為隨著時間流逝，這些表的數據被查詢的概率變小，銀行的交易記錄多數是採用這種方式。
優點：
缺點：
HASH（哈希分片）
將訂單作為主表，然後將其相關的業務表作為附表，取用戶id然後 hash取模 ，分配到不同的數據表或者資料庫上。
優點：
缺點：
講到這里，我們已經知道資料庫有哪些架構，解決的是哪些問題，因此， 我們在日常設計中需要根據數據的特點，數據的傾向性，數據的安全性等來選擇不同的架構 。
那麼，我們應該如何選擇資料庫架構呢？
雖然把上面的架構全部組合在一起可以形成一個強大的高可用，高負載的資料庫系統，但是架構選擇合適才是最重要的。
混合架構雖然能夠解決所有的場景的問題，但是也會面臨更多的挑戰，你以為的完美架構，背後其實有著更多的坑。
1、對事務支持
分庫分表後（無論是垂直還是水平拆分），就成了分布式事務了，如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價（XA事務）；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔（TCC、SAGA）。
2、多庫結果集合並 （group by，order by）
由於數據分布於不同的資料庫中，無法直接對其做分頁、分組、排序等操作，一般應對這種多庫結果集合並的查詢業務都需要採用數據清洗、同步等其他手段處理（TIDB、KUDU等）。
3、數據延遲
主從架構下的多副本機制和水平分庫後的聚合庫都會存在主數據和副本數據之間的延遲問題。
4、跨庫join
分庫分表後表之間的關聯操作將受到限制，我們無法join位於不同分庫的表（垂直），也無法join分表粒度不同的表（水平）， 結果原本一次查詢就能夠完成的業務，可能需要多次查詢才能完成。
5、分片擴容
水平分片之後，一旦需要做擴容時。需要將對應的數據做一次遷移，成本代價都極高的。
6、ID生成
分庫分表後由於資料庫獨立，原有的基於資料庫自增ID將無法再使用，這個時候需要採用其他外部的ID生成方案。
一、應用層依賴類（JDBC）
這類分庫分表中間件的特點就是和應用強耦合，需要應用顯示依賴相應的jar包（以Java為例），比如知名的TDDL、當當開源的 sharding-jdbc 、蘑菇街的TSharding等。
此類中間件的基本思路就是重新實現JDBC的API，通過重新實現 DataSource 、 PrepareStatement 等操作資料庫的介面，讓應用層在 基本 不改變業務代碼的情況下透明地實現分庫分表的能力。
中間件給上層應用提供熟悉的JDBC API，內部通過 sql解析 、 sql重寫 、 sql路由 等一系列的准備工作獲取真正可執行的sql，然後底層再按照傳統的方法（比如資料庫連接池）獲取物理連接來執行sql，最後把數據 結果合並 處理成ResultSet返回給應用層。
優點
缺點
二、中間層代理類（Proxy）
這類分庫分表中間件的核心原理是在應用和資料庫的連接之間搭起一個 代理層 ，上層應用以 標準的MySQL協議 來連接代理層，然後代理層負責 轉發請求 到底層的MySQL物理實例，這種方式對應用只有一個要求，就是只要用MySQL協議來通信即可。
所以用MySQL Navicat這種純的客戶端都可以直接連接你的分布式資料庫，自然也天然 支持所有的編程語言 。
在技術實現上除了和應用層依賴類中間件基本相似外，代理類的分庫分表產品必須實現標準的MySQL協議，某種意義上講資料庫代理層轉發的就是MySQL協議請求，就像Nginx轉發的是Http協議請求。
比較有代表性的產品有開創性質的Amoeba、阿里開源的Cobar、社區發展比較好的 Mycat （基於Cobar開發）等。
優點
缺點
JDBC方案 ：無中心化架構，兼容市面上大多數關系型資料庫，適用於開發高性能的輕量級 OLTP 應用（面向前台）。
Proxy方案 ：提供靜態入口以及異構語言的支持，適用於 OLAP 應用（面向後台）以及對分片資料庫進行管理和運維的場景。
混合方案 ：在大型復雜系統中存在面向C端用戶的前台應用，也有面向企業分析的後台應用，這個時候就可以採用混合模式。
JDBC 採用無中心化架構，適用於 Java 開發的高性能的輕量級 OLTP 應用；Proxy 提供靜態入口以及異構語言的支持，適用於 OLAP 應用以及對分片資料庫進行管理和運維的場景。
ShardingSphere是一套開源的分布式資料庫中間件解決方案組成的生態圈，它由 Sharding-JDBC 、 Sharding-Proxy 和 Sharding-Sidecar （計劃中）這3款相互獨立的產品組成，他們均提供標准化的數據分片、分布式事務和資料庫治理功能，可適用於如Java同構、異構語言、容器、雲原生等各種多樣化的應用場景。
ShardingSphere提供的核心功能：
Sharding-Proxy
定位為透明化的 資料庫代理端 ，提供封裝了 資料庫二進制協議的服務端版本 ，用於完成對 異構語言的支持 。
目前已提供MySQL版本，它可以使用 任何兼容MySQL協議的訪問客戶端 (如：MySQL Command Client, MySQL Workbench, Navicat等)操作數據，對DBA更加友好。
向 應用程序完全透明 ，可直接當做MySQL使用。
適用於任何兼容MySQL協議的客戶端。
Sharding-JDBC
定位為 輕量級Java框架 ，在Java的JDBC層提供的額外服務。 它使用客戶端直連資料庫，以jar包形式提供服務，無需額外部署和依賴，可理解為 增強版的JDBC驅動，完全兼容JDBC和各種ORM框架 。
以電商SaaS系統為例，前台應用採用Sharding-JDBC，根據業務場景的差異主要分為三種方案。
分庫（用戶）
問題解析：頭部企業日活高並發高，單獨分庫避免干擾其他企業用戶，用戶數據的增長緩慢可以不分表。
拆分維度：企業ID分庫
拆分策略：頭部企業單獨庫、非頭部企業一個庫
分庫分表（訂單）
問題解析：訂單數據增長速度較快，在分庫之餘需要分表。
拆分維度：企業ID分庫、用戶ID分表
拆分策略：頭部企業單獨庫、非頭部企業一個庫，分庫之後用戶ID取模拆分表
單庫分表（附件）
問題解析：附件數據特點是並發量不大，只需要解決數據增長問題，所以單庫IO足以支撐的情況下分表即可。
拆分維度：用戶ID分表
拆分策略：用戶ID取模分表
問題一：分布式事務
分布式事務過於復雜也是分布式系統最難處理的問題，由於篇幅有限，後續會開篇專講這一塊內容。
問題二：分布式ID
問題三：跨片查詢
舉個例子，以用戶id分片之後，需要根據企業id查詢企業所有用戶信息。
sharding針對跨片查詢也是能夠支持的，本質上sharding的跨片查詢是採用同時查詢多個分片的數據，然後聚合結果返回，這個方式對資源耗費比較大，特別是對資料庫連接資源的消耗。
假設分4個資料庫，8個表，則sharding會同時發出32個SQL去查詢。一下子消耗掉了32個連接；
特別是針對單庫分表的情況要注意，假設單庫分64個表，則要消耗64個連接。如果我們部署了2個節點，這個時候兩個節點同時查詢的話，就會遇到資料庫連接數上限問題（mysql默認100連接數）
問題四：分片擴容
隨著數據增長，每個片區的數據也會達到瓶頸，這個時候需要將原有的分片數量進行增加。由於增加了片區，原先的hash規則也跟著變化，造成了需要將舊數據做遷移。
假設原先1個億的數據，hash分64個表，現在增長到50億的數據，需要擴容到128個表，一旦擴容就需要將這50億的數據做一次遷移，遷移成本是無法想像的。
問題五：一致性哈希
首先，求出每個 伺服器的hash值 ，將其配置到一個 0~2^n 的圓環上 （n通常取32）
其次，用同樣的方法求出待 存儲對象的主鍵 hash值 ，也將其配置到這個圓環上。
然後，從數據映射到的位置開始順時針查找，將數據分布到找到的第一個伺服器節點上。
一致性hash的優點在於加入和刪除節點時只會影響到在哈希環中相鄰的節點，而對其他節點沒有影響。
所以使用一致性哈希在集群擴容過程中可以減少數據的遷移。
好了，這次分享到這里，我們日常的實踐可能只會用到其中一種方案，但它不是資料庫架構的全貌，打開技術視野，才能更好地把存儲工具利用起來。
老規矩，一鍵三連，日入兩千，點贊在看，年薪百萬！
本文作者：Jensen
7年Java老兵，小米主題設計師，手機輸入法設計師，ProcessOn特邀講師。
曾涉獵航空、電信、IoT、垂直電商產品研發，現就職於某知名電商企業。
技術公眾號 【架構師修行錄】 號主，專注於分享日常架構、技術、職場干貨，Java Goals：架構師。
交個朋友，一起成長！
㈣ 資料庫系統包括七個層次的內容
第7層 應用層：OSI中的最高層。為特定類型的網路應用提供了訪問OSI環境的手段。應用層確定進程之間通信的性質，以滿足用戶的需要。應用層不僅要提供應用進程所需要的信息交換和遠程操作，而且還要作為應用進程的用戶代理，來完成一些為進行信息交換所必需的功能。它包括：文件傳送訪問和管理FTAM、虛擬終端VT、事務處理TP、遠程資料庫訪問RDA、製造報文規范MMS、目錄服務DS等協議；
第6層 表示層：主要用於處理兩個通信系統中交換信息的表示方式。為上層用戶解決用戶信息的語法問題。它包括數據格式交換、數據加密與解密、數據壓縮與恢復等功能；
第5層 會話層：—在兩個節點之間建立端連接。為端系統的應用程序之間提供了對話控制機制。此服務包括建立連接是以全雙工還是以半雙工的方式進行設置，盡管可以在層4中處理雙工方式 ；
第4層 傳輸層：—常規數據遞送－面向連接或無連接。為會話層用戶提供一個端到端的可靠、透明和優化的數據傳輸服務機制。包括全雙工或半雙工、流控制和錯誤恢復服務；
第3層 網路層：—本層通過定址來建立兩個節點之間的連接，為源端的運輸層送來的分組，選擇合適的路由和交換節點，正確無誤地按照地址傳送給目的端的運輸層。它包括通過互連網路來路由和中繼數據 ；
第2層 數據鏈路層：—在此層將數據分幀，並處理流控制。屏蔽物理層，為網路層提供一個數據鏈路的連接，在一條有可能出差錯的物理連接上，進行幾乎無差錯的數據傳輸。本層指定拓撲結構並提供硬體定址；
第1層 物理層：處於OSI參考模型的最底層。物理層的主要功能是利用物理傳輸介質為數據鏈路層提供物理連接，以便透明的傳送比特流。
數據發送時，從第七層傳到第一層，接收數據則相反。
㈤ mysql 核心內容-上
1、SQL語句執行流程
MySQL大體上可分為Server層和存儲引擎層兩部分。
Server層：
連接器：TCP握手後伺服器來驗證登陸用戶身份，A用戶創建連接後，管理員對A用戶許可權修改了也不會影響到已經創建的鏈接許可權，必須重新登陸。
查詢緩存：查詢後的結果存儲位置，MySQL8.0版本以後已經取消，因為查詢緩存失效太頻繁，得不償失。
分析器：根據語法規則，判斷你輸入的這個SQL語句是否滿足MySQL語法。
優化器：多種執行策略可實現目標，系統自動選擇最優進行執行。
執行器：判斷是否有許可權，將最終任務提交到存儲引擎。
存儲引擎層
負責數據的存儲和提取。其架構模式是插件式的，支持InnoDB、MyISAM、Memory等多個存儲引擎。現在最常用的存儲引擎是InnoDB，它從MySQL 5.5.5版本開始成為了默認存儲引擎(經常用的也是這個)。
SQL執行順序
2、BinLog、RedoLog、UndoLog
BinLog
BinLog是記錄所有資料庫表結構變更（例如create、alter table）以及表數據修改(insert、update、delete)的二進制日誌，主從資料庫同步用到的都是BinLog文件。BinLog日誌文件有三種模式。
STATEMENT 模式
內容：binlog 記錄可能引起數據變更的 sql 語句
優勢：該模式下，因為沒有記錄實際的數據，所以日誌量很少 IO 都消耗很低，性能是最優的
劣勢：但有些操作並不是確定的，比如 uuid() 函數會隨機產生唯一標識，當依賴 binlog 回放時，該操作生成的數據與原數據必然是不同的，此時可能造成無法預料的後果。
ROW 模式
內容：在該模式下，binlog 會記錄每次操作的源數據與修改後的目標數據，StreamSets就要求該模式。
優勢：可以絕對精準的還原，從而保證了數據的安全與可靠，並且復制和數據恢復過程可以是並發進行的
劣勢：缺點在於 binlog 體積會非常大，同時，對於修改記錄多、欄位長度大的操作來說，記錄時性能消耗會很嚴重。閱讀的時候也需要特殊指令來進行讀取數據。
MIXED 模式
內容：是對上述STATEMENT 跟 ROW 兩種模式的混合使用。
細節：對於絕大部分操作，都是使用 STATEMENT 來進行 binlog 沒有記錄，只有以下操作使用 ROW 來實現：表的存儲引擎為 NDB，使用了uuid() 等不確定函數，使用了 insert delay 語句，使用了臨時表
主從同步流程：
1、主節點必須啟用二進制日誌，記錄任何修改了資料庫數據的事件。
2、從節點開啟一個線程（I/O Thread)把自己扮演成 mysql 的客戶端，通過 mysql 協議，請求主節點的二進制日誌文件中的事件 。
3、主節點啟動一個線程（mp Thread），檢查自己二進制日誌中的事件，跟對方請求的位置對比，如果不帶請求位置參數，則主節點就會從第一個日誌文件中的第一個事件一個一個發送給從節點。
4、從節點接收到主節點發送過來的數據把它放置到中繼日誌（Relay log）文件中。並記錄該次請求到主節點的具體哪一個二進制日誌文件內部的哪一個位置（主節點中的二進制文件會有多個）。
5、從節點啟動另外一個線程（sql Thread ），把 Relay log 中的事件讀取出來，並在本地再執行一次。
mysql默認的復制方式是非同步的，並且復制的時候是有並行復制能力的。主庫把日誌發送給從庫後不管了，這樣會產生一個問題就是假設主庫掛了，從庫處理失敗了，這時候從庫升為主庫後，日誌就丟失了。由此產生兩個概念。
全同步復制
主庫寫入binlog後強制同步日誌到從庫，所有的從庫都執行完成後才返回給客戶端，但是很顯然這個方式的話性能會受到嚴重影響。
半同步復制
半同步復制的邏輯是這樣，從庫寫入日誌成功後返回ACK確認給主庫，主庫收到至少一個從庫的確認就認為寫操作完成。
還可以延伸到由於主從配置不一樣、主庫大事務、從庫壓力過大、網路震盪等造成主備延遲，如何避免這個問題？主備切換的時候用可靠性優先原則還是可用性優先原則？如何判斷主庫Crash了？互為主備的情況下如何避免主備循環復制？被刪庫跑路了如何正確恢復？( o )… 感覺越來越扯到DBA的活兒上去了。
RedoLog
可以先通過下面demo理解：
飯點記賬可以把賬單寫在賬本上也可以寫在粉板上。有人賒賬或者還賬的話，一般有兩種做法：
1、直接把賬本翻出來，把這次賒的賬加上去或者扣除掉。
2、先在粉板上記下這次的賬，等打烊以後再把賬本翻出來核算。
生意忙時選後者，因為前者太麻煩了。得在密密麻麻的記錄中找到這個人的賒賬總額信息，找到之後再拿出算盤計算，最後再將結果寫回到賬本上。
同樣在MySQL中如果每一次的更新操作都需要寫進磁碟，然後磁碟也要找到對應的那條記錄，然後再更新，整個過程IO成本、查找成本都很高。而粉板和賬本配合的整個過程就是MySQL用到的是Write-Ahead Logging 技術，它的關鍵點就是先寫日誌，再寫磁碟。此時賬本 = BinLog，粉板 = RedoLog。
1、 記錄更新時，InnoDB引擎就會先把記錄寫到RedoLog（粉板）裡面，並更新內存。同時，InnoDB引擎會在空閑時將這個操作記錄更新到磁碟裡面。
2、 如果更新太多RedoLog處理不了的時候，需先將RedoLog部分數據寫到磁碟，然後擦除RedoLog部分數據。RedoLog類似轉盤。
RedoLog有write pos 跟checkpoint
write pos ：是當前記錄的位置，一邊寫一邊後移，寫到第3號文件末尾後就回到0號文件開頭。
check point：是當前要擦除的位置，也是往後推移並且循環的，擦除記錄前要把記錄更新到數據文件。
write pos和check point之間的是粉板上還空著的部分，可以用來記錄新的操作。如果write pos追上checkpoint，表示粉板滿了，這時候不能再執行新的更新，得停下來先擦掉一些記錄，把checkpoint推進一下。
有了redo log，InnoDB就可以保證即使資料庫發生異常重啟，之前提交的記錄都不會丟失，這個能力稱為crash-safe。 redolog兩階段提交：為了讓binlog跟redolog兩份日誌之間的邏輯一致。提交流程大致如下：
1 prepare階段 --> 2 寫binlog --> 3 commit
當在2之前崩潰時，重啟恢復後發現沒有commit，回滾。備份恢復：沒有binlog 。一致
當在3之前崩潰時，重啟恢復發現雖沒有commit，但滿足prepare和binlog完整，所以重啟後會自動commit。備份：有binlog. 一致
binlog跟redolog區別：
redo log是InnoDB引擎特有的；binlog是MySQL的Server層實現的，所有引擎都可以使用。
redo log是物理日誌，記錄的是在某個數據頁上做了什麼修改；binlog是邏輯日誌，記錄的是這個語句的原始邏輯，比如給ID=2這一行的c欄位加1。
redo log是循環寫的，空間固定會用完；binlog是可以追加寫入的。追加寫是指binlog文件寫到一定大小後會切換到下一個，並不會覆蓋以前的日誌。
UndoLog
UndoLog 一般是邏輯日誌，主要分為兩種：
insert undo log
代表事務在insert新記錄時產生的undo log, 只在事務回滾時需要，並且在事務提交後可以被立即丟棄
update undo log
事務在進行update或delete時產生的undo log; 不僅在事務回滾時需要，在快照讀時也需要；所以不能隨便刪除，只有在快速讀或事務回滾不涉及該日誌時，對應的日誌才會被purge線程統一清除
3、MySQL中的索引
索引的常見模型有哈希表、有序數組和搜索樹。
哈希表：一種以KV存儲數據的結構，只適合等值查詢，不適合范圍查詢。
有序數組：只適用於靜態存儲引擎，涉及到插入的時候比較麻煩。可以參考Java中的ArrayList。
搜索樹：按照數據結構中的二叉樹來存儲數據，不過此時是N叉樹(B+樹)。廣泛應用在存儲引擎層中。
B+樹比B樹優勢在於：
B+ 樹非葉子節點存儲的只是索引，可以存儲的更多。B+樹比B樹更加矮胖，IO次數更少。
B+ 樹葉子節點前後管理，更加方便范圍查詢。同時結果都在葉子節點，查詢效率穩定。
B+樹中更有利於對數據掃描，可以避免B樹的回溯掃描。
索引的優點：
1、唯一索引可以保證每一行數據的唯一性
2、提高查詢速度
3、加速表與表的連接
4、顯著的減少查詢中分組和排序的時間
5、通過使用索引，可以在查詢的過程中，使用優化隱藏器，提高系統的性能。
索引的缺點：
1、創建跟維護都需要耗時
2、創建索引時，需要對表加鎖，在鎖表的同時，可能會影響到其他的數據操作
3、 索引需要磁碟的空間進行存儲，磁碟佔用也很快。
4、當對表中的數據進行CRUD的時，也會觸發索引的維護，而維護索引需要時間，可能會降低數據操作性能
索引設計的原則不應該：
1、索引不是越多越好。索引太多，維護索引需要時間跟空間。
2、 頻繁更新的數據，不宜建索引。
3、數據量小的表沒必要建立索引。
應該：
1、重復率小的列建議生成索引。因為重復數據少，索引樹查詢更有效率，等價基數越大越好。
2、數據具有唯一性，建議生成唯一性索引。在資料庫的層面，保證數據正確性
3、頻繁group by、order by的列建議生成索引。可以大幅提高分組和排序效率
4、經常用於查詢條件的欄位建議生成索引。通過索引查詢，速度更快
索引失效的場景
1、模糊搜索：左模糊或全模糊都會導致索引失效，比如'%a'和'%a%'。但是右模糊是可以利用索引的，比如'a%' 。
2、隱式類型轉換：比如select * from t where name = xxx , name是字元串類型，但是沒有加引號，所以是由MySQL隱式轉換的，所以會讓索引失效 3、當語句中帶有or的時候：比如select * from t where name=『sw』 or age=14
4、不符合聯合索引的最左前綴匹配：(A,B,C)的聯合索引，你只where了C或B或只有B,C
關於索引的知識點：
主鍵索引：主鍵索引的葉子節點存的是整行數據信息。在InnoDB里，主鍵索引也被稱為聚簇索引（clustered index）。主鍵自增是無法保證完全自增的哦，遇到唯一鍵沖突、事務回滾等都可能導致不連續。
唯一索引：以唯一列生成的索引，該列不允許有重復值，但允許有空值(NULL)
普通索引跟唯一索引查詢性能：InnoDB的數據是按數據頁為單位來讀寫的，默認每頁16KB，因此這兩種索引查詢數據性能差別微乎其微。
change buffer：普通索引用在更新過程的加速，更新的欄位如果在緩存中，如果是普通索引則直接更新即可。如果是唯一索引需要將所有數據讀入內存來確保不違背唯一性，所以盡量用普通索引。
非主鍵索引：非主鍵索引的葉子節點內容是主鍵的值。在InnoDB里，非主鍵索引也被稱為二級索引（secondary index）
回表：先通過資料庫索引掃描出數據所在的行，再通過行主鍵id取出索引中未提供的數據，即基於非主鍵索引的查詢需要多掃描一棵索引樹。
覆蓋索引：如果一個索引包含（或者說覆蓋）所有需要查詢的欄位的值，我們就稱之為覆蓋索引。
聯合索引：相對單列索引，組合索引是用多個列組合構建的索引，一次性最多聯合16個。
最左前綴原則：對多個欄位同時建立的組合索引(有順序，ABC，ACB是完全不同的兩種聯合索引) 以聯合索引(a,b,c)為例，建立這樣的索引相當於建立了索引a、ab、abc三個索引。另外組合索引實際還是一個索引，並非真的創建了多個索引，只是產生的效果等價於產生多個索引。
索引下推：MySQL 5.6引入了索引下推優化，可以在索引遍歷過程中，對索引中包含的欄位先做判斷，過濾掉不符合條件的記錄，減少回表字數。
索引維護：B+樹為了維護索引有序性涉及到頁分裂跟頁合並。增刪數據時需考慮頁空間利用率。
自增主鍵：一般會建立與業務無關的自增主鍵，不會觸發葉子節點分裂。
延遲關聯：通過使用覆蓋索引查詢返回需要的主鍵，再根據主鍵關聯原表獲得需要的數據。
InnoDB存儲: * .frm文件是一份定義文件，也就是定義資料庫表是一張怎麼樣的表。*.ibd文件則是該表的索引，數據存儲文件，既該表的所有索引樹，所有行記錄數據都存儲在該文件中。
MyISAM存儲：* .frm文件是一份定義文件，也就是定義資料庫表是一張怎麼樣的表。* .MYD文件是MyISAM存儲引擎表的所有行數據的文件。* .MYI文件存放的是MyISAM存儲引擎表的索引相關數據的文件。MyISAM引擎下，表數據和表索引數據是分開存儲的。
MyISAM查詢：在MyISAM下，主鍵索引和輔助鍵索引都屬於非聚簇索引。查詢不管是走主鍵索引，還是非主鍵索引，在葉子結點得到的都是目的數據的地址，還需要通過該地址，才能在數據文件中找到目的數據。
PS：InnoDB支持聚簇索引，MyISAM不支持聚簇索引
4、SQL事務隔離級別
ACID的四個特性
原子性（Atomicity）：把多個操作放到一個事務中，保證這些操作要麼都成功，要麼都不成功
一致性（Consistency）：理解成一串對數據進行操作的程序執行下來，不會對數據產生不好的影響，比如憑空產生，或消失
隔離性（Isolation，又稱獨立性）：隔離性的意思就是多個事務之間互相不幹擾，即使是並發事務的情況下，他們只是兩個並發執行沒有交集，互不影響的東西；當然實現中，也不一定需要這么完整隔離性，即不一定需要這么的互不幹擾，有時候還是允許有部分干擾的。所以MySQL可以支持4種事務隔離性
持久性（Durability）：當某個操作操作完畢了，那麼結果就是這樣了，並且這個操作會持久化到日誌記錄中
PS：ACID中C與CAP定理中C的區別
ACID的C著重強調單資料庫事務操作時，要保證數據的完整和正確性，數據不會憑空消失跟增加。CAP 理論中的C指的是對一個數據多個備份的讀寫一致性
事務操作可能會出現的數據問題
1、臟讀(dirty read)：B事務更改數據還未提交，A事務已經看到並且用了。B事務如果回滾，則A事務做錯了
2、 不可重復讀(non-repeatable read)：不可重復讀的重點是修改: 同樣的條件, 你讀取過的數據, 再次讀取出來發現值不一樣了，只需要鎖住滿足條件的記錄
3、 幻讀(phantom read)：事務A先修改了某個表的所有紀錄的狀態欄位為已處理，未提交；事務B也在此時新增了一條未處理的記錄，並提交了；事務A隨後查詢記錄，卻發現有一條記錄是未處理的造成幻讀現象，幻讀僅專指新插入的行。幻讀會造成語義上的問題跟數據一致性問題。
4、 在可重復讀RR隔離級別下，普通查詢是快照讀，是不會看到別的事務插入的數據的。因此，幻讀在當前讀下才會出現。要用間隙鎖解決此問題。
在說隔離級別之前，你首先要知道，你隔離得越嚴實，效率就會越低。因此很多時候，我們都要在二者之間尋找一個平衡點。SQL標準的事務隔離級別由低到高如下： 上圖從上到下的模式會導致系統的並行性能依次降低，安全性依次提高。
讀未提交：別人改數據的事務尚未提交，我在我的事務中也能讀到。
讀已提交(Oracle默認)：別人改數據的事務已經提交，我在我的事務中才能讀到。
可重復讀(MySQL默認)：別人改數據的事務已經提交，我在我的事務中也不去讀，以此保證重復讀一致性。
串列：我的事務尚未提交，別人就別想改數據。
標准跟實現：上面都是關於事務的標准，但是每一種資料庫都有不同的實現，比如MySQL InnDB 默認為RR級別，但是不會出現幻讀。因為當事務A更新了所有記錄的某個欄位，此時事務A會獲得對這個表的表鎖，因為事務A還沒有提交，所以事務A獲得的鎖沒有釋放，此時事務B在該表插入新記錄，會因為無法獲得該表的鎖，則導致插入操作被阻塞。只有事務A提交了事務後，釋放了鎖，事務B才能進行接下去的操作。所以可以說 MySQL的RR級別的隔離是已經實現解決了臟讀，不可重復讀和幻讀的。
5、MySQL中的鎖
無論是Java的並發編程還是資料庫的並發操作都會涉及到鎖，研發人員引入了悲觀鎖跟樂觀鎖這樣一種鎖的設計思想。
悲觀鎖：
優點：適合在寫多讀少的並發環境中使用，雖然無法維持非常高的性能，但是在樂觀鎖無法提更好的性能前提下，可以做到數據的安全性
缺點：加鎖會增加系統開銷，雖然能保證數據的安全，但數據處理吞吐量低，不適合在讀書寫少的場合下使用
樂觀鎖：
優點：在讀多寫少的並發場景下，可以避免資料庫加鎖的開銷，提高DAO層的響應性能，很多情況下ORM工具都有帶有樂觀鎖的實現，所以這些方法不一定需要我們人為的去實現。
缺點：在寫多讀少的並發場景下，即在寫操作競爭激烈的情況下，會導致CAS多次重試，沖突頻率過高，導致開銷比悲觀鎖更高。
實現：資料庫層面的樂觀鎖其實跟CAS思想類似， 通數據版本號或者時間戳也可以實現。
資料庫並發場景主要有三種：
讀-讀：不存在任何問題，也不需要並發控制
讀-寫：有隔離性問題，可能遇到臟讀，幻讀，不可重復讀
寫-寫：可能存更新丟失問題，比如第一類更新丟失，第二類更新丟失
兩類更新丟失問題：
第一類更新丟失：事務A的事務回滾覆蓋了事務B已提交的結果 第二類更新丟失：事務A的提交覆蓋了事務B已提交的結果
為了合理貫徹落實鎖的思想，MySQL中引入了雜七雜八的各種鎖：
鎖分類
MySQL支持三種層級的鎖定，分別為
表級鎖定
MySQL中鎖定粒度最大的一種鎖，最常使用的MYISAM與INNODB都支持表級鎖定。
頁級鎖定
是MySQL中鎖定粒度介於行級鎖和表級鎖中間的一種鎖，表級鎖速度快，但沖突多，行級沖突少，但速度慢。所以取了折衷的頁級，一次鎖定相鄰的一組記錄。
行級鎖定
Mysql中鎖定粒度最細的一種鎖，表示只針對當前操作的行進行加鎖。行級鎖能大大減少資料庫操作的沖突。其加鎖粒度最小，但加鎖的開銷也最大行級鎖不一定比表級鎖要好：鎖的粒度越細，代價越高，相比表級鎖在表的頭部直接加鎖，行級鎖還要掃描找到對應的行對其上鎖，這樣的代價其實是比較高的，所以表鎖和行鎖各有所長。
MyISAM中的鎖
雖然MySQL支持表，頁，行三級鎖定，但MyISAM存儲引擎只支持表鎖。所以MyISAM的加鎖相對比較開銷低，但數據操作的並發性能相對就不高。但如果寫操作都是尾插入，那還是可以支持一定程度的讀寫並發
從MyISAM所支持的鎖中也可以看出，MyISAM是一個支持讀讀並發，但不支持通用讀寫並發，寫寫並發的資料庫引擎，所以它更適合用於讀多寫少的應用場合，一般工程中也用的較少。
InnoDB中的鎖
該模式下支持的鎖實在是太多了，具體如下：
共享鎖和排他鎖 (Shared and Exclusive Locks)
意向鎖（Intention Locks）
記錄鎖（Record Locks）
間隙鎖（Gap Locks）
臨鍵鎖 （Next-Key Locks）
插入意向鎖（Insert Intention Locks）
主鍵自增鎖 (AUTO-INC Locks)
空間索引斷言鎖（Predicate Locks for Spatial Indexes）
舉個栗子，比如行鎖里的共享鎖跟排它鎖：lock in share modle 共享讀鎖：
為了確保自己查到的數據沒有被其他的事務正在修改，也就是說確保查到的數據是最新的數據，並且不允許其他人來修改數據。但是自己不一定能夠修改數據，因為有可能其他的事務也對這些數據使用了 in share mode 的方式上了S 鎖。如果不及時的commit 或者rollback 也可能會造成大量的事務等待。
for update排它寫鎖:
為了讓自己查到的數據確保是最新數據，並且查到後的數據只允許自己來修改的時候，需要用到for update。相當於一個 update 語句。在業務繁忙的情況下，如果事務沒有及時的commit或者rollback 可能會造成其他事務長時間的等待，從而影響資料庫的並發使用效率。
Gap Lock間隙鎖：
1、行鎖只能鎖住行，如果在記錄之間的間隙插入數據就無法解決了，因此MySQL引入了間隙鎖(Gap Lock)。間隙鎖是左右開區間。間隙鎖之間不會沖突。
2、間隙鎖和行鎖合稱NextKeyLock，每個NextKeyLock是前開後閉區間。
間隙鎖加鎖原則(學完忘那種)：
1、加鎖的基本單位是 NextKeyLock，是前開後閉區間。
2、查找過程中訪問到的對象才會加鎖。
3、索引上的等值查詢，給唯一索引加鎖的時候，NextKeyLock退化為行鎖。
4、索引上的等值查詢，向右遍歷時且最後一個值不滿足等值條件的時候，NextKeyLock退化為間隙鎖。
5、唯一索引上的范圍查詢會訪問到不滿足條件的第一個值為止。
㈥ 全國計算機三級資料庫考點分析之資料庫系統基本原理[5]
考點46物理設計的評價
資料庫物理設計過程中需要對時間效率、空間效率、維護代價和各種用戶要求進行權衡，其結果可以產生多種方案，資料庫設計人員必須對這些方案進行細致的評價，從中選擇一個較優的方案作為資料庫的物理結構。
在資料庫應用系統生存期中，總的開銷包括：規劃開銷、設計開銷、實施和測試開銷、操作開銷、運行維護開銷。評價物理資料庫的方法完全依賴於所選用的DBMS。
4.20實現和維護
考點47資料庫的實現
資料庫實現的主要工作有以下幾個方面：
(1)定義資料庫結構。
(2)編制與調試應用程序。
(3)數據裝載。
(4)資料庫試運行。
考點48其他設計
其他設計工作包括加強資料庫的安全性、完整性控制，以及保證一致性、可恢復性等，總是以犧牲效率為代價的。設計人員的任務就是要在實現代價和盡可能多的功能之間進行合理平衡。其他設計包括資料庫的再組織設計、故障恢復方案設計、安全性考慮和事務控制等。
考點49資料庫的運行和維護
在資料庫運行階段，對資料庫經常性的維護工作主要是由DBA完成的，它包括以下幾個方面：
(1)資料庫的轉儲和恢復。
(2)資料庫的安全性、滑此完整性控制。
(3)資料庫性能的監督、分析和改進。
(4)資料庫的重組織和重構造。
4.21資料庫管理系統概述
考點50 DBMS的系統目標
資料庫管理系統(DBMS)是操作和管理資料庫的軟體系統，它由一組計算機程序構成，管理並控制數據資源的使用。資料庫管理系統是資料庫系統的核心DBMS的目標是用戶界面友好、結構清晰和開放性。
考點51 DBMS的基本功能
DBMS主要是實現對共享數據有效的組織、管理和存取。因此，DBMS具有如下幾個方面的基本功能。
(1)資料庫定義功能。
(2)數據存取功能。
(3)數據組織、存儲和管理。
(4)資料庫運行管理。
(5)資料庫的建立和維護。
(6)通信功能和數據轉換功能信滾迅等。
考點52 DBMS程序模塊的組成
大致來說，DBMS的程序模塊可按功能劃分為以下5個模塊：
(1)數據定義方面的程序模塊。
(2)數據操縱方面的程序模塊
(3)資料庫運行管理方面的程序模塊
(4)資料庫組織、存儲和管理方面的程序模塊。
(5)資料庫建立、維護和其他方面的程序模塊。
考點53 DBMS的層次結構
可以將DBMS劃分成若干層次，這樣可以幫助我們更清晰地認識DBMS，更重要的是有助於DBMS的設計和維護。
(1)最上層是應用層位於DBMS核心之外。
(2)第二層是語言翻譯處理層它處理的對象是資料庫語言}A SQL,
(3)第三層是數據存取層：該層處理的對象是單個元組。
(4)第四層是數據存儲層。該層處理的對象是數據頁和系統緩沖區。
(5)操作系統是DBMS的基礎。它處理的對象是數據文件的物理塊。
4.22新的應用需求對DBMS的挑戰
考點54新的應用需求對DBMS的挑戰
由於現在以關系型資料庫管理系統(RDBMS )為主流。這些新應用需求要求資料庫管理系統應該具有支持分布式操作、聯機事務處理能力、決策支持能力、支持多媒體、大容量、復雜數據應用、兼容性和集成能力、異種資料庫之間的互訪能力、系統可靠性、安全性、大型系統等方面的管理能力。
在我國，當前流行的資料庫管理系統絕大多數是關系型資料庫管理系統，一般可分為如下3類：
(1)以PC機、微型機系統為備告運行環境的資料庫管理系統。
(2)以Oracle為代表的資料庫管理系統，這類系統還有IBM DB2,Sybase等，也被稱為主流資料庫管理系統。
(3)以Microsoft SQI. Server為代表的介於以上兩類之間的資料庫管理系統。
4.23 Oracle資料庫系統
考點55Oracle資料庫系統簡介
Oracle關系型資料庫管理系統是美國Oracle公司的優秀軟體產品，它採用SQL語言作為資料庫語言。該公司於1979年推出了世界上第一個商業化的關系型資料庫系統。
Oracle資料庫的特點包括兼容性、可移植性、可連接性及高的生產率。
考點56 Oracle的主要產品及其功能
1Oracle資料庫服務霖功能及其特色
Oracle資料庫伺服器包括標准伺服器和許多可選的伺服器選件，選件用於擴展標准伺服器的功能，以適應特殊的應用需求。
(1)標准伺服器主要具有下列特色：多進程多線索的體系結構、高性能核心技術、高可用性和SQL的實現。
(2)並行伺服器選件(paralle server option)和並行查詢選件(paralle query option)。
(3)分布式選件(distributed)。
(4)過程化選件(proceral option)。
2Oracle的工具產品及其功能
為方便用戶開發資料庫應用程序，Oracle提供了眾多工具供用戶選擇使用，主要包括以下幾個方面：
(1)Developer/2000。它是Oracle的一個較新的應用開發工具集，包括Oracle Forms， Oracle Reports，Oracle Graphics和Oracle Books等多種工具，用來實現高生產率、大型事務處理及客戶／伺服器結構的應用系統。
(2)Designer/2000 。它是Oracle提供的CASE工具，能夠幫助用戶對復雜系統進行建模、分析和設計，由BPR、Modellers、Generators等組成。
(3 ) Discoverer/2000。它是一個OLAP工具，主要用於支持數據倉庫應用。
(4)Oracle Office。它是用於辦公自動化的，能完成企業范圍內的消息接收與發送。
(5)SQL DBA 。SQL DBN 是一個易於使用的。菜單驅動的DNA實用工具，可供用戶進行動態性能監視、遠程DB管理等。
4.24 IBM DB2資料庫系統
考點58 IBM DB2資料庫系統簡介
IBM DB2資料庫系統是美國IBM公司的產品1973年位於美國加州聖荷西市的IBM研究中心開始了一個大的關系型資料庫系統研究項目jvstem R，探討並驗證在多用戶與大量數據下關系型資料庫的實際可行性。
考點59 DB2通用資料庫的功能和特色
DB2家族除r包含在各種平台土運行的資料庫管理系統內核之外，產品包中還包括了數據復制、資料庫系統管理、Internet網關支持、在線分析處理、多媒體支持和各種並行處理能力，並為所有平台上的異構資料庫訪問提供『中間件」解決方案。
DB2通用資料庫(LDB)V7. 1的特色包括支持Internet應用、支持面向對象和多媒體應用、支持聯機分析處理和了干行處理能力。
考點60 IBM的商務智能解決方案
商務智能解決方案的基本結構往往包含以下3個部分：
(1)數據倉庫，用於抽取、整和、分布、存儲有用的信息。
(2)多維分析模型，全方位了解現狀。
(3)前台分析工具，提供簡單易用的圖形化界面給管理人員。
考點61 IBM內容管理解決方案
(1) IBM Content Manager On Demand.它可以完成電子存儲、回取、分發、列印和傳真，在極短的時間內就可以在顯示器上獲得與原來提供給客戶的一模一樣的報表／賬單及其他計算機的輸出信息。
(2)Digital Library IBM數字圖書館技術使人們快速而廉價地管理、訪問、保護及傳遞大量多種多樣的資料成為可能。這種數字化工作流程包含了一系列最新信息技術。
4.25 Sybase資料庫系統
考點62 Svbase資料庫簡介
Sybase是美國Sybase公司的產品。1986年正式推出Sybase資料庫系統。 Sybase在新興的EP發展策略中充分利用了已有的核心產品和戰略優勢，提供了滿足電子商務需求的解決方案。
考點63Sybase資料庫系統的功能及其特色
目前,Sybase資料庫系統定位在4個方向，分別在企業解決方案,Internet應用、商務智能和移動與嵌人計算領域為客戶提供先進的技術：
企業解決方案包括企業級資料庫、數據復制和數據訪問。主要產品有：Sybase EP,Adaptive Server Enter-prise、Adaptive Server Replication、Adaptive Server Connect及異構資料庫互聯選件。
4.26 IBS-SQL Server資料庫系統
考點64 MS-SQL Server資料庫系統
MS-SQL Server資料庫系統是美國Microsoft公司的產品。MS-SQL Server資料庫系統是在Svbase SQL erver 4的版本基礎上發展起來的。目前Microsoft SQL Server 7. 0和Microsoft SQL Server 2000廣泛使用於我國的各行各業，包括許多政府部門。
考點65 Microsoft SQL Server系統主要功能及其特性
1資料庫服備器MS-SQI, Server
MS-SQL決rver資料庫系統的核心是Microsoft SQL Server，簡稱MS-SQL Server或SQL Server，它有7.0、2000和2005三個主要版本。
2MS-SQL Server 2000的主要功能及其特色
MS-SQL Server 2000的主要功能有充分的Web支持、高度可伸縮性和可靠性、最快投放市場、充分的數據倉庫功能和廣泛的支持電子商務功能。
考點66 SQL Server 2000多版本支持
SQL Server 2000提供了各種不同的版本，包括SQL Server 2000企業版、SQL Server 2000標准版、SQLServer 2000個人版、SQL Server 2000開發人員版,SQL Server 2000企業評估版,SQL Server 2000桌面引擎和SQL Server 2000 Windows CE版