MSSQL 重建索引（在线重建、控制最大处理器数 、MAXDOP ）
一、什么情況下需要重建索引
1、碎片過多（參考值：>20%）
索引碎片如何產(chǎn)生，請移步至《T-SQL查詢高級—SQL Server索引中的碎片和填充因子》
2、填充度過低（參考值：<75%）
導(dǎo)致填充度過低的可能原因：①.有刪除②.有分區(qū)表③.聚集索引不是數(shù)字④.數(shù)據(jù)百萬以內(nèi)，比較少
二、重建索引
ALTER INDEX <name of index> ON <table or view name> REBUILD WITH (ONLINE = ON,MAXDOP = 4)
ONLINE：在線執(zhí)行，減少重建過程中的鎖（執(zhí)行時(shí)間延長）
MAXDOP：手動(dòng)配置用于運(yùn)行索引語句的最大處理器數(shù)
| 值 | 說明 |
|---|---|
| 0 |
指定服務(wù)器根據(jù)當(dāng)前系統(tǒng)工作負(fù)荷確定所使用的 CPU 數(shù)目。這是默認(rèn)值，還是推薦設(shè)置。 |
| 1 |
取消生成并行計(jì)劃。操作將以串行方式執(zhí)行。 |
|
2-64 |
將處理器的數(shù)量限制為指定的值。根據(jù)當(dāng)前工作負(fù)荷，可能使用較少的處理器。如果指定的值大于可用的 CPU 數(shù)量，將使用實(shí)際可用的 CPU 數(shù)量。 |
-- 查找碎片率大于40
SELECT object_name(object_id) ,index_type_desc,alloc_unit_type_desc,avg_fragmentation_in_percent,
fragment_count,avg_fragment_size_in_pages,page_count,record_count,
avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID('DBNAME'),
OBJECT_ID(''),NULL,NULL,'Sampled')
WHERE avg_fragmentation_in_percent>40
三、擴(kuò)展筆記：
對于碎片的解決辦法（引用自：宋沄劍SQL Server索引中的碎片和填充因子）
基本上所有解決辦法都是基于對索引的重建和整理，只是方式不同
1.刪除索引并重建
這種方式并不好.在刪除索引期間，索引不可用.會(huì)導(dǎo)致阻塞發(fā)生。而對于刪除聚集索引，則會(huì)導(dǎo)致對應(yīng)的非聚集索引重建兩次(刪除時(shí)重建，建立時(shí)再重建).雖然這種方法并不好，但是對于索引的整理最為有效
2.使用DROP_EXISTING語句重建索引
為了避免重建兩次索引，使用DROP_EXISTING語句重建索引，因?yàn)檫@個(gè)語句是原子性的，不會(huì)導(dǎo)致非聚集索引重建兩次，但同樣的，這種方式也會(huì)造成阻塞
3.如前面文章所示，使用ALTER INDEX REBUILD語句重建索引
使用這個(gè)語句同樣也是重建索引，但是通過動(dòng)態(tài)重建索引而不需要卸載并重建索引.是優(yōu)于前兩種方法的，但依舊會(huì)造成阻塞?？梢酝ㄟ^ONLINE關(guān)鍵字減少鎖，但會(huì)造成重建時(shí)間加長.
4.使用ALTER INDEX REORGANIZE
這種方式不會(huì)重建索引，也不會(huì)生成新的頁，僅僅是整理，當(dāng)遇到加鎖的頁時(shí)跳過，所以不會(huì)造成阻塞。但同時(shí)，整理效果會(huì)差于前三種.
當(dāng)隨著表的數(shù)據(jù)量不斷增長，很多存儲(chǔ)的數(shù)據(jù)進(jìn)行了不適當(dāng)?shù)目珥摚╯qlserver中存儲(chǔ)的最小單位是頁，頁是不不可再分的），會(huì)產(chǎn)生很多索引的碎片。這時(shí)候需要重建索引來提高查詢性能。
如何查看索引的使用情況：
SELECT index_type_desc,alloc_unit_type_desc,avg_fragmentation_in_percent,fragment_count,avg_fragment_size_in_pages,page_count,record_count,avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID('db_name'),OBJECT_ID('table_name),NULL,NULL,'Sampled')
上面的語句是查詢數(shù)據(jù)庫db_name的表table_name的索引使用情況。
查詢結(jié)果中的列avg_fragment_size_in_pages值超過40%就需要重建索引,可以減少IO掃描操作。
重建索引：
alter index pk_my_users on my_users rebuild;
測試結(jié)果：
原來的碎片達(dá)到89%，重建索引碎片降到2%，查詢速度快了1倍。（數(shù)據(jù)量為百萬級）
SQL Server索引語法 <第四篇>
從CREATE開始
通過顯式的CREATE INDEX命令
在創(chuàng)建約束時(shí)作為隱含的對象
隨約束創(chuàng)建的隱含索引
當(dāng)向表中添加如下兩種約束之一時(shí)，就會(huì)創(chuàng)建隱含索引。
主鍵約束(聚集索引)
唯一約束(唯一索引)
一、CREATE INDEX語法
CREATE INDEX語句所做的事情與其聽上去一樣-用于在指定表或視圖上基于聲明的列創(chuàng)建索引:
CREATE [UNIQUE] [CLUSTERED | NONCLUSTERED]
INDEX <index name> ON <table or view name>(<column name> [ASC|DESC][,...n])
INCLUDE (<column name> [,...n])
[
WITH
[PAD_INDEX = {ON | OFF}]
[[,] FILLFACTOR = <fillfactor>]
[[,] IGNORE_DUR_KEY = {ON | OFF}]
[[,] DROP_EXISTING = {ON | OFF}]
[[,] STATISTICS_NORECOMPUTE = {ON | OFF}]
[[,] SORT_IN_TEMPDB = {ON | OFF}]
[[,] ONLINE = {ON | OFF}]
[[,] ALLOW_ROW_LOCKS = {ON | OFF}]
[[,] ALLOW_PAGE_LOCKS = {ON | OFF}]
[[,] MAXDOP = <maxinum degree of parallelism>
]
[ON {<filegroup> | <partition scheme name> | DEFAULT}]
CREATE INDEX語句必須隨表或者視圖出現(xiàn)，并且需要聲明列所在(ON)的表。下面解釋個(gè)選項(xiàng)的作用
1、ASC/DESC
這兩個(gè)選項(xiàng)允許為索引選擇升序和降序排列順序。默認(rèn)選項(xiàng)為ASC，它是升序。
為什么需要升序和降序兩個(gè)選項(xiàng)呢？不是反序查看索引不就行了嗎？但是如果一列按升序排列，但是其他列要求按降序排列，怎么辦呢？因?yàn)樗饕牧惺谴鎯?chǔ)在一起的，所以對一列反向查看索引也將倒轉(zhuǎn)其他列的順序。如果顯示地聲明某一列是升序，而另一列是降序，那么將直接在索引的物理數(shù)據(jù)中倒轉(zhuǎn)第二列-突然間就不必改變訪問數(shù)據(jù)的方式了。
2、INCLUDE
這是SQL Server2005及后續(xù)版本支持的選項(xiàng)。它的目的是為覆蓋查詢(covered queries)提供更好的支持。
當(dāng)包含(INCLUDE)列而不是將列放在ON列表上時(shí)，SQL Server僅僅在索引的葉級上添加它們。因?yàn)樵谒饕~級上的每一行對應(yīng)于一個(gè)數(shù)據(jù)行，所以所做的事情在本質(zhì)上是將更多的原始數(shù)據(jù)包含在索引的葉級上。這樣做有一個(gè)好處，因?yàn)镾QL Server在有了它實(shí)際需要的內(nèi)容就停止工作。SQL Server在遍歷索引時(shí)沒有繼續(xù)訪問實(shí)際的數(shù)據(jù)行就找到所需的所有數(shù)據(jù)，那么就不必再到達(dá)數(shù)據(jù)行。通過在索引中包含特定的列，可以在葉級“覆蓋”利用該特定索引的查詢，從而節(jié)省了與使用索引指針到達(dá)數(shù)據(jù)頁相關(guān)的I/O。實(shí)際是，比如你為一個(gè)日期列創(chuàng)建索引，但是INCLUDE一個(gè)訂單ID列。那么查找某日期的訂單ID，就不必再到實(shí)際數(shù)據(jù)行了，因?yàn)樵谒饕芯陀辛怂璧臄?shù)據(jù)。但是注意不要濫用該選項(xiàng)，當(dāng)包含列時(shí)，將增加索引頁的葉級的大小。這意味著每頁中的行數(shù)將更少，因此需要更多的I/O來查看相同數(shù)量的行。結(jié)果可能是，加快了一個(gè)查詢的同時(shí)可能減慢了其他的查詢。要考慮對系統(tǒng)各個(gè)部分的影響，而不是僅僅考慮某個(gè)時(shí)候正在使用的特定查詢。
3、WITH
WITH非常簡單-它只是告訴SQL Server將要提供一個(gè)或者多個(gè)跟在后面的選項(xiàng)。
4、PAD_INDEX
該選項(xiàng)確定了第一次創(chuàng)建索引時(shí)，索引的非葉級頁將有多滿(用百分比表示)。不用在PAD_INDEX中聲明百分比，因?yàn)閷⑹褂煤竺娴腇ILLTACTOR選項(xiàng)指定的百分比。設(shè)置不帶有FILLFACTOR選項(xiàng)的PAD_INDEX=ON將是沒有意義的。
5、FILLFACTOR
當(dāng)SQL Server第一次創(chuàng)建索引時(shí)，默認(rèn)情況下將盡可能地將頁填滿，僅留兩個(gè)記錄的控件，可以將FILLTACTOE設(shè)置為在0-100之間的任意值。一旦索引構(gòu)造完成，這個(gè)數(shù)字將表示頁相對滿的程度的百分比。但是在進(jìn)行頁拆分時(shí)，數(shù)據(jù)將仍然在兩頁之間對半分布-除了定期重建索引外，不能不斷地控制填充百分比。
當(dāng)需要調(diào)整頁密度的時(shí)候，使用FILLTACTOR需要從以下幾方面考慮：
如果是OLTP系統(tǒng)(經(jīng)常添加和刪除)，那么需要較低的FILLFACTOR。
如果是OLAP或者其他非常穩(wěn)定(幾乎沒有添加和刪除)的系統(tǒng)，那么需要盡可能高的FILLFACTOR。
如果事務(wù)比例中等，且有很多基于它的報(bào)表類型查詢，那么可能需要中等水平的FILLFACTOR(不太低，也不太高)。
如果沒有提供值，那么SQL Server將把頁填充至差兩行滿為止，同時(shí)保證每頁至少有一行。(如果行是8000字符寬，那么每頁只能放一行，所以無法達(dá)到差兩行滿)。
6、IGNORE_DUP_KEY
IGNORE_DUP_KEY選項(xiàng)幾乎是一種回避系統(tǒng)的方法。簡而言之，它使得唯一約束與其應(yīng)有的操作方式有些不同。
通常，唯一約束(或唯一索引)不允許任何種類的重復(fù)-如果事務(wù)嘗試基于定義為唯一的列創(chuàng)建重復(fù)值，那么事務(wù)將被回滾并且拒絕。然而，一旦設(shè)置了IGNORE_DUP_KEY選項(xiàng)，就將得到混合的行為。仍然接收錯(cuò)誤信息，但是錯(cuò)誤將僅僅是一種警告-記錄仍然沒有被插入。
從IGNORE_DUP_KEY的角度看，不能會(huì)事務(wù)進(jìn)行回滾(錯(cuò)誤仍是警告錯(cuò)誤，而不是關(guān)鍵錯(cuò)誤)，但重復(fù)的行將被拒絕。
一句話，這個(gè)東西的態(tài)度是，重復(fù)行完全沒問題，但是你要有一個(gè)該值的行存在就OK了(插入時(shí)，重復(fù)行被忽略，還是全部都不允許插入)。
當(dāng)你創(chuàng)建唯一索引時(shí)，你可以指定IGNORE_DUP_KEY選項(xiàng)，因此本文最開始創(chuàng)建唯一索引的選項(xiàng)可以是:
CREATE UNIQUE NONCLUSTERED INDEX AK_Product_Name ON Production.Product ( [Name] ) WITH ( IGNORE_DUP_KEY = OFF );
IGNORE_DUP_KEY這個(gè)名字容易讓人誤會(huì)。唯一索引存在時(shí)重復(fù)的值永遠(yuǎn)不會(huì)被忽略。更準(zhǔn)確的說，唯一索引中永遠(yuǎn)不允許存在重復(fù)鍵。這個(gè)選項(xiàng)的作用僅僅是在多列插入時(shí)有用。
比如，你有兩個(gè)表，表A和表B，有著完全相同的結(jié)構(gòu)。你可能提交如下語句給SQL Server。
INSERT INTO TableA SELECT * FROM TableB;
SQL Server會(huì)嘗試將所有表B中的數(shù)據(jù)插入表A。但如果因?yàn)槲ㄒ凰饕芙^表B中含有和表A相同的數(shù)據(jù)插入A怎么辦？你是希望僅僅重復(fù)數(shù)據(jù)插入不成功，還是整個(gè)INSERT語句不成功？
這個(gè)取決于你設(shè)定的IGNORE_DUP_KEY參數(shù)，當(dāng)你創(chuàng)建唯一索引時(shí)，通過設(shè)置設(shè)個(gè)參數(shù)可以設(shè)定當(dāng)插入不成功時(shí)怎么辦，設(shè)置IGNORE_DUP_KEY的兩種參數(shù)解釋如下:
IGNORE_DUP_KEY=OFF
整個(gè)INSERT語句都不會(huì)成功并彈出錯(cuò)誤提示，這也是默認(rèn)設(shè)置。
IGNORE_DUP_KEY=OFF
只有那些具有重復(fù)鍵的行不成功，其它所有的行會(huì)成功。并彈出警告信息。
IGNORE_DUP_KEY 選項(xiàng)僅僅影響插入語句。而不會(huì)被UPDATE,CREATE INDEX,ALTER INDEX所影響。這個(gè)選項(xiàng)也可以在設(shè)置主鍵和唯一約束時(shí)進(jìn)行設(shè)置。
7、DROP_EXISTING
如果指定DROP_EXISTING選項(xiàng)，那么如果之前已經(jīng)存在同名索引將在構(gòu)造新索引之前被刪除。當(dāng)和群集索引一起使用該選項(xiàng)時(shí)，這個(gè)選項(xiàng)比簡單刪除并重新創(chuàng)建現(xiàn)有的索引更加有效。如果重新創(chuàng)建與現(xiàn)有索引完全匹配的索引，那么SQL Server知道它不需要涉及非群集索引，然而為了適應(yīng)不同的行位置，顯式刪除和創(chuàng)建將導(dǎo)致重新構(gòu)建所有非群集索引兩次。如果使用DROP_EXISTING改變索引的結(jié)構(gòu)，那么NCI只被重新構(gòu)建一次，而不是兩次。
8、STATISTICS_NORECOMPUTE
默認(rèn)情況下，SQL Server試圖自動(dòng)化在表和索引上更新統(tǒng)計(jì)信息的過程。通過選擇該選項(xiàng)，表示將由自己手動(dòng)負(fù)責(zé)更新統(tǒng)計(jì)信息。為了關(guān)閉這個(gè)選項(xiàng)，需要運(yùn)行UPDATESTATISTICS命令，但不使用NORECOMPUTE。
強(qiáng)烈建議不要使用該選項(xiàng)，因?yàn)椴樵儍?yōu)化器使用索引上的統(tǒng)計(jì)信息來指出索引對于給定的查詢有多大用處。隨著表中數(shù)據(jù)大量增多或減少，以及列特定值改變。索引上的統(tǒng)計(jì)信息會(huì)不斷變化?；谶@兩點(diǎn)，可以知道不更新統(tǒng)計(jì)信息則查詢優(yōu)化器將基于過時(shí)的信息運(yùn)行查詢，打開自動(dòng)統(tǒng)計(jì)信息功能意味著統(tǒng)計(jì)信息將周期地更新(多長時(shí)間更新一次取決于對表更新的本質(zhì)和頻繁程度)。相反關(guān)閉自動(dòng)更新統(tǒng)計(jì)信息意味著信息會(huì)過時(shí)，或者需要設(shè)定計(jì)劃手動(dòng)運(yùn)行UPDATE STATISTICS。
9、SORT_IN_TEMPDB
只有在tempdb存儲(chǔ)在與包含新索引的數(shù)據(jù)庫物理上分離的驅(qū)動(dòng)器上時(shí)，該選項(xiàng)才有意義。為什么？
當(dāng)SQL Server建立索引時(shí)，它必須執(zhí)行多個(gè)讀操作以處理各種索引構(gòu)造步驟。
1、遍歷所有的數(shù)據(jù)，構(gòu)建對應(yīng)于實(shí)際數(shù)據(jù)每一行的葉行。類似于實(shí)際數(shù)據(jù)和最后的索引，這些內(nèi)容進(jìn)入用于臨時(shí)存儲(chǔ)的頁。這些中間頁不是最終的索引頁，而是每次排序緩沖器已滿時(shí)臨時(shí)存儲(chǔ)的位置。
2、通過這些中間頁單獨(dú)運(yùn)行，以將他們合并到最終葉級頁。
3、當(dāng)填充葉級頁時(shí)，構(gòu)建非葉級頁。
如果沒有使用SORT_IN_TEMPDB選項(xiàng)，那么中間頁將被寫入在其中存儲(chǔ)數(shù)據(jù)庫的相同物理文件中。這意味著實(shí)際數(shù)據(jù)的讀操作必須與構(gòu)建過程的寫操作競爭。這兩種情況造成磁頭需要移動(dòng)到一個(gè)不同的位置(讀和寫)。結(jié)果是磁頭經(jīng)常地來回移動(dòng)-這會(huì)花費(fèi)時(shí)間。
另一方面，如果使用SORT_IN_TEMPDB，那么中間頁將被寫入tempdb中，而不是數(shù)據(jù)庫自己的文件。如果它們在單獨(dú)的物理驅(qū)動(dòng)器上，這意味著在索引構(gòu)建的讀和寫操作之間沒有競爭。但是要牢記，只有在tempdb位于與數(shù)據(jù)庫文件分離的獨(dú)立物理驅(qū)動(dòng)器上，這才會(huì)有效。否則，只是名義上發(fā)生改變，而I/O競爭仍然是問題。
如果要使用SORT_IN_TEMPDB，那么確保在tempdb中有用于支持大文件的足夠空間。
10、ONLINE
如果將這個(gè)選項(xiàng)設(shè)置為ON，那么它將強(qiáng)制表對于一般的訪問保持有效，并且不創(chuàng)建任何阻止用戶使用索引和/表的鎖。默認(rèn)情況下，全索引操作將獲得所需的鎖(最終得到表鎖)，以便對表進(jìn)行完全和有效的訪問，然而，副作用是這將會(huì)阻止用戶(這是矛盾的：一方面可能正在建立索引以使數(shù)據(jù)庫更為有用，但是同時(shí)又使表變得不可用)。
11、ALLOW ROW/PAGE LOCKS
這里的ALLOW設(shè)置用于確定索引是否允許行鎖和頁鎖。
12、MAXDOP
該選項(xiàng)用于為構(gòu)建索引覆蓋關(guān)于最大并行度的系統(tǒng)設(shè)置。并行度是指將有多少個(gè)進(jìn)程用于一個(gè)數(shù)據(jù)庫操作。有一個(gè)稱為最大并行度的系統(tǒng)設(shè)置，允許限制每個(gè)操作中的處理器數(shù)。索引創(chuàng)建的MAXDOP選項(xiàng)允許將并行度設(shè)置為高于或者低于基本系統(tǒng)設(shè)置。只要合適就行。
13、ON
SQL Server允許通過使用ON選項(xiàng)將數(shù)據(jù)和索引單獨(dú)存放。這樣做有以下優(yōu)點(diǎn)：
索引需要的空間可以分散到其他的驅(qū)動(dòng)器中。
用于索引操作的I/O不會(huì)加重物理數(shù)據(jù)檢索的負(fù)擔(dān)。
下面簡單補(bǔ)充下XML索引的概念。
XML索引是SQL Server2005新增功能。
除了IGNORE_DUP_KEY和ONLINE之外，XML的創(chuàng)建語法支持前面的CREATE語句中所看到的所有相同選項(xiàng)。
在SQL Server中，可以再類型為XML的列上創(chuàng)建索引。這樣做的主要要求如下。
在包含需要索引的XML的表上必須具有群集索引。
在創(chuàng)建“輔助”索引之前，必須先在XML數(shù)據(jù)列上創(chuàng)建“主”XML索引。
XML索引只能放在XML類型的列上創(chuàng)建(而且XML索引是可以再改類型的列上創(chuàng)建的唯一一種索引)。
XML列必須是基表的一部分-不能在視圖上創(chuàng)建索引。
1、主XML索引
在XML索引上創(chuàng)建的第一個(gè)索引必須聲明為"主索引"。當(dāng)創(chuàng)建主索引時(shí)，SQL Server創(chuàng)建一個(gè)新的群集索引，這個(gè)群集索引將基表的群集索引和來自任何指定的XML節(jié)點(diǎn)的數(shù)據(jù)組合在一起。
2、輔助XML索引
類似于指向群集索引的群集鍵的非群集索引，輔助XML索引以很相似的方法指向主XML索引。一旦創(chuàng)建了主XML索引，就只能在XML列上創(chuàng)建多達(dá)248個(gè)以上的XML索引。
二、修改索引
ALTER INDEX命令在其用來做什么方面多少有些欺騙性。截止到現(xiàn)在，ALTER命令總是與修改對象的定義有關(guān)。例如ALTER表以添加或禁用約束和列。ALTER INDEX是不同的-該命令與維護(hù)有關(guān)，而與結(jié)構(gòu)完全不相干。如果需修改索引的組成，那么只能DROP然后CREATE索引，或者用DROP_EXISTING=ON選項(xiàng)CREATE并使用索引。
ALTER INDEX的語法類似于下面這樣：
ALTER INDEX {<name of index> | ALL}
ON<table or view name>
{ REBUILD
[[ WITH (
[PAD_INDEX = {ON | OFF}]
| [[,] FILLFACTOR = <fillfactor>
| [[,] SORT_IN_TEMPDB = { ON | OFF }]
| [[,] IGNORE_DUP_KEY = { ON | OFF }]
| [[,] STATISTICS_NORECOMPUTE = { ON | OFF }]
| [[,] ONLINE = { ON| OFF }]
| [[,] ALLOW_ROW_LOCKS = { ON | OFF }]
| [[,] ALLOW_PAGE_LOCKS = { ON | OFF }]
| [[,] MAXDOP = <max degree of parallelism>
)]
|[ PARTITION = <partition number>
[ WITH (< partition rebuild index option>
[,...N])]]]
| DISABLE
| REORGANIZE
[ PARTITION = <partition number> ]
[ WITH (LOB_COMPACTION = { ON | OFF })]
| SET ([ ALLOW_ROW_LOCKS = { ON | OFF} ]
| [[,] ALLOW_PAGE_LOCKS = { ON | OFF } ]
| [[,] IGNORE_DUP_KEY = { ON | OFF } ]
| [[,] STATISTICS_NORECOMPUTE = { ON | OFF }]
)
}[;]
其中一些選項(xiàng)與CREATE INDEX命令相同，因此這里將略過對這些選項(xiàng)的重新定義。除此之外，相當(dāng)多的ALTER特定選項(xiàng)都是細(xì)節(jié)性的，且與處理碎片之類的事情有關(guān)。下面解釋下參數(shù)
1、索引名
如果想維護(hù)一個(gè)特定的索引可以指定該索引，或者使用ALL表明想要維護(hù)與指定的表相關(guān)聯(lián)的所有索引。
2、表名或視圖名
要在其上維護(hù)的特定對象(表或視圖)的名稱。注意，必須是一個(gè)特定的表(可以給它提供一個(gè)列表，然后說“請?zhí)幚硭羞@些！”)。
3、REBULD
如果使用該選項(xiàng)運(yùn)行ALTER INDEX，那么將完全丟棄舊的索引并重新生成新的索引。結(jié)果是真正優(yōu)化的索引，其中所有葉級和非葉級的頁都按照定義進(jìn)行了重新構(gòu)建。如果是群集索引，那么也會(huì)重新組織物理數(shù)據(jù)。
默認(rèn)情況下，頁將被重新組織為差兩行滿。和CREATE TABLE語法一樣，可以將FILLFACTOR設(shè)置為0~100之前的任何值。該值是在數(shù)據(jù)庫完成重新組織后頁被填滿的程度(以百分比表示)。但在進(jìn)行頁拆分時(shí)，數(shù)據(jù)將被對半分部在兩個(gè)頁上-除了定期重建索引外，不得不斷控制填充的百分比。
要小心使用該選項(xiàng)，一旦開始REBUILD，在完成索引重建錢，正在使用的索引實(shí)際上就沒有了。依賴該索引的所有查詢可能會(huì)變得異常慢。對于這類事情，首先需要在離線系統(tǒng)上測試，以了解整個(gè)過程將花多少時(shí)間。然后，計(jì)劃在非高峰時(shí)段運(yùn)行。
4、DISABLE
該選項(xiàng)名副其實(shí)，只是方式有些過激。如果該命令的全部作用只是為了讓索引離線，直至您決定了進(jìn)一步要做什么，則它是不錯(cuò)的選擇，但它實(shí)際會(huì)把索引標(biāo)記為不可用，一旦禁用了某個(gè)索引，在重新激活之前，必須重建索引(不是重新組織，而是重建)。
如果對表禁用了群集索引，那么也會(huì)禁用表。數(shù)據(jù)仍會(huì)保留，但在重建群集索引錢，不能被所有索引(因?yàn)樗麄兌家蕾嚾杭饕?訪問。
5、REORGANIZE
如果重新組織索引，就得到了比完全重建索引稍遜一點(diǎn)的完全優(yōu)化，但這種方法可以聯(lián)機(jī)進(jìn)行(用戶仍能使用索引)。
稍遜一點(diǎn)指的是什么？其實(shí)是REORGANIZE只在索引的葉級起作用，而不觸及非葉級。這意味著未獲得完全優(yōu)化。但是，對于大部分的索引而言，那不是真正產(chǎn)生碎片的地方。
三、刪除索引
如果不斷地重新分析情況和添加索引，那么也不要忘記刪除索引。記住在插入索引上的系統(tǒng)開銷?！ ?/p>
刪除索引的語法如下：
DROP INDEX <table or view name>.<index name>
這樣就可以刪除索引了。
總結(jié)
以上是生活随笔為你收集整理的MSSQL 重建索引（在线重建、控制最大处理器数 、MAXDOP ）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： android新架构,Android新架
- 下一篇： 简单选择排序（选择排序）