需要原文的可以留下郵箱我給你發，這里的文章少了很多圖，懶得網上粘啦
1數據庫基礎
1.1數據庫定義
1）數據庫(Database)是按照數據結構來組織、存儲和管理數據的建立在計算機存儲設備上的倉庫。簡單來說是本身可視為電子化的文件柜——存儲電子文件的處所，用戶可以對文件中的數據進行新增、截取、更新、刪除等操作。
2）數據庫是長期儲存在計算機內、有組織的、可共享的數據集合。數據庫中的數據指的是以一定的數據模型組織、描述和儲存在一起、具有盡可能小的冗余度、較高的數據獨立性和易擴展性的特點并可在一定范圍內為多個用戶共享。
這種數據集合具有如下特點：盡可能不重復，以最優方式為某個特定組織的多種應用服務，其數據結構獨立于使用它的應用程序，對數據的增、刪、改、查由統一軟件進行管理和控制。從發展的歷史看，數據庫是數據管理的高級階段，它是由文件管理系統發展起來的。
1.2數據庫系統VS文件系統
1）共同點：
同屬于系統軟件或底層軟件；都是用來存儲和訪問數據的；都有著悠久的研究開發歷史；都有成熟的標準或規范。這既有利于開發可移植的程序，又不利于開發創新的系統，特別是分布式系統。
實現技術上也有很多的共同點：大都采用C/C++這樣更底層的語言；需要保證數據的一致性，特別的，不同程度的支持事務；都有Block或Page或Allocation unit或Extent這樣的概念；都用到Buffer cache、LRU、Group commit之類的概念和算法；都要針對各種負載做IO優化
2）不同點：
數據庫對事務的支持要強很多，文件系統可以只保證元數據的一致性；數據庫有不同級別的一致性，以隔離級別的形式體現出來；數據庫可以有REDO和UNDO日志，文件系統一般只用REDO；數據庫的事務可以很長，文件系統的事務很短；數據庫的事務事先無法確定，是用戶輸入的，文件系統的事務可以事先確定，種類明確；數據庫是用戶態實現的，文件系統一般是內核態實現的。因此，前者更容易做到跨OS平臺；數據庫的訪問接口通常是非過程化的SQL語言，文件系統的則是API。二者對應的主流標準分別是SQL和POSIX；數據庫對死鎖可以做檢測，文件系統則需要避免死鎖。
3）聯系點：
數據庫系統經常依賴于文件系統作為其最底層的存儲，也可能會實現一些文件系統的功能；文件系統可以為數據庫這種特殊的應用做專門的優化；文件系統可以被當做簡單的數據庫使用（例如VSAM），數據庫也可以暴露出NFS（例如Oracle）；文件系統可能會用到一些簡單的數據庫功能（例如把符號鏈接當KV，實現簡單的DB功能，或直接用一個小型的DBMS）
1.3數據庫的體系結構
數據庫系統各個部分以及他們之間的聯系見圖1。
圖1DBMS體系結構
1.3.1集中式數據庫系統
[if !supportLists]1）[endif]集中式系統：運行在一臺機器上，數據集中存儲在一臺計算機中，并且不與其他計算機系統交互的數據庫系統。
[if !supportLists]2）[endif]單用戶系統：個人使用的桌面系統，單CPU，1至2個硬盤，OS可以只支持單用戶，數據庫系統不支持并發控制，故障恢復能力沒有或非常有限，用戶接口類似QBE。
3）多用戶系統
服務大量用戶，用戶通過終端與之相連，多個磁盤，多個主存儲器，多個CPU，多用戶OS，具有并發控制、故障恢復等能力
1.3.2 C/S數據庫系統
1.3.2.1簡介
連接到集中式系統的終端被PC代替；以前由集中式系統執行的諸如用戶界面功能由PC來處理；集中式系統變成服務器系統的作用，來響應客戶系統產生的請求，見圖2C/S數據庫系統。優點：
圖2C/S數據庫系統
具有如下優點：有利于充分利用網絡中的計算資源；減少網絡上的傳輸量；高性能/價格比；可擴展性；友好的用戶接口；易維護。
1.3.2.2服務器分類
[if !supportLists]1）[endif]事務服務器：又稱查詢服務器或SQL服務器，廣泛用于關系數據庫系統；客戶向服務器發送請求，事務在服務器端執行，結果返回給客戶端；可以以SQL表達請求，也可以通過應用程序接口，使用遠程過程調用(RPC)機制來表達請求；ODBC（Open Database Connectivity）使用ODBC接口的任何客戶程序都可以與提供ODBC接口的任何服務器連接。
2）數據服務器：用于局域網中；客戶與服務器之間具有高速連接；客戶機與服務器的處理能力相當，并且其執行的任務主要以計算為主；數據傳送到客戶機器，在客戶機上進行所有處理，然后再把數據傳回到服務器；多用于面向對象數據庫系統。
1.3.3并行數據庫系統
1.3.3.1簡介
由通過高速互連網絡連接在一起的多個CPU、存儲器和磁盤組成；查詢大數據量；處理大數量的事務；粗粒度并行機由幾個能力強大的處理器組成；細粒度并行機由數千個小處理器組成。
1.3.3.2應用需求和目的
需求：查詢非常大的數據庫（1012字節以上）;處理很大數量的事務（每秒數千個事務）
目的：保證即使在數據庫的規模和事務的數量都大大增長時，數據庫系統仍能以可接受的速度運行。
1.3.4分布式數據庫系統
1.3.4.1背景及定義
1）背景
分布式數據庫系統的應用背景是數據庫系統+計算機網絡，如圖3分布式系統圖例為銀行系統的一個簡單示例，數據庫系統分布與不同的地區，通過互聯網實現數據的寫入和讀取操作。
圖3分布式系統圖例
[if !supportLists]1）[endif]描述定義
D-DBS是一個數據集合，這些數據在邏輯上屬于同一個系統，但在物理上分布在計算機網絡的不同結點上。
[if !supportLists]1）[endif]精確定義
D-DBS是一個數據集合，這些數據，分布在計算機網絡的不同計算機上，網絡中每個結點具有獨立處理的能力，可以執行局部應用，同時每個結點也能通過網絡通訊支持全局應用。分布式數據庫強調場地自治性（局部應用）以及自治場地之間的協作性（全局應用）
1.3.4.2體系結構
1）G-外模式：全局應用的用戶視圖；
2）G-概念模式：定義D-DBS中數據的整體邏輯結構，數據如同沒有分布一樣；
3）分片模式：每一個關系可以分為若干互不相交的部分，每一部分稱為一個片段；
4）分布模式：定義片段的存放地點。
圖4分布式體系結構
1.4數據挖掘和信息檢索
1.4.1基本定義
[if !supportLists]1）[endif]信息檢索
信息檢索（Information
Retrieval）是用戶進行信息查詢和獲取的主要方式，是查找信息的方法和手段。狹義的信息檢索僅指信息查詢（Information Search）。即用戶根據需要，采用一定的方法，借助檢索工具，從信息集合中找出所需要信息的查找過程。廣義的信息檢索是信息按一定的方式進行加工、整理、組織并存儲起來，再根據信息用戶特定的需要將相關信息準確的查找出來的過程。又稱信息的存儲于檢索。一般情況下，信息檢索指的就是廣義的信息檢索。
[if !supportLists]2）[endif]數據挖掘
數據挖掘一般是指從大量的數據中通過算法搜索隱藏于其中信息的過程。數據挖掘通常與計算機科學有關，并通過統計、在線分析處理、情報檢索、機器學習、專家系統（依靠過去的經驗法則）和模式識別等諸多方法來實現上述目標。
[if !supportLists]1.4.2[endif]應用分類
[if !supportLists]1）[endif]信息檢索：
個人信息檢索：個人相關信息的組織、整理、搜素等。桌面搜索、個人信息管理、個人數字記憶；企業級信息檢索：在企業內容文檔的組織、管理、搜索等。企業級信息檢索是內容管理的重要組成部分；Web信息檢索：在超大規模數據集上的檢索；移動搜索、產品搜索、專利搜索、廣告推薦、社會網絡分析、消費行為分析、網絡評論分析、SEO營銷。
[if !supportLists]2）[endif]數據挖掘：
大小公司對數據挖掘的需求有50多個方面：數據統計分析；預測預警模型；數據信息闡釋；數據采集評估；數據加工倉庫；品類數據分析；銷售數據分析；網絡數據分析；流量數據分析等等。
2數據庫的分類
2.1商用數據庫VS開源數據庫
DB-Engines中目前有331個不同的數據庫管理系統，其中開源數據庫有165個，商業數據庫有166個，雙方可謂旗鼓相當見圖5開源VS商用走勢圖。
圖5開源VS商用走勢圖
2.2數據庫切分
2.2.1切分概述
2.2.1.1 OLTP和OLAP
聯機事務處理（OLTP）也稱為面向交易的處理系統，其基本特征是原始數據可以立即傳送到計算機中心進行處理，并在很短的時間內給出處理結果。
聯機分析處理（OLAP）是指通過多維的方式對數據進行分析、查詢和報表，可以同數據挖掘工具、統計分析工具配合使用，增強決策分析功能。
對于二者的區別見表1。
表1OLAP和OLTP對比
OLTPOLAP
系統功能日常交易處理統計、分析、報表
DB設計面向實時交易類應用面向統計分析類應用
數據處理當前的、最新的細節、二維的分立的歷史的、聚集的、多維的、集成的、統一的
實時性實時讀寫要求高實時讀寫要求低
事務強一致性弱事務
分析要求低、簡單高、復雜
2.2.1.2關系型數據庫和非關系型數據庫（NoSQL）
針對上面兩類系統有多種技術實現方案，存儲部分的數據庫主要分為兩大類：關系型數據庫和NoSQL。
關系型數據庫，是建立在關系模型基礎上的數據庫，其借助于集合代數等數學概念和方法來處理數據庫中的數據。主流的Oracle、DB2、MS SQL Server和mysql都屬于這類傳統的數據庫。
NoSQL數據庫，全稱為Not Only SQL，意思就是適用關系型數據庫的時候使用關系型數據庫，不適用的時候也沒必要非使用關系型數據庫不可，可以考慮使用更加合適的數據存儲。主要為臨時性鍵值存儲、永久性鍵值、面向文檔的數據庫、面向列的數據庫。
二者各自特點見表2關系數據庫與非關系數據庫對比。
表2關系數據庫與非關系數據庫對比
關系型數據庫NoSQL
特點數據關系模型基于關系模型，結構化存儲，完整約束；基于二維表及其之間的聯系，需要連接、并、交、差、除等數據操作；采用結構化的查詢語言做數據讀寫；操作需要數據的一致性，需要事務甚至是強一致性非結構化的存儲
基于多維關系模型
具有特有的使用場景
優點保持數據的一致性（事務處理）
可以進行join等復雜查詢
通用化，技術成熟
高并發，大數據下讀寫能力較強；基本支持分布式，易于擴展，可伸縮；簡單，弱結構化
缺點數據讀寫必須經過SQL解析、大量數據，高并發下讀寫性能不足；對數據做讀寫，或修改數據結構需要加鎖，影響并發操作；無法適應非結構化存儲；擴展困難；昂貴、復雜。Join等復雜操作能力較弱；事務支持較弱；通用性差；無完整約束復雜業務場景支持較差。
2.2.1.3何為數據切分
簡單來說，就是指通過某種特定條件，將我們存放在同一個數據庫中的數據分散存放到多個數據庫中，以達到分散單臺設備負載的效果。
數據的切分根據其切分規則的類型，可以分為兩種切分模式。一種是按照不同的表來切分到不同的數據庫上，這種切分可以稱之為數據的垂直切分；另外一種則是根據數據的邏輯關系，將同一個表中的數據按照某種條件拆分到多臺數據庫上，這種切分稱之為水平切分。
關于數據庫的垂直切分和水平切分將在第3.1.5和3.16節進行詳細介紹。
2.3數據庫分類
數據庫通常分為層次式數據庫、網絡式數據庫和關系式數據庫三種。而不同的數據庫是按不同的數據結構來聯系和組織的。而在當今的互聯網中，最常見的數據庫模型主要是兩種，即關系型數據庫和非關系型數據庫，見圖6數據庫簡單劃分。
圖6數據庫簡單劃分
數據庫按其數據模型詳細分類、使用情況和排名情況見圖7數據庫分類。
圖7數據庫分類
2.3.1關系型數據庫(Relational DBMS)
關系數據庫，是建立在關系模型基礎上的數據庫，借助于集合代數等數學概念和方法來處理數據庫中的數據。簡單來說，關系模型指的就是二維表格模型，而一個關系型數據庫就是由二維表及其之間的聯系所組成的一個數據組織。
關系數據庫分為兩類：一類是桌面數據庫，例如Access、FoxPro和dBase等；另一類是客戶/服務器數據庫，例如SQL
Server、Oracle和Sybase等。一般而言，桌面數據庫用于小型的、單機的應用程序，它不需要網絡和服務器，實現起來比較方便，但它只提供數據的存取功能。客戶/服務器數據庫主要適用于大型的、多用戶的數據庫管理系統，應用程序包括兩部分：一部分駐留在客戶機上，用于向用戶顯示信息及實現與用戶的交互；另一部分駐留在服務器中，主要用來實現對數據庫的操作和對數據的計算處理。
表3關系型數據庫是DB-Engines提供的關系型數據庫的排名情況，表中按數字為先后進行排序，并對相應數據庫做了最簡要的介紹。由表可知：現在主流的數據庫主要以Oracle、mysql和sql Server為主，但只有mysql開源（獲取排名時間2017年6月）。
表3關系型數據庫
排名簡述
1、OracleOracle Database，又名Oracle RDBMS，或簡稱Oracle。是甲骨文公司的一款關系數據庫管理系統。
2、MySqlMySQL是一種開放源代碼的關系型數據庫管理系統（RDBMS）
3、Microsoft SQL ServerSQL Server是Microsoft公司推出的關系型數據庫管理系統
4、PostgreSQLPostgreSQL是一個自由的對象-關系數據庫服務器(數據庫管理系統)
5、DB2IBM DB2是美國IBM公司開發的一套關系型數據庫管理系統
6、Microsoft AccessMicrosoft Office Access是微軟把數據庫引擎的圖形用戶界面和軟件開發工具結合在一起的一個數據庫管理系統。
7、SQLiteSQLite，是一款輕型的數據庫，是遵守ACID的關系型數據庫管理系統
8、TeradataTeradata天睿公司數據庫，Teradata數據倉庫配備性能最高、最可靠的大規模并行處理(MPP)平臺，能夠高速處理海量數據。（大數據，價格不菲）
9、SAP Adaptive ServerAdaptive Server IQ是sybase公司(現已被SAP收購)一個數據庫產品
10、FileMakerFileMaker是一個關于數據庫的應用軟件，它因易于使用且有不要求使用另外的第三方應用程序就能動態地為網頁服務的能力而著稱。
11、MariaDBMariaDB數據庫管理系統是MySQL的一個分支，主要由開源社區在維護，采用GPL授權許可MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能輕松成為MySQL的代替品。
12、Hivehive是基于Hadoop的一個數據倉庫工具，可以將結構化的數據文件映射為一張數據庫表，并提供簡單的sql查詢功能，可以將sql語句轉換為MapReduce任務進行運行。
…省略
2.3.2文檔存儲數據庫（Document stores）
2.3.2.1定義
文檔數據庫區別于傳統的其它數據庫，它是用來管理文檔。在傳統的數據庫中，信息被分割成離散的數據段，而在文檔數據庫中，文檔是處理信息的基本單位。文檔可以很長、很復雜、可以無結構，與字處理文檔類似。一個文檔相當于關系數據庫中的一條記錄。
2.3.2.2與文件系統區別
首先，文件系統中的文件基本上對應于某個應用程序。當不同的應用程序所需要的數據有部分相同時，也必須建立各自的文件，而不能共享數據，而文檔數據庫可以共享相同的數據。因此，文件系統比文檔數據庫數據冗余度更大，更浪費存儲空間，且更難于管理維護。其次，文件系統中的文件是為某一特定應用服務的，所以，要想對現有的數據再增加一些新的應用是很困難的，系統不容易擴充。數據和程序缺乏獨立性。而文檔數據庫具有數據的物理獨立性和邏輯獨立性，數據和程序分離。
2.3.2.3與關系型數據庫的區別
文檔數據庫也不同于關系數據庫,關系數據庫是高度結構化的,而Notes的文檔數據庫允許創建許多不同類型的非結構化的或任意格式的字段,與關系數據庫的主要不同在于,它不提供對參數完整性和分布事務的支持,但和關系數據庫也不是相互排斥的,它們之間可以相互交換數據,從而相互補充、擴展。
2.3.2.4常用的文檔存儲數據庫
表4文檔存儲類數據庫
1、MongoDBMongoDB是一個介于關系數據庫和非關系數據庫之間的產品，是非關系數據庫當中功能最豐富，最像關系數據庫的。
可以存儲比較復雜的數據類型；
最大的特點是他支持的查詢語言非常強大。
2、Amazon DynamoDBAmazon DynamoDB是一項完全托管的NoSQL數據庫服務，提供快速而可預測的性能，能夠實現無縫擴展。
Amazon DynamoDB可自動將表的數據和流量分布到足夠多的服務器中，以處理客戶指定的請求容量和數據存儲量，同時保持一致的性能和高效的訪問。
3、CouchbaseCouchbase是一個具有高性能、可擴展性和可 用性強的數據庫引擎。它可以讓開發人員通過NoSQL的鍵值存儲（二進制或者JSON）或者使用N1QL的形式對數據進行操作（N1QL是非常類似于SQL的一種語法操作JSON數據的方式）。
2.3.3鍵值存儲（key-value stores）
數據按照鍵值對的形式進行組織、索引和存儲。KV存儲非常適合不涉及過多數據關系業務關系的業務數據，同時能有效減少讀寫磁盤的次數，比SQL數據庫存儲擁有更好的讀寫性能。
1、Redis（高性能的key-value數據庫）Redis與其他key - value緩存產品有以下三個特點：
Redis支持數據的持久化，可以將內存中的數據保存在磁盤中，重啟的時候可以再次加載進行使用。
Redis不僅僅支持簡單的key-value類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。
Redis支持數據的備份，即master-slave模式的數據備份。
2、MemcachedMemcached是一個高性能的分布式內存對象緩存系統，用于動態Web應用以減輕數據庫負載。
2.3.4圖形數據庫
圖形數據庫是NoSQL數據庫的一種類型，它應用圖形理論存儲實體之間的關系信息。圖形數據庫是一種非關系型數據庫，它應用圖形理論存儲實體之間的關系信息。最常見例子就是社會網絡中人與人之間的關系。關系型數據庫用于存儲“關系型”數據的效果并不好，其查詢復雜、緩慢、超出預期，而圖形數據庫的獨特設計恰恰彌補了這個缺陷。
在一個圖形數據庫中，最主要的組成有兩種，結點集和連接結點的關系（有的也稱泡泡和箭頭）。結點集就是圖中一系列結點的集合，比較接近于關系數據庫中所最常使用的表，而關系則是圖形數據庫所特有的組成。
表5圖形數據庫
1、Neo4jNeo4j是一個高性能的,NOSQL圖形數據庫，它將結構化數據存儲在網絡上而不是表中。它是一個嵌入式的、基于磁盤的、具備完全的事務特性的Java持久化引擎，但是它將結構化數據存儲在網絡(從數學角度叫做圖)上而不是表中。
2、Microsoft Azure Cosmos DBAzure Cosmos DB是一個全球分布式數據庫服務，使用它可以跨任意數量的地理區域，根據全面的SLA，靈活、獨立地縮放吞吐量與存儲。 使用Cosmos DB可通過一系列流行API和編程模型開發文檔、鍵/值或圖形數據庫。
3、OrientDBOrientDB是兼具文檔數據庫的靈活性和圖形數據庫管理鏈接能力的可深層次擴展的文檔-圖形數據庫管理系統。
4、TitanTitan是一個在服務器集群搭建的分布式的圖形數據庫，特別為存儲和處理大規模圖形而優化
2.3.5列存儲（Wide column stores）
在SQL Server里，Page是數據存儲的基本單位，而數據行是實際數據的存儲單位，它們從Page Header之后就開始依次存儲在Page上。這種按行在Page上存儲記錄的方式就是行存儲。當數據是按單列而不是多行進行連續存儲時，就是所謂的列存儲。（列存儲的數據庫更適合（聯機分析處理）OLAP；行存儲的數據庫更適合（聯機事務處理過程）OLTP）。
表6列式存儲
1、CassandraCassandra是一個來自Apache的分布式數據庫，具有高度可擴展性，可用于管理大量的結構化數據。它提供了高可用性，沒有單點故障。
2、HbaseHBase是一個分布式的、面向列的開源數據庫，HBase不同于一般的關系數據庫，它是一個適合于非結構化數據存儲的數據庫。
3、Microsoft Azure Cosmos DB上面簡要介紹過。
4、AccumuloAccumulo是一個基于谷歌Big Table、采用鍵值的分布式數據存儲。
2.4數據庫選型
2.4.1五個要素
2.4.1.1開發要求
實現基于關系型數據庫的應用可以選擇傳統的主流品牌，這些數據庫產品有著很成熟的關系技術以及廣泛的應用資源。但是,如果實現的是基于面向對象技術的應用、又或是數據結構更為復雜時，不妨考慮目前一些公司推出的所謂后關系數據庫。它所代表的正好是關系數據庫和面向對象技術的融合，以多維數據引擎作為核心，從根本上支持復雜的對象存儲及主流的二維表，同時也已經配備了功能強大的應用服務引擎，可作對象邏輯操作的平臺。它的出現已經為傳統數據庫領域帶來了沖擊，而在面向對象數據庫方面更是廣受歡迎。
2.4.1.2性能/成本
測量數據庫性能最常見的方法是TPC基準。TPC定義了數據庫方案、數據量以及SQL查詢。它指出，在這一數據庫版本、平臺、操作系統版本，以及這一內存和磁盤技術/容量條件下，每項事務的成本是多少－其中的事務可以是TPC測試中定義的任何數據庫操作。
理論上來講，這類基準旨在提供不同產品間的比較值，而在現實中，方案定義可能無法準確反映您正在挑選的技術的使用的本質情況。其次，所有技術廠商發布的TPC基準都會超過以前發布的結果。這樣，TPC基準更大程度上反映的是為解決問題而投入的內存和CPU量，而不是數據庫性能的任何真實表現。
2.4.1.3數據庫的運行和管理
數據庫管理涉及以下問題：
表7數據庫管理涉及的問題
操作任務備份、故障切換、災難恢復等
整理系統分段、存檔
訪問控制定義、監控
性能保持系統在線和優化運行
數據庫方案變更更改數據庫結構、重新索引、數據庫同步
2.4.1.4可升級性
隨著對數據庫應用軟件使用的不斷增加，很可能某一時刻當前的硬件配置就不夠用了，這時您就需要對硬件進行檢查。升級可以朝兩個方向發展：垂直升級（使用更大/更多的處理器）和水平升級（使用與當前平臺同一規格的更多的計算機/處理器）。
應考慮到的問題：業務邏輯能否和數據分離；業務邏輯能否拆分；數據庫能否分段；
執行上述任一操作后對性能有多少提升；如果當前的配置成倍增長，那么性能是否會成倍增長；高容量升級是否會引發直接、間接或者隱藏的成本。
2.3.2商用主流數據庫
表8商用數據庫優缺點
數據庫優點缺點
Oracle[if !supportLists]1）[endif]廣泛的支持選項；
[if !supportLists]2）[endif]可在多平臺上運行；
[if !supportLists]3）[endif]良好的可擴展性；
[if !supportLists]4）[endif]非常穩定；
[if !supportLists]5）[endif]針對大型數據集的速度最快；
[if !supportLists]6）[endif]強大的第三方應用程序支持
1）對管理員要求較高(經過培訓認證)；
2）價格非常昂貴3）授權方式復雜4）升級過程復雜
DB21）可在多平臺上運行；
2）良好的支持選項；
3）可以輕松地進行擴容；
4）非常穩定；
5）極佳的壓縮特性
1）價格非常昂貴；
2）授權方式復雜；
3）有限的培訓選項；
4）有限的附加工具
SQL Server1）出色的維護與開發工具；
2）廣泛的支持選項；
3）非常穩定；
4）完整的解決方案，無需添加其他選；
5）大多數情況下可以提供最低的TCO；
6）強大的第三方應用程序支持；
7）與Windows操作系統的緊密整合
1）只能運行在Windows平臺；
2）功能不如DB2與Oracle強大；
3）價格相對昂貴
4）需要手動管理
2.3.3開源主流數據庫
表9開源數據庫優缺點
數據庫優點缺點
MySql快速、多線程、多用戶；
支持不同的操作系統；靈活而又安全的權限和口令系統；支持ODBC for
Windows；擁有一個非常快速而且穩定的基于線程的內存分配系統，可以持續使用面不必擔心其穩定性。
MySQL不完全支持陌生的關鍵詞；使用myisam配置，如果你不慎損壞數據庫，結果可能會導致所有的數據丟失；
MongoDB文件驗證；
加密存儲引擎；
具有內存存儲引擎（beta）的實時應用程序；
減少主要故障恢復的時間；
不適合需要處理復雜事務的應用程序；不是傳統應用程序的替代品；年輕的解決方案：軟件更新快
PostgreSQL創建自定義數據類型和查詢方法；框架允許定義和創建自定義數據類型；以十幾種編程語言運行存儲過程；提供不同的排序和搜索算法MVCC系統需要定期的“清理（vacuuming）”；
高交易率環境中的問題；
由強大的社區發展起來的
3數據庫設計
3.1數據庫架構演變
3.1.1單主機
最開始網站一般都是由典型的LAMP架構演變而來的，一般都是一臺linux主機，一臺apache服務器，php執行環境以及mysql服務器，一般情況下，這些都在一臺虛擬主機上，簡稱單主機模式。
單主機模式缺點：1）web服務器和mysql服務器公用一臺主機，共享硬件資源，可能存在某一方資源征用太大，導致整個應用產生瓶頸；2）當業務增長之后，沒有辦法做到橫向擴展；3）容錯性太差，一旦主機存在問題，整個應用不可用。
3.1.2獨立主機
隨著業務的發展，可以把mysql服務器和web服務器主機分開，分別部署，就是獨立主機模式。
獨立主機模式下，web服務器和mysql不再共享硬件資源，分別部署，增加了容錯性。如果只是mysql服務器故障，那么對于web上不訪問服務器的應用是不會受到影響的。而且web服務器可以做到橫向擴展，如果web服務器性能不夠，可以增加多臺web服務器，進行負載均衡，分散web服務器的壓力。
獨立主機模式的缺點：1）可擴展性問題：雖然web服務器可以做到橫向擴展，但是mysql服務器是沒有辦法做到橫向擴展的；2）可用性問題：mysql服務器存在單點問題，一旦mysql服務器宕機，對影響的影響很大；3）性能問題：單臺mysql服務器能夠支撐的服務是有限的。
3.1.3讀寫分離
隨著業務的不斷發展，數據庫的壓力會越來越大，單數據庫慢慢的就不能滿足需求了，一些網站對數據實時性要求不高，就會慢慢發展讀寫分離模式，對于普通的查詢請求，分配到讀庫（也可以說是備庫），對于修改請求，在主庫上完成。對于讀庫，由于是無狀態的，可以做到橫向擴展。對于寫庫，還只能是單臺主機。
圖8讀寫分離
這種模式其實有限制的，要根據業務的類型來考慮。主庫的數據是最新的，但是同步到讀庫會有時延，所以應用必須能夠容忍短暫的不一致性。對于一致性要求非常高的場景是不適合的。
實現層面可能出現的問題：1）主從數據庫之間的數據同步問題；2）應用對于數據源的選擇問題。
解決思路：1）我們可以使用MYSQL自帶的master+slave的方式實現主從復制；2）采用第三方數據庫中間件，例如mycat。
這種模式的存在的問題：
1）可擴展性：雖然讀庫可以做到橫向擴展，但是寫庫還不行，讀庫不能夠橫向擴展；
2）可用性：讀庫成為單點，一旦故障，影響所有的寫操作業務；
3）主庫無法承受數據寫入量時怎么辦。
3.1.4讀庫緩存
隨著訪問量的增加，逐漸出現了許多用戶訪問同一部分內容的情況，對于這些比較熱門的內容，沒必要每次都從數據庫讀取。我們可以使用緩存技術，例如可以使用google的開源緩存技術guava或者使用memcacahe作為應用層的緩存，也可以使用redis作為數據庫層的緩存。
另外，在某些場景下，關系型數據庫并不是很適合，例如我想做一個“每日輸入密碼錯誤次數限制”的功能，思路大概是在用戶登錄時，如果登錄錯誤，則記錄下該用戶的IP和錯誤次數，那么這個數據要放在哪里呢？假如放在內存中，那么顯然會占用太大的內容；假如放在關系型數據庫中，那么既要建立數據庫表，還要簡歷對應的java bean，還要寫SQL等等。而分析一下我們要存儲的數據，無非就是類似{ip:errorNumber}這樣的key:value數據。對于這種數據，我們可以用NOSQL數據庫來代替傳統的關系型數據庫。
優點：減輕數據庫的壓力；大幅度提高訪問速度。
缺點：需要維護緩存服務器，提高了編碼的復雜性。
3.1.5業務垂直拆分
隨著業務的發展，一臺寫庫顯然不能夠滿足高并發的情況，但是考慮到寫庫是有狀態的，不能簡單的橫向擴展，假設有兩臺寫庫，那么隨機更新一臺的數據，就會導致另一方數據存在問題。出現一種數據兩個不同版本，顯然是無法接受的。在寫庫上，可以考慮按照業務來垂直進行分庫。所謂垂直就是從業務角度來看，將關聯性不強的數據拆分到不同的instance上，從而達到消除瓶頸的目標。
圖9數據庫的垂直拆分
在按照業務垂直拆分以后，系統在性能上有了很高的提升，只需要把業務上分成垂直部分，分的越細，系統的整體擴展能力就越強。
這種模式下，存在以下幾個問題：
[if !supportLists]1）[endif]可用性：假設一個完整的業務流程P訪問的數據庫被拆分為A、B、C、D、E五個庫，假設每個寫庫可用性為99%，那么這個業務流程P的可用性就為99%*99%*99%*99%*99%=95%，庫拆分的越多，對系統的整體可用性挑戰就越大；
2）性能：由于垂直業務庫每個庫的負載可能不一樣，假設交易庫負載很高，一個交易寫庫肯定不能夠滿足需求，這個情況下，交易庫成為整個系統的瓶頸；
3）可擴展性：單個節點的可擴展性沒有得到改善，交易庫不能單獨進行擴展。
3.1.6單業務庫水平、垂直拆分
在上一種情況，假設交易庫是整個系統的瓶頸，需要對交易庫進行單獨的擴展。可以考慮交易的水平拆分或者垂直拆分，有可能同時進行兩種方式拆分。
水平拆分一般根據業務無關的關鍵字進行拆分，拆分結果是任何實例都只有全量的1/n的數據，橫向擴展性比較好，但是對于查詢的挑戰比較大。
垂直拆分一般根據業務來拆分，但是可能導致數據不均勻以及拆分不夠靈活。對于查詢來說，相對比較友好，垂直拆分拆完的結果是在一個實例上是擁有全量數據的。
圖10水平拆分
以交易庫為例，可以先交易的類型進行業務上的垂直分庫，在按照訂單號進行水平分庫。
假設可以分成M*N個庫，那么單個庫的故障會影響1/M*N的交易，但是假設每個庫可用性為99%，那么交易數據庫故障概率為(99%)的(M+N)次方，如果數據庫拆分的越多，發生單個數據庫故障概率就越高。
這種方式存在的問題：1）雖然單個節點故障影響的用戶很少，但是整體可用會降低；2）數據庫管理上帶來復雜的挑戰，假設交易庫表結構變更，需要執行M×N次腳本變更；3）由于發生單個數據庫故障的概率比較高，DBA需經常維護；4）開發和測試成本會變高，查詢非常復雜；5）單個節點如果發生故障，沒有失敗檢測并且切換機制；6）分庫還不能在水平方向做到無限擴展，我們的算法是事先分配M個庫，如果添加一個庫基本上不可行。
解決方案：
[if !supportLists]1）[endif]針對垂直拆分查詢:在應用層盡量避免跨數據庫事務，或者使用中間件進行跨庫join；
[if !supportLists]2）[endif]針對水平拆分查詢：使用中間件的分頁查詢方案。
3.2數據庫設計的思路
3.2.1初期（讀寫分離）
讀寫分離簡單的說是把對數據庫讀和寫的操作分開對應不同的數據庫服務器，這樣能有效地減輕數據庫壓力，也能減輕io壓力。主數據庫提供寫操作，從數據庫提供讀操作。
3.2.1.1讀寫分離整體架構
1）基于后端MySql的主從數據庫同步利用MyCat實現的讀寫分離架構見圖11讀寫分離架構。這種架構適用于讀遠高于寫，并且實時性不高的場景。（注：主從架構是一種用于數據容錯的高可用性解決方案，而不是一種處理高并發壓力的解決方案，但是加入MyCat可以）
圖11讀寫分離架構
2）從服務器的IO線程從主服務器獲取二進制日志，并在本地保存為中繼日志，然后通過SQL線程來在從上執行中繼日志中的內容，從而使從庫和主庫保持一致。
圖12mysql數據庫同步
3.2.2讀寫分離+數據拆分+負載均衡
（待更新）；
4數據庫性能指標及測試
4.1衡量性能的關鍵性指標
數據庫需要著重關注的六個性能指標：數據庫性能指標\衡量企業應用數據庫性能的6大指標 -數據庫 - ITeye資訊.htm
文中詳細介紹了事務、查詢性能、用戶和查詢沖突、容量、配置。
4.2數據庫壓測工具
4.2.1Sysbench
sysbench是一個模塊化的、跨平臺、多線程基準測試工具，主要用于評估測試各種不同系統參數下的數據庫負載情況。
主要包括以下幾種方式的測試：
1、cpu性能
2、磁盤io性能
3、調度程序性能
4、內存分配及傳輸速度
5、POSIX線程性能
6、數據庫性能(OLTP基準測試)
目前sysbench主要支持mysql,pgsql,oracle這3種數據庫。
測試示例網址：基準測試工具之sysbench
4.2.2Tpcc-mysql
TPC(Tracsaction
Processing Performance Council)事務處理性能協會是一個評價大型數據庫系統軟硬件性能的非盈利的組織,TPC-C是TPC協會制定的，用來測試典型的復雜OLTP系統的性能。Tpcc-mysql是percona基于tpcc衍生出來的產品，專用于mysql基準測試，其源碼放在bazaar上，因此需要先安裝bazaar客戶端。值得說明的是Tpcc-mysql包括五個處理邏輯，是比較貼近電商平臺業務的一個壓測工具New-Order :新訂單Payment :支付Order-Status :訂單查詢Delivery:發貨Stock-Level
:庫存。
項目地址：源碼地址
測試示例：tpcc使用結果示例
4.2.3mysqlslap
mysqlslap是從5.1.4版開始的一個MySQL官方提供的壓力測試工具。通過模擬多個并發客戶端訪問MySQL來執行壓力測試，同時提供了比較詳細的數據性能報告。并且能很好的對比多個存儲引擎在相同環境下的并發壓力性能差別。通過mysqlslap–help可以獲得可用的選項。
官網地址：mysqlslap官網
測試示例：mysqlslap使用實例
4.2.4tcpcopy
TCPCOPY是一個tcp流量的實時復制工具，其1.0版本由網易工程師@tcpcopy開發和維護。一般用來將生產環境的線上流量實時復制到測試環境進行測試。例如新系統上線前，如果我們希望進行一些基本的壓力測試，那么我們可以直接利用tcpcopy來復制線上的流量過來對系統進行測試，這樣的好處是測試數據接近真實水平，且實施起來相對簡單。下面我們將通過一個真實的使用案例，來簡單介紹tcpcopy的基本使用方法。我們假定讀者對tcp以及路由相關基本知識有一定了解。
項目地址：項目源碼地址
4.2.5Mydbtest
樓方鑫的一款壓測工具，可以根據業務模型配置業務的sql，利用線上的數據備份進行壓測的一款工具。具有免安裝，上手快，而且可以針對業務sql做定制化壓測等優點
測試示例：Mydbtest測試實例
5數據庫優化
數據庫的優化一方面是找出系統的瓶頸，提高數據庫的整體性能，另一方面是設計合理的結構和參數調整，以提高用戶的訪問速度；同時還要盡可能節省系統資源，以便系統提供更大負荷的服務。詳見：數據庫五個方面的性能優化
圖13計算機性能指標
從圖13可以看到基本上每種設備都有兩個指標：延時（響應時間）：表示硬件的突發處理能力；帶寬（吞吐量）：代表硬件持續處理能力。
根據數據庫知識，我們可以列出每種硬件主要的工作內容：1)CPU及內存：緩存數據訪問、比較、排序、事務檢測、SQL解析、函數或邏輯運算；2)網絡：結果數據傳輸、SQL請求、遠程數據庫訪問（dblink）；3)硬盤：數據訪問、數據寫入、日志記錄、大數據量排序、大表連接。
根據當前計算機硬件的基本性能指標及其在數據庫中主要操作內容，可以整理出如下圖所示的性能基本優化法則：1）減少數據訪問（減少磁盤訪問）；2）返回更少數據（減少網絡傳輸或磁盤訪問）；3）減少交互次數（減少網絡傳輸）；4）減少服務器CPU開銷（減少CPU及內存開銷）；5）利用更多資源（增加資源）；6）數據庫備份；7）數據庫安全。
優化成本見表10硬件優化成本。
表10硬件優化成本
優化法則性能提升效果優化成本
減少數據訪問1~1000低
返回更少數據1~100低
減少交互次數1~20低
減少服務器CPU開銷1~5低
利用更多資源@~10高
5.1減少數據訪問
5.1.1創建并正確使用索引
索引會大大增加表記錄的DML(INSERT,UPDATE,DELETE)開銷，正確的索引可以讓性能提升100，1000倍以上，不合理的索引也可能會讓性能下降100倍，因此在一個表中創建什么樣的索引需要平衡各種業務需求。
常見的索引有B-TREE索引、位圖索引、全文索引，位圖索引一般用于數據倉庫應用，全文索引由于使用較少，這里不深入介紹。B-TREE索引包括很多擴展類型，如組合索引、反向索引、函數索引等等。
5.1.2組合索引
有些時候，我們只是訪問表中的幾個字段，并且字段內容較少，我們可以為這幾個字段單獨建立一個組合索引，這樣就可以直接只通過訪問索引就能得到數據，一般索引占用的磁盤空間比表小很多，所以這種方式可以大大減少磁盤IO開銷。
如：select id,name fromcompany where type='2';
如果這個SQL經常使用，我們可以在type,id,name上創建組合索引：
createindex my_comb_index on company(type,id,name);
有了這個組合索引后，SQL就可以直接通過my_comb_index索引返回數據，不需要訪問company表。
注：性能優化是無止境的，當性能可以滿足需求時即可，不要過度優化。
5.1.3優化SQL執行計劃
所謂執行計劃，顧名思義，就是對一個查詢任務，做出一份怎樣去完成任務的詳細方案。舉個生活中的例子，我從珠海要去英國，我可以選擇先去香港然后轉機，也可以先去北京轉機，或者去廣州也可以。但是到底怎樣去英國劃算，也就是我的費用最少，這是一件值得考究的事情。同樣對于查詢而言，我們提交的SQL僅僅是描述出了我們的目的地是英國，但至于怎么去，通常我們的SQL中是沒有給出提示信息的，是由數據庫來決定的。
基于代價的優化器在絕大多數情況下它會選擇正確的優化器，減輕了DBA的負擔。但有時它也聰明反被聰明誤，選擇了很差的執行計劃，使某個語句的執行變得奇慢無比。此時就需要DBA進行人為的干預，告訴優化器使用我們指定的存取路徑或連接類型生成執行計劃，從而使語句高效的運行。例如:對于一個特定的語句，執行全表掃描要比執行索引掃描更有效，則我們可以指示優化器使用全表掃描。
關于執行計劃的解釋詳見：http://blog.chinaunix.net/uid-22864942-id-375762.html
5.2返回更少數據
5.2.1數據分頁處理
5.2.1.1客戶端分頁
將數據從應用服務器全部下載到本地應用程序或瀏覽器，在應用程序或瀏覽器內部通過本地代碼進行分頁處理
優點：編碼簡單，減少客戶端與應用服務器網絡交互次數
缺點：首次交互時間長，占用客戶端內存
適應場景：客戶端與應用服務器網絡延時較大，但要求后續操作流暢，如手機GPRS，超遠程訪問（跨國）等等。
5.2.1.2應用服務器分頁
將數據從數據庫服務器全部下載到應用服務器，在應用服務器內部再進行數據篩選。以下是一個應用服務器端Java程序分頁的示例：
Listlist=executeQuery(“select * from employee order by id”);
Int count=list.size();
ListsubList= list.subList(10, 20);
優點：編碼簡單，只需要一次SQL交互，總數據與分頁數據差不多時性能較好。
缺點：總數據量較多時性能較差。
適應場景：數據庫系統不支持分頁處理，數據量較小并且可控。
5.2.1.3數據庫SQL分頁
采用數據庫SQL分頁需要兩次SQL完成
一個SQL計算總數量
一個SQL返回分頁后的數據
優點：性能好
缺點：編碼復雜，各種數據庫語法不同，需要兩次SQL交互。
5.2.2返回所需字段
通過去除不必要的返回字段可以提高性能，例：
調整前：select * fromproduct where company_id=?;
調整后：select id,namefrom product where company_id=?;
優點：1、減少數據在網絡上傳輸開銷；2、減少服務器數據處理開銷；3、減少客戶端內存占用；4、字段變更時提前發現問題，減少程序BUG；5、如果訪問的所有字段剛好在一個索引里面，則可以使用純索引訪問提高性能。
缺點：增加編碼工作量
5.3減少交互次數
具體包括：batch DML；In List；設置Fetch Size；使用存儲過程；優化業務邏輯；使用ResultSet游標處理記錄等方法。
5.4減少服務器CPU開銷
具體的方法包括：使用綁定變量；合理使用排序；較少比較操作；大量復雜運算在客戶端處理等等。
5.5利用更多資源
具體方法包括利用客戶端多進程訪問；數據庫并行處理等等。
6數據庫安全
6.1定義
數據庫安全包含兩層含義：
第一層是指系統運行安全，系統運行安全通常受到的威脅如下，一些網絡不法分子通過網絡，局域網等途徑通過入侵電腦使系統無法正常啟動，或超負荷讓機子運行大量算法，并關閉cpu風扇，使cpu過熱燒壞等破壞性活動；
第二層是指系統信息安全，系統安全通常受到的威脅如下，黑客對數據庫入侵，并盜取想要的資料。數據庫系統的安全特性主要是針對數據而言的，包括數據獨立性、數據安全性、數據完整性、并發控制、故障恢復等幾個方面。
6.2常見問題及解決措施
6.2.1錯誤地部署
開發者在部署過程中的粗心大意會很容易讓數據庫陷入危難之中。在現實中，有些公司會意識到優化搜索引擎對于業務取得成功的重要性，但只有對數據庫進行排序，SEO才可以很好地對其優化。盡管功能性測試對性能有一定的保證，但測試并不能預料數據庫會發生的一切。因此，在進行完全部署之前，對數據庫進行全面的檢查是非常有必要的。
6.2.2數據泄露
你可以把數據庫當做后端設置的一部分，并將焦點轉移到保護互聯網安全上面，黑客很容易操縱數據庫中的網絡接口的，所以，為了避免這種現象發生，工程師在進行數據庫開發時，使用TLS或SSL加密通信平臺變的尤為重要。
6.2.3數據庫維護
你是否還記得2003年的SQL Slammer蠕蟲病毒，該病毒利用SQL Server的漏洞進行傳播，導致全球范圍內的互聯網癱瘓，中國也有80%以上網民受到影響。該蠕蟲的成功充分說明了保護數據庫安全是多么的重要。不幸的是，現實中很少有公司對他們的系統提供常規的補丁，因此，他們很容易遭受蠕蟲攻擊。
6.2.4數據庫備份信息被盜
通常，數據庫備份信息外泄一般會來自兩種途徑，一個是外部，一個是內部的。這是許多企業會經常遇到的問題，而解決這種問題的唯一方法是對檔案進行加密。
6.2.5濫用數據庫特性
據專家稱，每一個被黑客攻擊的數據庫都會濫用數據庫特性。例如，黑客可以在系統沒有執行的情況下隨意進入系統。解決這種問題的方法是移除不必要的工具。
6.2.6基礎設施薄弱
黑客一般不會馬上控制整個數據庫，相反，他們會選擇玩跳房子游戲來發現基礎架構中薄弱的地方，然后再利用該地方的優勢來發動字符串攻擊，直到抵達后端。
6.2.7缺乏隔離
給管理員和用戶進行職責劃分，如果他們試圖盜取數據，那么內部員工將會面臨更多的困難。所以，限制用戶數量，這樣黑客想控制整個數據庫就會有一定的挑戰。
6.2.8 SQL注入
一旦應用程序被注入惡意的字符串來欺騙服務器執行命令，那么管理員不得不收拾殘局，在保護數據庫上，這是一個主要問題。目前最佳的解決方案就是使用防火墻來保護數據庫網絡。
6.2.9密鑰管理不當
保證密鑰安全是非常重要的，但是加密密鑰通常存儲在公司的磁盤驅動器上，如果無人防守，那么您的系統會很容易遭受黑客攻擊。
6.2.10違法操作
開發人員可以利用追蹤信息/日志文本來查詢和解決此類問題。
7數據庫備份與還原
7.1數據庫備份類型
按照備份數據庫的大小數據庫備份有四種類型：
1）完全備份：這是大多數人常用的方式，它可以備份整個數據庫，包含用戶表、系統表、索引、視圖和存儲過程等所有數據庫對象。但它需要花費更多的時間和空間，所以，一般推薦一周做一次完全備份。
2）事務日志備份：事務日志是一個單獨的文件，它記錄數據庫的改變，備份的時候只需要復制自上次備份以來對數據庫所做的改變，所以只需要很少的時間。為了使數據庫具有魯棒性，推薦每小時甚至更頻繁的備份事務日志。
3）差異備份：也叫增量備份。它是只備份數據庫一部分的另一種方法，它不使用事務日志，相反，它使用整個數據庫的一種新映象。它比最初的完全備份小，因為它只包含自上次完全備份以來所改變的數據庫。它的優點是存儲和恢復速度快。推薦每天做一次差異備份。
4）文件備份：數據庫可以由硬盤上的許多文件構成。如果這個數據庫非常大，并且一個晚上也不能將它備份完，那么可以使用文件備份每晚備份數據庫的一部分。由于一般情況下數據庫不會大到必須使用多個文件存儲，所以這種備份不是很常用。
按照數據庫的狀態可分為三種：
1.冷備份，此時數據庫處于關閉狀態，能夠較好的保證數據庫的完整性。
2.熱備份，數據庫正處于運行狀態，這種方法依賴于數據庫的日志文件進行備份。
3.邏輯備份，使用軟件從數據庫中提取數據并將結果寫到一個文件上。
7.2數據庫恢復
1）還原完整備份
還原完整備份是指對數據庫完整備份文件進行還原，將數據庫還原到完備時的狀態。
2）還原完整備份+差異備份
該方式是將數據庫還原到差異備份的狀態。在還原完整備份后，可以繼續對目標數據庫還原差異備份，用于將差異備份保存的數據更新進入當前數據庫，使數據庫還原到差異備份時的狀態。
3）還原完整備份+差異備份+事務日志備份
該方式是將數據庫還原到事務日志備份時的狀態。在還原完整備份后，可以繼續對目標數據庫還原差異備份然后在繼續還原事務日志備份，用于將差異備份、事務日志備份保存的數據更新進入當前數據庫，使數據庫還原到事務日志備份時的狀態。
附錄一文件系統
所謂文件系統，它是操作系統中藉以組織、存儲和命名文件的結構。磁盤或分區和它所包括的文件系統的不同是很重要的，大部分應用程序都基于文件系統進行操作，在不同種文件系統上是不能工作的。
文件系統簡介
FAT16
FAT文件系統FAT文件系統最初用于小型磁盤和簡單文件結構的簡單文件系統。
磁盤文件系統文件系統就是在硬盤上存儲信息的格式。
FAT32文件系統FAT32文件系統提供了比FAT文件系統更為先進的文件管理特性
NTFS文件系統NTFS文件系統的設計目標就是用來在很大的硬盤上能夠很快地執行諸如：讀、寫和搜索這樣的標準文件操作，甚至包括像文件系統恢復這樣的高級操作
VFATVFAT是“擴展文件分配表系統”的意思，主要應用于在Windows 95中。它對FAT16文件系統進行擴展，并提供支持長文件名，文件名可長達255個字符
HPFS高性能文件系統。OS/2的高性能文件系統(HPFS)主要克服了FAT文件系統不適合于高檔操作系統這一缺點，HPFS支持長文件名，比FAT文件系統有更強的糾錯能力。
ext2Linux中使用最多的一種文件系統，因為它是專門為Linux設計，擁有最快的速度和最小的CPU占用率。
附錄二SqlServer性能指標
指標名稱指標描述指標范圍指標單位
1．SQL
Server中訪問方法（Access Methods）對象包含的性能計數器
全表掃描/秒
(Full Scans/sec)
指每秒全表掃描的數量。全表掃描可以是基本表掃描或全索引掃描。由于全表掃描需要耗費大量時間，因此全表掃描的頻率過高的話，會影響性能。如果該指標的值比1或2高，應該分析設計的查詢以確定是否確實需要全表掃描，以及SQL查詢是否可以被優化。次數/秒
2．SQL
Server中緩沖器管理器（Buffer
Manager）對象包含的性能計數器
緩沖區高速緩存命中率(BufferCache
Hit Ratio%）
指在緩沖區高速緩存中找到而不需要從磁盤中讀取的頁的百分比。該比率是緩存命中總次數與緩存查找總次數之比。經過很長時間后，該比率的變化很小。由于從緩存中讀取數據比從磁盤中讀取數據的開銷小得多，一般希望該比率高一些。該指標的值最好為90%或更高。通常可以通過增加SQL Server可用的內存數量來提高該指標的值。增加內存直到這指標的值持續高于90%，表示90%以上的數據請求可以從數據緩沖區中獲得所需數據。%
讀的頁/秒
(Page Reads/sec)
指每秒發出的物理數據庫頁讀取數。該指標主要考察數據庫從磁盤讀取數據的頻率。因為物理I/O會耗費大量時間，所以應盡可能地減少物理I/O以提高性能。該指標的值應盡可能的小。可以通過使用更大的數據高速緩存、智能索引、更高效的查詢或者改變數據庫設計等方法，以降低該指標的值。個數/秒
寫的頁/秒
(Page Writes/sec)
指每秒執行的物理數據庫寫的頁數。該指標主要考察數據庫向磁盤寫入數據的頻率。因為物理I/O會耗費大量時間，所以應盡可能地減少物理I/O以提高性能。該指標的值應盡可能的小。可以通過使用更大的數據高速緩存、智能索引、更高效的查詢或者改變數據庫設計等方法，以降低該指標的值。個數/秒
惰性寫/秒
(Lazy Writes/sec)
指每秒被緩沖區管理器的惰性編寫器寫入的緩沖區數。惰性編寫器是一個系統進程，用于成批刷新臟的老化的緩沖區（包含更改的緩沖區，必須將這些更改寫回磁盤，才能將緩沖區重用于其他頁），并使它們可用于用戶進程。該指標的值最好為0。個數/秒
3．SQL
Server中高速緩存管理器（Cache
Manager）對象包含的性能計數器
高速緩存命中率(Cache Hit Ratio%）指高速緩存命中次數和查找次數的比率。在SQL
Server中，Cache包括Log Cache，Buffer
Cache以及Procedure Cache，該指標是指所有Cache的命中率，是一個總體的比率。
該指標的值越高越好。如果該指標的值持續低于80%，就需要增加更多的內存。%
4．SQL
Server中閂（Latches）對象包含的性能計數器
平均閂等待
時間(毫秒)
(Average Latch
Wait Time(ms))
指一個SQL
Server線程必須等待一個閂的平均時間。
如果該指標的值很高，則系統可能正經歷嚴重的資源競爭問題。毫秒
閂等待/秒
(Latch Waits/sec)
指在一個閂上每秒的平均等待數量。如果該指標的值很高，則系統可能正經歷嚴重的資源競爭問題。個數/秒
5．SQL
Server中鎖（Locks）對象包含的性能計數器
死鎖的數量/秒
(Number of Deadlocks/sec)
指每秒導致死鎖的鎖請求數。鎖加在SQL
Server資源上（如在一個事務中進行的行讀取或修改），以防止多個事務并發使用資源。應盡可能少使用鎖以提高事務的并發性，從而改善性能。
個數/秒
平均等待時間(毫秒)
(Average Wait
Time(ms))
指線程等待某種類型的鎖的平均等待時間。同上毫秒
鎖請求/秒
(Lock Requests/sec)
指每秒鐘某種類型的鎖請求的數量。同上個數/秒
附錄三DB2性能指標
附錄四oracle數據庫性能指標
