A. 如何檢查sql資料庫索引填充因子是否產生碎片以及如何處理
這是收藏的一些資料：
SQLServer提供了一個資料庫命令――DBCC SHOWCONTIG――來確定一個指定的表或索引是否有碎片。
示例：
顯示資料庫里所有索引的碎片信息
DBCC SHOWCONTIG WITH ALL_INDEXES
顯示指定表的所有索引的碎片信息
DBCC SHOWCONTIG (authors) WITH ALL_INDEXES
顯示指定索引的碎片信息
DBCC SHOWCONTIG (authors,aunmind)
DBCC 執行結果：
掃描頁數：如果你知道行的近似尺寸和表或索引里的行數，那麼你可以估計出索引里的頁數。看看掃描頁數，如果明顯比你估計的頁數要高，說明存在內部碎片。
掃描擴展盤區數：用掃描頁數除以8,四捨五入到下一個最高值。該值應該和DBCC SHOWCONTIG返回的掃描擴展盤區數一致。如果DBCC SHOWCONTIG返回的數高，說明存在外部碎片。碎片的嚴重程度依賴於剛才顯示的值比估計值高多少。
擴展盤區開關數：該數應該等於掃描擴展盤區數減1。高了則說明有外部碎片。
每個擴展盤區上的平均頁數：該數是掃描頁數除以掃描擴展盤區數，一般是8。小於8說明有外部碎片。
掃描密度［最佳值:實際值］：DBCC SHOWCONTIG返回最有用的一個百分比。這是擴展盤區的最佳值和實際值的比率。該百分比應該盡可能靠近100％。低了則說明有外部碎片。
邏輯掃描碎片：無序頁的百分比。該百分比應該在0％到10％之間，高了則說明有外部碎片。
擴展盤區掃描碎片：無序擴展盤區在掃描索引葉級頁中所佔的百分比。該百分比應該是0％，高了則說明有外部碎片。
每頁上的平均可用位元組數：所掃描的頁上的平均可用位元組數。越高說明有內部碎片，不過在你用這個數字決定是否有內部碎片之前，應該考慮fill factor（填充因子）。
平均頁密度（完整）：每頁上的平均可用位元組數的百分比的相反數。低的百分比說明有內部碎片。
解決碎片問題 ：
1. 刪除並重建索引
2. 使用DROP_EXISTING子句重建索引
3. 執行DBCC DBREINDEX
4. 執行DBCC INDEXDEFRAG
刪除並重建索引 ：
用DROP INDEX和CREATE INDEX或ALTER TABLE來刪除並重建索引有些缺陷包括在刪除重建期間索引會消失。在索引刪除重建時，對於查詢它不在可用，查詢性能也許會受到明顯的影響，直到重建索引為止。另一個潛在的缺陷是當都請求索引的時候會引起阻塞，直到重建索引為止。通過其他的處理也能解決阻塞，就是索引被使用的時候不刪除索引。另一個主要的缺陷是在用DROP INDEX和CREATE INDEX重建聚集索引時會引起非聚集索引重建兩次。刪除聚集索引時非聚集索引的行指針會指向數據堆，聚集索引重建時非聚集索引的行指針又會指回聚集索引的行位置。
刪除並重建索引的確有一個好處就是通過重新排序索引頁，使索引頁緊湊並刪除不需要的索引頁來完全重建索引。你也許需要考慮那些內部和外部碎片都很高的情況下才使用，以使那些索引回到它們應該在的位置。
使用DROP_EXISTING子句重建索引 ：
為了避免在重建聚集索引時表上的非聚集索引重建兩次，可以使用帶DROP_EXISTING子句的CREATE INDEX語句。這個子句會保留聚集索引鍵值，以避免非聚集索引重建兩次。和刪除並重建索引一樣，該方法也可能會引起阻塞和索引消失的問題。該方法的另一個缺陷是也強迫你去分別發現和修復表上的每一個索引。
除了和上一個方法一樣的好處之外，該方法的好處是不必重建非聚集索引兩次。這樣可以對那些帶約束的索引提供正確的索引定義以符合約束的要求。
執行DBCC DBREINDEX ：
DBCC DBREINDEX類似於第二種方法，但它物理地重建索引，允許SQLServer給索引分配新頁來減少內部和外部碎片。DBCC DBREINDEX也能動態的重建帶約束的索引，不象第二種方法。
DBCC DBREINDEX的缺陷是會遇到或引起阻塞問題。DBCC DBREINDEX是作為一個事務來運行的，所以如果在完成之前中斷了，那麼你會丟失所有已經執行過的碎片。
執行DBCC INDEXDEFRAG ：
DBCC INDEXDEFRAG（在SQLServer2000中可用）按照索引鍵的邏輯順序，通過重新整理索引里存在的葉頁來減少外部碎片，通過壓縮索引頁里的行然後刪除那些由此產生的不需要的頁來減少內部碎片。它不會遇到阻塞問題但它的結果沒有其他幾個方法徹底。這是因為DBCC INDEXDEFRAG跳過了鎖定的頁且不使用任何新頁來重新排序索引。如果索引的碎片數量大的話你也許會發現DBCC INDEXDEFRAG比重建索引花費的時間更長。DBCC INDEXDEFRAG比其他方法的確有好處的是在其他過程訪問索引時也能進行碎片整理，不會引起其他方法的阻塞問題。
B. 如何用sql語句在列上建立聚集索引
可以用如下語句
create clustered index 索引名 on 表名(欄位名)
C. sql 自動創建的主鍵索引 可以刪除嗎
1. 首先刪除主鍵, 然後重新創建主鍵,
重新創建主鍵的時候, 需要說明本主鍵是使用 非聚集索引
PRIMARY KEY NONCLUSTERED ( sno )
D. SQL中怎麼刪除由creat table命令創建的primary key 約束索引
1.在聚集索引中，表中各行的物理順序和鍵值的邏輯（索引）順序相同。非聚集索引則不相同。因此聚集索引比非聚集索引有更快的數據訪問速度。因為其鍵值的邏輯（索引）順序即為物理順序。
2.同一張表裡只能有一個聚集索引，而可以有多個非聚集索引
3.當你沒有設置聚集索引的時候，就設置主鍵的話，會默認把主鍵所在的列設置為聚集索引
反之則不會設置為聚集索引
E. 刪除索引的sql語句
刪除索引可以使用ALTER TABLE或DROP INDEX語句來實現。DROP INDEX可以在ALTER TABLE內部作為一條語句處理，其格式如下：
drop index index_name on table_name ;
alter table table_name drop index index_name ;
alter table table_name drop primary key ;
其中，在前面的兩條語句中，都刪除了
F. SQL2008中索引類型為聚集,非聚集,主XML,空間各是什麼意思
聚集索引：表中存儲的數據按照索引的順序存儲，檢索效率比普通索引高，但對數據新增/修改/刪除的影響比較大。
非聚集索引：不影響表中的數據存儲順序，檢索效率比聚集索引低，對數據新增/修改/刪除的影響很小。
一張表只有一個聚簇索引，可有多個非聚簇索引。
G. 刪除索引的sql語句是(
先選擇該索引。右鍵看看哪些表對該索引有依賴。解除依賴。再用Drop Index 索引名 刪除
alter table tableName drop index indexName
用delete 語句可以刪去，但是在栓去之前的解除表之間的關系。
H. 用SQL sever時，出現」無法對 表 'C23' 創建多個聚集索引。「怎麼解決
SQL server 裡面， 一個表 最多隻能有一個 聚集索引。
默認情況下， 主鍵是 聚集索引。
因此，2條路。
1. 修改你創建索引的語句， 把那個 聚集 的關鍵字刪除掉。 這樣就默認創建一個 非聚集索引。
2. 刪除主鍵，並重建之， 創建主鍵的時候， 加上 「非聚集」的關鍵字。 然後就可以創建你的聚集索引了。
I. sql server執行計劃 怎麼看消耗資源
掃描：逐行遍歷數據。
先建立一張表，並給大家看看大概是什麼樣子的。
CREATE TABLE Person(
Id int IDENTITY(1,1) NOT NULL,
Name nvarchar(50) NULL,
Age int NULL,
Height int NULL,
Area nvarchar(50) NULL,
MarryHistory nvarchar(10) NULL,
EcationalBackground nvarchar(10) NULL,
Address nvarchar(50) NULL,
InSiteId int NULL
) ON [PRIMARY]
表中的數據14萬左右，大概類似下面這樣：
此表，暫時沒有任何索引。
一、數據訪問操作
1、表掃描
表掃描:發生於堆表，並且沒有可用的索引可用時，會發生表掃描,表示整個表掃描一次。
現在，我們來對此表執行一條簡單的查詢語句：
SELECT * From Person WHERE Name = '公子'
查看執行計劃如下：
表掃描，顧名思義就是整張表掃描，找到你所需要的數據了。
2、聚集索引掃描
聚集索引掃描：發生於聚集表，也相當於全表掃描操作，但在針對聚集列的條件如(WHERE Id > 10)等操作時，效率會較好。
下面我們在Id列來對此表加上一個聚集索引
CREATE CLUSTERED INDEX IX_Id ON Person(Id)
再次執行同樣的查詢語句：
SELECT * From Person WHERE Name = '公子'
執行計劃如下：
為什麼建的聚集索引在Id列，會對掃描有影響呢？更何況與Name條件也沒關系啊？
其實，你加了聚集索引之後，表就由堆表變成了聚集表。我們知道聚集表的數據存在於聚集索引的葉級節點。因此，聚集掃描與表掃描其實差別不大，要說差別大，也得看where條件里是什麼，以後返回的數據。就本條SQL語句而言，效率差別並不大。
可以看看I/O統計信息：
表掃描：
聚集索引掃描：
此處超出本文范疇了，效率不在本文考慮范圍內，本文只考慮的是，各種掃描的區別，以及為何會產生。
3、聚集索引查找
聚集索引查找：掃描聚集索引中特定范圍的行。
看執行以下SQL語句：
SELECT * FROM Person WHERE Id = '73164'
執行計劃如下:
4、索引掃描
索引掃描：整體掃描非聚集索引。
下面我們來添加一個聚集索引，並執行一條查詢語句：
CREATE NONCLUSTERED INDEX IX_Name ON Person(Name) --創建非聚集索引
SELECT Name FROM Person
查看執行計劃如下：
為什麼此處會選擇索引掃描(非聚集索引)呢？
因為此非聚集索引能夠覆蓋所需要的數據。如果非聚集索引不能覆蓋呢?例如，我們將SELECT改為SELECT *再來看看。
好明顯，返回結果所包括的記錄太多，用非聚集索引反而不合算。因此使用了聚集索引。
如果此時我們刪除聚集索引，再執行SELECT *看看。
DROP INDEX Person.IX_Id
而此時沒有聚集索引，所以只有使用表掃描。
5、書簽查找
前面關於索引的學習我們已經知道，當在非聚集索引中並非覆蓋和包含所需全部的列時，SQL Server會選擇，直接進行聚集索引掃描獲得數據，還是先去非聚集索引找到聚集索引鍵，然後利用聚集索引找到數據。
下面來看一個書簽查找的示例：
SELECT * FROM Person WHERE Name = '胖胖'--Name列有非聚集索引
執行計劃如下：
上面的過程可以理解為：首先通過非聚集索引找到所求的行，但這個索引並不包含所有的列，因此還要額外去基本表中找到這些列，因此要進行鍵查找，如果基本表是以堆進行組織的，那麼這個鍵查找(Key Lookup)就會變成RID查找(RID Lookup),鍵查找和RID查找統稱為書簽查找。不過有時當非聚集索引返回的行數過多時，SQL Server可能會選擇直接進行聚集索引掃描了。
二、流聚合操作
1、流聚合
流聚合：在相應排序的流中，計算多組行的匯總值。
所有的聚合函數(如COUNT(),MAX())都會有流聚合的出現，但是其不會消耗IO，只有消耗CPU。
例如執行以下語句：
SELECT MAX(Age) FROM Person
查看執行計劃如下：
2、計算標量
計算標量：根據行中的現有值計算新值。比如COUNT()函數，多一行，行數就加1咯。
除MIN和MAX函數之外的聚合函數都要求流聚合操作後面跟一個計算標量。
SELECT COUNT(*) FROM Person
查看執行計劃如下：
3、散列聚合(哈希匹配)
對於加了Group by的子句，因為需要數據按照group by 後面的列有序，就需要Sort來保證排序。注意,Sort操作是佔用內存的操作，當內存不足時還會去佔用tempdb。SQL Server總是會在Sort操作和散列匹配中選擇成本最低的。
SELECT Height,COUNT(Id) FROM Person --查出各身高的認輸
GROUP BY Height
執行計劃如下：
對於數據量比較大時，SQL Server選擇的是哈希匹配。
在內存中建立好散列表後，會按照group by後面的值作為鍵，然後依次處理集合中的每條數據，當鍵在散列表中不存在時，向散列表添加條目，當鍵已經在散列表中存在時，按照規則（規則是聚合函數，比如Sum,avg什麼的）計算散列表中的值（Value）。
4、排序
當數據量比價少時，例如執行以下語句，新建一個只有數十條記錄的與Person一樣的表。
SELECT * INTO Person2 FROM Person2
WHERE Id < 100
再來執行同樣的查詢語句：
SELECT Height,COUNT(Id) FROM Person2 --只是表換成了數據量比較少的表
GROUP BY Height
執行計劃如下：
三、連接
當多表連接時(包括書簽查找，索引之間的連接)，SQL Server會採用三類不同的連接方式：循環嵌套連接，合並連接，散列連接。這幾種連接格式有適合自己的場景，不存在哪個更好的說法。
新建兩張表如下
這是一個簡單的新聞，欄目結構。
1、嵌套循環
先來看一個簡單的Inner Join查詢語句
SELECT * FROM Nx_Column AS C
INNER JOIN Nx_Article AS A
ON A.ColumnId = C.ColumnId
執行計劃如下：
循環嵌套連接的圖標同樣十分形象，處在上面的外部輸入(Outer input)，這里也就是聚集索引掃描。和處在下面的內部輸入(Inner Input),這里也就是聚集索引查找。外部輸入僅僅執行一次，根據外部輸入滿足Join條件的每一行，對內部輸入進行查找。這里由於是7行，對於內部輸入執行7次。
根據嵌套循環的原理不難看出，由於外部輸入是掃描，內部輸入是查找，當兩個Join的表外部輸入結果集比較小，而內部輸入所查找的表非常大時，查詢優化器更傾向於選擇循環嵌套方式。
2、合並連接
不同於循環嵌套的是，合並連接是從每個表僅僅執行一次訪問。從這個原理來看，合並連接要比循環嵌套要快了不少。
從合並連接的原理不難想像，首先合並連接需要雙方有序.並且要求Join的條件為等於號。因為兩個輸入條件已經有序，所以從每一個輸入集合中取一行進行比較，相等的返回，不相等的舍棄，從這里也不難看出Merge join為什麼只允許Join後面是等於號。從圖11的圖標中我們可以看出這個原理。
SELECT * FROM Nx_Column AS C
INNER JOIN Nx_Article AS A
ON A.ColumnId = C.ColumnId
OPTION(MERGE join)
執行計劃如下：
如果輸入數據的雙方無序，則查詢分析器不會選擇合並連接，我們也可以通過索引提示強制使用合並連接，為了達到這一目的，執行計劃必須加上一個排序步驟來實現有序。這也是上述SQL語句為什麼要加OPTION(MERGE join)的原因。上述對Article表的ColumnId列進行了排序。
3、哈希連接
散列連接同樣僅僅只需要只訪問1次雙方的數據。散列連接通過在內存中建立散列表實現。這比較消耗內存，如果內存不足還會佔用tempdb。但並不像合並連接那樣需要雙方有序。
要進行下面這兩個實現，得把兩個列的聚集索引不要建在ColumnId列，否則不會採用哈希連接。
ALTER TABLE PK_Nx_Column DROP CONSTRAINT PK_Nx_Column --刪除主鍵
DROP INDEX Nx_Column.PK_Nx_Column --刪除聚集索引
CREATE CLUSTERED INDEX IX_ColumnName ON Nx_Column(ColumnName) --創建聚集索引
--這里再設置回主鍵就可以了，有了聚集索引，就不能隨主鍵默認建啦
還要刪除另外一個表Article的聚集索引哦。
然後執行以下查詢：
SELECT * FROM Nx_Column AS C
INNER JOIN Nx_Article AS A
ON A.ColumnId = C.ColumnId
執行計劃如下：
要刪除掉聚集索引，否則兩個有序輸入SQL Server會選擇代價更低的合並連接。SQL Server利用兩個上面的輸入生成哈希表，下面的輸入來探測，可以在屬性窗口看到這些信息，如圖15所示。
J. 怎麼在資料庫中刪除已經添加的某個索引
刪除索引可以使用ALTER TABLE或DROP INDEX語句來實現，DROP INDEX可以在ALTER TABLE內部作為一條語句處理，其格式如下：
DROP INDEX index_nameONtalbe_name
ALTER TABLE table_name DROP INDEX index_name
ALTER TABLE table_name DROP PRIMARY KEY
註：其中，前兩條語句是等價的，刪除掉table_name中的索引index_name。
(10)sql刪除聚集索引擴展閱讀：
索引的使用及注意事項
EXPLAIN可以幫助開發人員分析SQL問題,explain顯示了mysql如何使用索引來處理select語句以及連接表,可以幫助選擇更好的索引和寫出更優化的查詢語句。
使用方法,在select語句前加上Explain就可以了：Explain select * from user where id=1;
盡量避免這些不走索引的sql：
SELECT `sname` FROM `stu` WHERE `age`+10=30;-- 不會使用索引,因為所有索引列參與了計算
SELECT `sname` FROM `stu` WHERE LEFT(`date`,4) <1990; -- 不會使用索引,因為使用了函數運算,原理與上面相同
SELECT * FROM `hounwang` WHERE `uname` LIKE'後盾%' 走索引
SELECT * FROM `hounwang` WHERE `uname` LIKE "%後盾%" 不走索引
正則表達式不使用索引,這應該很好理解,所以為什麼在SQL中很難看到regexp關鍵字的原因。
字元串與數字比較不使用索引;
CREATE TABLE `a` (`a` char(10));
EXPLAIN SELECT * FROM `a` WHERE `a`="1" 走索引
EXPLAIN SELECT * FROM `a` WHERE `a`=1 不走索引