database - 數據庫設計/使用容易忽略的細節

1、設計

 

1，數據類型儘可能使用數字型，數字型的比較比字符型的快不少

 

2，數據類型儘可能小，預測能夠知足將來需求的前提

 

3，儘可能建表時字段不容許爲null，除非必要，能夠用NOT NULL+DEFAULT代替

當你須要查詢數據的時候你每每須要在WHERE條件中多加一個判斷條件IS NOT NULL,這樣的一個條件不只僅增長了額外的開銷，並且對查詢的性能產生很大的影響，有可能就由於多了這個查詢條件致使你的查詢變的很是的慢；還有一個比較重要的問題就是容許爲空的數據可能會致使你的查詢結果出現不許確的問題，

----若是整形字段能夠賦0，字符型能夠賦值空（這裏只是給建議）這裏的空和NULL是不同的意思
--增長整形字段能夠這樣寫
ALTER TABLE TABLE_NAME ADD  COLUMN_NAME  INT NOT NULL DEFAULT(0)

--增長字符型字段能夠這樣寫
ALTER TABLE TABLE_NAME ADD  COLUMN_NAME  NVARCHAR(50) NOT NULL DEFAULT('')

 

4，少用TEXT和IMAGE，二進制字段的讀寫是比較慢的，並且，讀取的方法也很少，大部分狀況下最好不用

 

5,創建自增列時單獨再給自增列添加惟一約束

若是要保證ID是惟一的，單單隻設置自增值不行，須要給字段設置主鍵或者惟一約束

 

6，創建索引

能夠根據功能和性能的需求進行初步的索引設計，這裏須要根據預計的數據量和查詢來設計索引

A、根據數據量決定哪些表須要增長索引，數據量小的能夠只有主鍵

B、根據使用頻率決定哪些字段須要創建索引，選擇常常做爲鏈接條件、篩選條件、聚合查詢、排序的字段做爲索引的候選字段

C、把常常一塊兒出現的字段組合在一塊兒，組成組合索引，組合索引的字段順序與主鍵同樣，也須要把最經常使用的字段放在前面，把重複率低的字段放在前面

D、一個表不要加太多索引，由於索引影響插入和更新的速度

創建索引後，並非每一個查詢都會使用索引，在使用索引的狀況下，索引的使用效率也會有很大的差異。只要咱們在查詢語句中沒有強制指定索引，索引的選擇和使用方法是SQLSERVER的優化器自動做的選擇，而它選擇的根據是查詢語句的條件以及相關表的統計信息，這就要求咱們在寫SQL語句的時候儘可能使得優化器可使用索引。

 

 

2、編碼

1，查詢條件不要使用計算列

例：查詢條件爲 year(createdate)=2014

優化：createdate>='20140101' and createdate<='20141231'

緣由：使用計算列查詢，是經過[索引掃描]方式查找

不使用計算列，走的是索引查找

絕大部分狀況下索引查找的查詢性能要高於索引掃描，特別是查詢的數據庫不是很是大的狀況下，索引查找的消耗時間要遠遠少於索引掃描的時間,相關知識[彙集、非彙集、堆的索引]

　　

2，分組統計時避免使用count(*)

if OBJECT_ID('Customer') is not null drop table [Customer]
go
create table [Customer] (CId int not null,Name nvarchar(20));
go
if OBJECT_ID('Order') is not null drop table [Order]
go
create table [Order] (OId int not null, CusId int);
go
insert into Customer values(1,'小米'),(2,'大米'),(3,'mini')
insert into [Order] values(1,1),(2,2),(3,NULL),(4,1)

　　

--例如:須要統計每一個顧客的訂單量
--使用count(*)
select CID,count(*) from Customer left join [order] on Customer.CId=[order].CusId group by CId

　　

實際狀況CusId=3是沒有訂單的，數量應該是0，可是結果是1,count()裏面的字段是左鏈接右邊的表字段，若是你用的是主表字段結果頁是錯誤的。

--正確的方法是使用count(CusId)
select CID,count(CusId) from Customer left join [order] on Customer.CId=[order].CusId group by CId

 

3，子查詢的表加上表別名

4，查詢時使用*

查詢時必定不能使用」*」來代替字段來進行查詢，不管你查詢的字段有多少個，就算字段太多沒法走索引也避免瞭解析」*」帶來的額外消耗。

查詢字段值列出想要的字段，避免出現多餘的字段，字段越多查詢開銷越大並且可能會由於多列出了某個字段而引發查詢不走索引。

 

5，使用存儲過程的好處

1. 減小網絡通訊量。調用一個行數很少的存儲過程與直接調用SQL語句的網絡通訊量可能不會有很大的差異，但是若是存儲過程包含上百行SQL語句，那麼其性能絕對比一條一條的調用SQL語句要高得多。
2. 執行速度更快。有兩個緣由：首先，在存儲過程建立的時候，數據庫已經對其進行了一次解析和優化。其次，存儲過程一旦執行，在內存中就會保留一份這個存儲過程緩存計劃，這樣下次再執行一樣的存儲過程時，能夠從內存中直接調用。
3. 更強的適應性：因爲存儲過程對數據庫的訪問是經過存儲過程來進行的，所以數據庫開發人員能夠在不改動存儲過程接口的狀況下對數據庫進行任何改動，而這些改動不會對應用程序形成影響。
4. 布式工做：應用程序和數據庫的編碼工做能夠分別獨立進行，而不會相互壓制。
5. 更好的封裝移植性。
6. 安全性，它們能夠防止某些類型的 SQL 插入攻擊。

默認狀況下，存儲過程將返回過程當中每一個語句影響的行數。若是不須要在應用程序中使用該信息（大多數應用程序並不須要），請在存儲過程當中使用 SET NOCOUNT ON 語句以終止該行爲。根據存儲過程當中包含的影響行的語句的數量，這將刪除客戶端和服務器之間的一個或多個往返過程。儘管這不是大問題，但它能夠爲高流量應用程序的性能產生負面影響。

6，判斷一條查詢是否有值

IF NOT EXISTS/IF EXISTS 優於 COUNT(*)

 

7, 理解TRUNCATE和DELETE的區別

TRUNCATE操做沒有記錄刪除日誌操做

主要的緣由是由於TRUNCATE操做不會激活觸發器,由於TRUNCATE操做不會記錄各行的日誌刪除操做,因此當你須要刪除一張表的數據時你須要考慮是否應該若有記錄日誌刪除操做，而不是根據我的的習慣來操做。

 

8，事務的理解

XACT_ABORT

---查詢是否有打開事務
SELECT XACT_STATE()

DBCC OPENTRAN
未查詢到有打開事務
當 SET XACT_ABORT 爲 ON 時，若是執行 Transact-SQL 語句產生運行時錯誤，則整個事務將終止並回滾。

當 SET XACT_ABORT 爲 OFF 時，有時只回滾產生錯誤的 Transact-SQL 語句，而事務將繼續進行處理。若是錯誤很嚴重，那麼即便 SET XACT_ABORT 爲 OFF，也可能回滾整個事務。OFF 是默認設置。

編譯錯誤（如語法錯誤）不受 SET XACT_ABORT 的影響。

 

9,條件字段的前後順序

對於常常用做查詢的字段放在第一個位置,其它的字段根據表的實際字段順序排列，這樣每每你的查詢語句走索引的機率會更大。

 

10,避免使用長字節字段排序

order by Id 優於 order by CreateTime