數據庫性能優化一：數據庫自身優化（大數據量）

　　數據庫優化包含如下三部分，數據庫自身的優化，數據庫表優化，程序操做優化.此文爲第一部分

　　數據庫性能優化一：數據庫自身優化

　　優化①：增長次數據文件，設置文件自動增加（粗略數據分區）

  1.1：增長次數據文件

　　從SQL SERVER 2005開始，數據庫不默認生成NDF數據文件，通常狀況下有一個主數據文件（MDF）就夠了，可是有些大型的數據庫，因爲信息不少，並且查詢頻繁，因此爲了提升查詢速度，能夠把一些表或者一些表中的部分記錄分開存儲在不一樣的數據文件裏 因爲CPU和內存的速度遠大於硬盤的讀寫速度，因此能夠把不一樣的數據文件放在不一樣的物理硬盤裏，這樣執行查詢的時候，就可讓多個硬盤同時進行查詢，以充分利用CPU和內存的性能，提升查詢速度。 在這裏詳細介紹一下其寫入的原理，數據文件（MDF、NDF）和日誌文件（LDF）的寫入方式是不同的：

　　數據文件：SQL Server按照同一個文件組裏面的全部文件現有空閒空間的大小，按這個比例把新的數據分佈到全部有空間的數據文件裏，若是有三個數據文件A.MDF，B.NDF，C.NDF，空閒大小分別爲200mb，100mb，和50mb，那麼寫入一個70mb的東西，他就會向ABC三個文件中一次寫入40、20、10的數據，若是某個日誌文件已滿，就不會向其寫入

　　日誌文件：日誌文件是按照順序寫入的，一個寫滿，纔會寫入另一個

　　由上可見，若是能增長其數據文件NDF,有利於大數據量的查詢速度，可是增長日誌文件卻沒什麼用處。

1.2：設置文件自動增加（大數據量，小數據量無需設置）

　　在SQL Server 2005中，默認MDF文件初始大小爲5MB，自增爲1MB，不限增加，LDF初始爲1MB，增加爲10%，限制文件增加到必定的數目，通常設計中，使用SQL自帶的設計便可，可是大型數據庫設計中，最好親自去設計其增加和初始大小，若是初始值過小，那麼很快數據庫就會寫滿，若是寫滿，在進行插入會是什麼狀況呢？當數據文件寫滿，進行某些操做時，SQL Server會讓操做等待，直到文件自動增加結束了，原先的那個操做才能繼續進行。若是自增加用了很長時間，原先的操做會等不及就超時取消了（通常默認的閾值是15秒），不但這個操做會回滾，文件自動增加也會被取消。也就是說，這一次文件沒有獲得任何增大，增加的時間根據自動增加的大小肯定的，若是過小，可能一次操做須要連續幾回增加才能知足，若是太大，就須要等待很長時間，因此設置自動增加要注意一下幾點：

　　1）要設置成按固定大小增加，而不能按比例。這樣就能避免一次增加太多或者太少所帶來的沒必要要的麻煩。建議對比較小的數據庫，設置一次增加50 MB到100 MB。對大的數據庫，設置一次增加100 MB到200 MB。

　　2）要按期監測各個數據文件的使用狀況，儘可能保證每一個文件剩餘的空間同樣大，或者是指望的比例。

　　3）設置文件最大值，以避免SQL Server文件自增加用盡磁盤空間，影響操做系統。

　　4）發生自增加後，要及時檢查新的數據文件空間分配狀況。避免SQL Server老是往個別文件寫數據。

　　所以，對於一個比較繁忙的數據庫，推薦的設置是開啓數據庫自動增加選項，以防數據庫空間用盡致使應用程序失敗，可是要嚴格避免自動增加的發生。同時，儘可能不要使用自動收縮功能。 

 1.3 數據和日誌文件分開存放在不一樣磁盤上　

　 數據文件和日誌文件的操做會產生大量的I/O。在可能的條件下，日誌文件應該存放在一個與數據和索引所在的數據文件不一樣的硬盤上以分散I/O，同時還有利於數據庫的災難恢復。

　　優化②：表分區，索引分區 （優化①粗略的進行了表分區，優化②爲精確數據分區）

　　爲何要表分區？

 　　 當一個表的數據量太大的時候，咱們最想作的一件事是什麼？將這個表一分爲二或者更多分，可是表仍是這個表，只是將其內容存儲分開，這樣讀取就快了N倍了

　　原理：表數據是沒法放在文件中的，可是文件組能夠放在文件中，表能夠放在文件組中，這樣就間接實現了表數據存放在不一樣的文件中。能分區存儲的還有：表、索引和大型對象數據 。

　　SQL SERVER 2005中，引入了表分區的概念， 當表中的數據量不斷增大，查詢數據的速度就會變慢，應用程序的性能就會降低，這時就應該考慮對錶進行分區,當一個表裏的數據不少時，能夠將其分拆到多個的表裏,由於要掃描的數據變得更少 ,查詢能夠更快地運行,這樣操做大大提升了性能,表進行分區後，邏輯上表仍然是一張完整的表，只是將表中的數據在物理上存放到多個表空間(物理文件上)，這樣查詢數據時，不至於每次都掃描整張表 

 2.1何時使用分區表：

   一、表的大小超過2GB。 

  二、表中包含歷史數據，新的數據被增長到新的分區中。 

 2.2表分區的優缺點 

表分區有如下優勢：    1、改善查詢性能：對分區對象的查詢能夠僅搜索本身關心的分區，提升檢索速度。    2、加強可用性：若是表的某個分區出現故障，表在其餘分區的數據仍然可用；    3、維護方便：若是表的某個分區出現故障，須要修復數據，只修復該分區便可；    4、均衡I/O：能夠把不一樣的分區映射到磁盤以平衡I/O，改善整個系統性能。  缺點：    分區表相關：已經存在的表沒有方法能夠直接轉化爲分區表。不過 Oracle 提供了在線重定義表的功能.

2.3表分區的操做三步走

   2.31 建立分區函數

CREATE PARTITION FUNCTION xx1(int)

AS RANGE LEFT FOR VALUES (10000, 20000);

註釋：建立分區函數：myRangePF2，以INT類型分區，分三個區間，10000之內在A 區，1W-2W在B區，2W以上在C區.

 2.3.2建立分區架構

CREATE PARTITION SCHEME myRangePS2

AS PARTITION xx1

TO (a, b, c);

註釋：在分區函數XX1上建立分區架構：myRangePS2，分別爲A,B,C三個區間

A,B,C分別爲三個文件組的名稱，並且必須三個NDF隸屬於這三個組，文件所屬文件組一旦建立就不能修改

2.3.3 對錶進行分區

經常使用數據規範--數據空間類型修改成：分區方案，而後選擇分區方案名稱和分區列列表，結果如圖所示：

也能夠用sql語句生成

CREATE TABLE [dbo].[AvCache]( 

[AVNote] [varchar](300) NULL,

[bb] [int] IDENTITY(1,1)

) ON [myRangePS2](bb); --注意這裏使用[myRangePS2]架構，根據bb分區

2.3.4查詢表分區

SELECT *, $PARTITION.[myRangePF2](bb)  FROM dbo.AVCache 

這樣就能夠清楚的看到表數據是如何分區的了

2.3.5建立索引分區

 

　　優化③：分佈式數據庫設計

　　分佈式數據庫系統是在集中式數據庫系統的基礎上發展起來的，理解起來也很簡單，就是將總體的數據庫分開，分佈到各個地方，就其本質而言，分佈式數據庫系統分爲兩種：1.數據在邏輯上是統一的，而在物理上倒是分散的，一個分佈式數據庫在邏輯上是一個統一的總體，在物理上則是分別存儲在不一樣的物理節點上，咱們一般說的分佈式數據庫都是這種2.邏輯是分佈的，物理上也是分佈的，這種也成聯邦式分佈數據庫，因爲組成聯邦的各個子數據庫系統是相對「自治」的，這種系統能夠容納多種不一樣用途的、差別較大的數據庫，比較適宜於大範圍內數據庫的集成。

　　分佈式數據庫較爲複雜，在此不做詳細的使用和說明，只是舉例說明一下，如今分佈式數據庫多用於用戶分區性較強的系統中，若是一個全國連鎖店，通常設計爲每一個分店都有本身的銷售和庫存等信息，總部則須要有員工，供應商，分店信息等數據庫，這類型的分店數據庫能夠徹底一致，不少系統也可能致使不一致，這樣，各個連鎖店數據存儲在本地，從而提升了影響速度，下降了通訊費用，並且數據分佈在不一樣場地，且存有多個副本，即便個別場地發生故障，不致引發整個系統的癱瘓。 可是他也帶來不少問題，如：數據一致性問題、數據遠程傳遞的實現、通訊開銷的下降等，這使得分佈式數據庫系統的開發變得較爲複雜，只是讓你們明白其原理，具體的使用方式就不作詳細的介紹了。 

　　優化④：整理數據庫碎片

　　若是你的表已經建立好了索引，但性能卻仍然很差，那極可能是產生了索引碎片，你須要進行索引碎片整理。

　　什麼是索引碎片?

　　因爲表上有過分地插入、修改和刪除操做，索引頁被分紅多塊就造成了索引碎片，若是索引碎片嚴重，那掃描索引的時間就會變長，甚至致使索引不可用，所以數據檢索操做就慢下來了。

　　如何知道是否發生了索引碎片?

在SQLServer數據庫，經過DBCC ShowContig或DBCC ShowContig(表名)檢查索引碎片狀況，指導咱們對其進行定時重建整理。 

  

經過對掃描密度（太低），掃描碎片（太高）的結果分析，斷定是否須要索引重建，主要看以下兩個： Scan Density [Best Count:Actual Count]-掃描密度［最佳值:實際值］：DBCC SHOWCONTIG返回最有用的一個百分比。這是擴展盤區的最佳值和實際值的比率。該百分比應該儘量靠近100％。低了則說明有外部碎片。

Logical Scan Fragmentation-邏輯掃描碎片：無序頁的百分比。該百分比應該在0％到10％之間，高了則說明有外部碎片。 

解決方式：

一是利用DBCC INDEXDEFRAG整理索引碎片

二是利用DBCC DBREINDEX重建索引。

二者區別調用微軟的原話以下： DBCC INDEXDEFRAG 命令是聯機操做，因此索引只有在該命令正在運行時纔可用，並且能夠在不丟失已完成工做的狀況下中斷該操做。這種方法的缺點是在從新組織數據方面沒有彙集索引的除去/從新建立操做有效。 從新建立彙集索引將對數據進行從新組織，其結果是使數據頁填滿。填滿程度可使用 FILLFACTOR 選項進行配置。這種方法的缺點是索引在除去/從新建立週期內爲脫機狀態，而且操做屬原子級。若是中斷索引建立，則不會從新建立該索引。也就是說，要想得到好的效果，仍是得用重建索引，因此決定重建索引。