1. 程式人生 > >數據庫性能優化二:數據庫表優化

數據庫性能優化二:數據庫表優化

尺寸 blog 一致性 依賴 常常 允許 new 自己 性能

  數據庫優化包含以下三部分,數據庫自身的優化,數據庫表優化,程序操作優化.此文為第二部分

  數據庫性能優化二:數據庫表優化

  優化①:設計規範化表,消除數據冗余

  數據庫範式是確保數據庫結構合理,滿足各種查詢需要、避免數據庫操作異常的數據庫設計方式。滿足範式要求的表,稱為規範化表,範式產生於20世紀70年代初,一般表設計滿足前三範式就可以,在這裏簡單介紹一下前三範式

先給大家看一下百度百科給出的定義:

第一範式(1NF)無重復的列

  所謂第一範式(1NF)是指在關系模型中,對域添加的一個規範要求,所有的域都應該是原子性的,即數據庫表的每一列都是不可分割的原子數據項,而不能是集合,數組,記錄等非原子數據項。

第二範式(2NF)屬性

  在1NF的基礎上,非碼屬性必須完全依賴於碼[1NF基礎上消除非主屬性對主碼的部分函數依賴]

第三範式(3NF)屬性

1NF基礎上,任何非主屬性不依賴於其它非主屬性[2NF基礎上消除傳遞依賴]

通俗的給大家解釋一下(可能不是最科學、最準確的理解)

  第一範式:屬性(字段)的原子性約束,要求屬性具有原子性,不可再分割;   第二範式:記錄的惟一性約束,要求記錄有惟一標識,每條記錄需要有一個屬性來做為實體的唯一標識。   第三範式:屬性(字段)冗余性的約束,即任何字段不能由其他字段派生出來,在通俗點就是:主鍵沒有直接關系的數據列必須消除(消除的辦法就是再創建一個表來存放他們,當然外鍵除外)

如果數據庫設計達到了完全的標準化,則把所有的表通過關鍵字連接在一起時,不會出現任何數據的復本(repetition)。標準化的優點是明顯的,它避免了數據冗余,自然就節省了空間,也對數據的一致性(consistency)提供了根本的保障,杜絕了數據不一致的現象,同時也提高了效率。

優化②:適當的冗余,增加計算列

  數據庫設計的實用原則是:在數據冗余和處理速度之間找到合適的平衡點

滿足範式的表一定是規範化的表,但不一定是最佳的設計。很多情況下會為了提高數據庫的運行效率,常常需要降低範式標準:適當增加冗余,達到以空間換時間的目的。比如我們有一個表,產品名稱,單價,庫存量,總價值。這個表是不滿足第三範式的,因為“總價值”可以由單價乘以數量得到,說明金額是冗余字段。但是,增加“總價值”這個冗余字段,可以提高查詢統計的速度,這就是以空間換時間的作法。合理的冗余可以分散數據量大的表的並發壓力,也可以加快特殊查詢的速度,冗余字段可以有效減少數據庫表的連接,提高效率。

其中"總價值"就是一個計算列,在數據庫中有兩種類型:數據列和計算列,數據列就是需要我們手動或者程序給予賦值的列,計算列是源於表中其他的數據計算得來,比如這裏的"總價值"

SQL中創建計算列:

create table table1 ( number decimal(18,4), price money, Amount as number*price --這裏就是計算列 )

也可以再表設計中,直接手動添加或修改列屬性即可:如下圖

技術分享

是否持久性,我們也需要註意:

如果是‘否‘,說明這列是虛擬列,每次查詢的時候計算一次,而且那麽它是不可以用來做check,foreign keynot null約束。

如果是‘是‘,就是真實的列,不需要每次都計算,可以再此列上創建索引等等。

優化③:索引

索引是一個表優化的重要指標,在表優化中占有極其重要的成分,所以將單獨寫一章”SQL索引一步到位“去告訴大家如何建立和優化索引

優化④:主鍵和外鍵的必要性

主鍵與外鍵的設計,在全局數據庫的設計中,占有重要地位。 因為:主鍵是實體的抽象,主鍵與外鍵的配對,表示實體之間的連接。

主鍵:根據第二範式,需要有一個字段去標識這條記錄,主鍵無疑是最好的標識,但是很多表也不一定需要主鍵,但是對於數據量大,查詢頻繁的數據庫表,一定要有主鍵,主鍵可以增加效率、防止重復等優點。

主鍵的選擇也比較重要,一般選擇總的長度小的鍵,小的鍵的比較速度快,同時小的鍵可以使主鍵的B樹結構的層次更少。 主鍵的選擇還要註意組合主鍵的字段次序,對於組合主鍵來說,不同的字段次序的主鍵的性能差別可能會很大,一般應該選擇重復率低、單獨或者組合查詢可能性大的字段放在前面。

外鍵:外鍵作為數據庫對象,很多人認為麻煩而不用,實際上,外鍵在大部分情況下是很有用的,理由是:外鍵是最高效的一致性維護方法

數據庫的一致性要求,依次可以用外鍵、CHECK約束、規則約束、觸發器、客戶端程序,一般認為,離數據越近的方法效率越高。 謹慎使用級聯刪除和級聯更新,級聯刪除和級聯更新作為SQL SERVER 2000當年的新功能,在2005作了保留,應該有其可用之處。我這裏說的謹慎,是因為級聯刪除和級聯更新有些突破了傳統的關於外鍵的定義,功能有點太過強大,使用前必須確定自己已經把握好其功能範圍,否則,級聯刪除和級聯更新可能讓你的數據莫名其妙的被修改或者丟失。從性能看級聯刪除和級聯更新是比其他方法更高效的方法。

優化⑤:存儲過程、視圖、函數的適當使用

很多人習慣將復雜操作都放在應用程序層,但如果你要優化數據訪問性能,將SQL代碼移植到數據庫上(使用存儲過程,視圖,函數和觸發器)也是一個很大的改進原因如下:

1. 存儲過程減少了網絡傳輸、處理及存儲的工作量,且經過編譯和優化,執行速度快,易於維護,且表的結構改變時,不影響客戶端的應用程序

2、使用存儲過程,視圖,函數有助於減少應用程序中SQL復制的弊端,因為現在只在一個地方集中處理SQL

3、使用數據庫對象實現所有的TSQL有助於分析TSQL的性能問題,同時有助於你集中管理TSQL代碼,更好的重構TSQL代碼

優化⑥:傳說中的‘三少原則’

①:數據庫的表越少越好

②:表的字段越少越好

③:字段中的組合主鍵、組合索引越少越好

當然這裏的少是相對的,是減少數據冗余的重要設計理念。

優化⑦:分割你的表,減小表尺寸

如果你發現某個表的記錄太多,例如超過一千萬條,則要對該表進行水平分割。水平分割的做法是,以該表主鍵的某個值為界線,將該表的記錄水平分割為兩個表。

如果你若發現某個表的字段太多,例如超過八十個,則垂直分割該表,將原來的一個表分解為兩個表

優化⑧:字段設計原則

字段是數據庫最基本的單位,其設計對性能的影響是很大的。需要註意如下:
A、數據類型盡量用數字型,數字型的比較比字符型的快很多。
B、 數據類型盡量小,這裏的盡量小是指在滿足可以預見的未來需求的前提下的。
C、 盡量不要允許NULL,除非必要,可以用NOT NULL+DEFAULT代替。
D、少用TEXTIMAGE,二進制字段的讀寫是比較慢的,而且,讀取的方法也不多,大部分情況下最好不用。
E、 自增字段要慎用,不利於數據遷移

數據庫性能優化二:數據庫表優化