推薦：怎樣減少SQL Server死鎖發(fā)生的情況
死鎖是指在某組資源中，兩個或兩個以上的線程在執(zhí)行過程中，在爭奪某一資源時而造成互相等待的現(xiàn)象，若無外力的作用下,它們都將無法推進下去，死時就可能會產(chǎn)生死鎖,這些永遠在互相等待的進程稱為死鎖線程。簡單的說，進程A等待進程B釋放他的資源，B又等待A

在SQL Server中，為了查詢性能的優(yōu)化，有時我們就需要對數(shù)據(jù)表通過建立索引的方式，目的主要是根據(jù)查詢要求，迅速縮小查詢范圍，避免全表掃描。

索引有兩種類型，分別是聚集索引(clustered index，也稱聚類索引、簇集索引)和非聚集索引(nonclustered index，也稱非聚類索引、非簇集索引)。

聚集索引在一個表中只能有一個，默認情況下在主鍵建立的時候創(chuàng)建，它是規(guī)定數(shù)據(jù)在表中的物理存儲順序，我們也可以取消主鍵的聚集索引，所以必須考慮數(shù)據(jù)庫可能用到的查詢類型以及使用的最為頻繁的查詢類型，對其最常用的一個字段或者多個字段建立聚集索引或者組合的聚集索引，它就是SQL Server會在物理上按升序(默認)或者降序重排數(shù)據(jù)列，這樣就可以迅速的找到被查詢的數(shù)據(jù)。

非聚集索主要是數(shù)據(jù)存儲在一個地方，索引存儲在另一個地方，索引帶有指針指向數(shù)據(jù)的存儲位置。索引中的項目按索引鍵值的順序存儲，而表中的信息按另一種順序存儲�？梢栽谝粋�表格中使用高達249個非聚集的索引，在查詢的過程中先對非聚集索引進行搜索，找到數(shù)據(jù)值在表中的位置，然后從該位置直接檢索數(shù)據(jù)。這使非聚集索引成為精確匹配查詢的最佳方法，因為索引包含描述查詢所搜索的數(shù)據(jù)值在表中的精確位置的條目。

所以我們在選擇創(chuàng)建聚集索引的時候要注意以下幾個方面：

1) 對表建立主鍵時，就會為主鍵自動添加了聚集索引，如自動編號字段，而我們沒有必要把聚集索引浪費在主鍵上，除非你只按主鍵查詢，所以會把聚集索引設(shè)置在按條件查詢頻率最高的那個字段或者組合的字段。

2) 索引的建立要根據(jù)實際應(yīng)用的需求來進行，并非是在任何字段上建立索引就能提高查詢速度。聚集索引建立遵循下面幾個原則：

包含大量非重復值的列。

使用下列運算符返回一個范圍值的查詢：BETWEEN、>、>=、< 和 <=。

被連續(xù)訪問的列。

返回大型結(jié)果集的查詢。

經(jīng)常被使用聯(lián)接或 GROUP BY 子句的查詢訪問的列;一般來說，這些是外鍵列。對ORDER BY 或 GROUP BY 子句中指定的列進行索引，可以使 SQL Server 不必對數(shù)據(jù)進行排序，因為這些行已經(jīng)排序。這樣可以提高查詢性能。

OLTP 類型的應(yīng)用程序，這些程序要求進行非�？焖俚膯涡胁檎�(一般通過主鍵)。應(yīng)在主鍵上創(chuàng)建聚集索引。

舉例來說，銀行交易日志中對交易日期建立聚合索引，數(shù)據(jù)物理上按順序存于數(shù)據(jù)頁上，重復值也排列在一起，因而在范圍查找時，可以先找到這個范圍的起末點，且只在這個范圍內(nèi)掃描數(shù)據(jù)頁，避免了大范圍掃描，提高了查詢速度。而如果我們對員工的基本信息表中性別的字段列上建立聚集索引，就完全沒有必要，因為內(nèi)容里只涉及到 “男”與“女”兩個不同值。

3) 在聚集索引中按常用的組合字段建立索引，形成復合索引，一般在為表建立多個主鍵的時候就會產(chǎn)生，如果一個表中的數(shù)據(jù)在查詢時有多個字段總是同時出現(xiàn)則這些字段就可以作為復合索引,這樣能形成索引覆蓋,提高where語句的查詢效率。

4)索引對查詢有一這的優(yōu)化，但由于改變一個表的內(nèi)容，將會引起索引的變化。頻繁的對數(shù)據(jù)操作如insert,update,delete語句將導致系統(tǒng)花費較大的代價進行索引更新，引起整體性能的下降。一般來講，在對查詢性能的要求高于對數(shù)據(jù)維護性能要求時，應(yīng)該盡量使用索引，有時在這種操作數(shù)據(jù)庫比較頻繁的某些極端情況下，可先刪除索引，再對數(shù)據(jù)庫表更新大量數(shù)據(jù)，最后再重建索引，新建立的索引總是比較好用。

索引在使用了長久的時候，就會產(chǎn)生很多的碎片，查詢的性能就會受到影響，這時候有兩種方法解決，一是利用DBCC INDEXDEFRAG整理索引碎片，還有就是利用DBCC DBREINDEX重建索引。

DBCC INDEXDEFRAG 命令是聯(lián)機操作，所以索引只有在該命令正在運行時才可用。而且可以在不丟失已完成工作的情況下中斷該操作。這種方法的缺點是在重新組織數(shù)據(jù)方面沒有聚集索引的除去/重新創(chuàng)建操作有效。

重新創(chuàng)建聚集索引將對數(shù)據(jù)進行重新組織，其結(jié)果是使數(shù)據(jù)頁填滿。填滿程度可以使用 FILLFACTOR 選項進行配置。這種方法的缺點是索引在除去/重新創(chuàng)建周期內(nèi)為脫機狀態(tài)，并且操作屬原子級。如果中斷索引創(chuàng)建，則不會重新創(chuàng)建該索引。

我們來看看索引重建使用的方法：

語法 DBCC DBREINDEX ( [ ‘TableName’ [ , index_name [ , fillfactor ] ] ] )

參數(shù) ‘TableName’

是要重建其指定的索引的表名。數(shù)據(jù)庫、所有者和表名必須符合標識符的規(guī)則。有關(guān)更多信息，請參見使用標識符。如果提供 database 或 owner 部分，則必須使用單引號 (‘)將整個 database.owner.table_name 括起來。如果只指定 table_name，則不需要單引號。

index_name 是要重建的索引名。索引名必須符合標識符的規(guī)則。如果未指定 index_name 或指定為 ‘ ‘，就要對表的所有索引進行重建。

fillfactor 是創(chuàng)建索引時每個索引頁上要用于存儲數(shù)據(jù)的空間百分比。fillfactor替換起始填充因子以作為索引或任何其它重建的非聚集索引(因為已重建聚集索引)的新默認值。如果 fillfactor 為 0，DBCC DBREINDEX 在創(chuàng)建索引時將使用指定的起始fillfactor。

我們在查詢分析器中輸入如下的命令：

DBCC DBREINDEX (‘MyTable,’’,80)

這樣就會索引重建了。

分享：解析SQL Server數(shù)據(jù)庫觸發(fā)器的安全隱患
觸發(fā)器權(quán)限和所有權(quán) CREATE TRIGGER 權(quán)限默認授予定義觸發(fā)器的表所有者、sysadmin 固定服務(wù)器角色成員以及 db_owner 和 db_ddladmin 固定數(shù)據(jù)庫角色成員，并且不可轉(zhuǎn)讓。 需要的環(huán)境 本文需要的環(huán)境是已經(jīng)獲取了sql服務(wù)器的以上其中一個權(quán)限，目的是為了留下