2. 程式人生 > >SQL Server的聚集索引和非聚集索引

SQL Server的聚集索引和非聚集索引

阿新 • • 發佈：2019-01-19

轉載：http://www.cnblogs.com/tuyile006/archive/2009/08/28/1555615.html

微軟的SQL SERVER提供了兩種索引：聚集索引(clustered index，也稱聚類索引、簇集索引)和非聚集索引(nonclustered index，也稱非聚類索引、非簇集索引)…… 

　　(一)深入淺出理解索引結構 

　　實際上，您可以把索引理解為一種特殊的目錄。微軟的SQL SERVER提供了兩種索引：聚集索引(clustered index，也稱聚類索引、簇集索引)和非聚集索引(nonclustered index，也稱非聚類索引、非簇集索引)。下面，我們舉例來說明一下聚集索引和非聚集索引的區別： 


　　其實，我們的漢語字典的正文字身就是一個聚集索引。比如，我們要查“安”字，就會很自然地翻開字典的前幾頁，因為“安”的拼音是“an”，而按 照拼音排序漢字的字典是以英文字母“a”開頭並以“z”結尾的，那麼“安”字就自然地排在字典的前部。如果您翻完了所有以“a”開頭的部分仍然找不到這個 字，那麼就說明您的字典中沒有這個字;同樣的，如果查“張”字，那您也會將您的字典翻到最後部分，因為“張”的拼音是“zhang”。也就是說，字典的正 文部分本身就是一個目錄，您不需要再去查其他目錄來找到您需要找的內容。 

　　我們把這種正文內容本身就是一種按照一定規則排列的目錄稱為“聚集索引”。 

　　如果您認識某個字，您可以快速地從自典中查到這個字。但您也可能會遇到您不認識的字，不知道它的發音，這時候，您就不能按照剛才的方法找到您要 查的字，而需要去根據“偏旁部首”查到您要找的字，然後根據這個字後的頁碼直接翻到某頁來找到您要找的字。但您結合“部首目錄”和“檢字表”而查到的字的 排序並不是真正的正文的排序方法，比如您查“張”字，我們可以看到在查部首之後的檢字表中“張”的頁碼是672頁，檢字表中“張”的上面是“馳”字，但頁 碼卻是63頁，“張”的下面是“弩”字，頁面是390頁。很顯然，這些字並不是真正的分別位於“張”字的上下方，現在您看到的連續的“馳、張、弩”三字實 際上就是他們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的對映。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的 結果，然後再翻到您所需要的頁碼。 


　　我們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱為“非聚集索引”。 

　　通過以上例子，我們可以理解到什麼是“聚集索引”和“非聚集索引”。 

　　進一步引申一下，我們可以很容易的理解：每個表只能有一個聚集索引，因為目錄只能按照一種方法進行排序。 

　　(二)何時使用聚集索引或非聚集索引 

　　下面的表總結了何時使用聚集索引或非聚集索引(很重要)。 


動作描述                           使用聚集索引 使用非聚集索引 
外來鍵列                                 應                    應 
主鍵列                                 應                      應 

列經常被分組排序(order by) 應                    應 
返回某範圍內的資料              應                   不應 
小數目的不同值                   應                     不應 
大數目的不同值                     不應                應 
頻繁更新的列                      不應               應 
頻繁修改索引列                  不應                應 
一個或極少不同值              不應                不應 

　　事實上，我們可以通過前面聚集索引和非聚集索引的定義的例子來理解上表。如：返回某範圍內的資料一項。比如您的某個表有一個時間列，恰好您把 聚合索引建立在了該列，這時您查詢2004年1月1日至2004年10月1日之間的全部資料時，這個速度就將是很快的，因為您的這本字典正文是按日期進行 排序的，聚類索引只需要找到要檢索的所有資料中的開頭和結尾資料即可;而不像非聚集索引，必須先查到目錄中查到每一項資料對應的頁碼，然後再根據頁碼查到 具體內容。 

　(三)結合實際，談索引使用的誤區 

　　理論的目的是應用。雖然我們剛才列出了何時應使用聚集索引或非聚集索引，但在實踐中以上規則卻很容易被忽視或不能根據實際情況進行綜合分析。下面我們將根據在實踐中遇到的實際問題來談一下索引使用的誤區，以便於大家掌握索引建立的方法。 

　　1、主鍵就是聚集索引 

　　這種想法筆者認為是極端錯誤的，是對聚集索引的一種浪費。雖然SQL SERVER預設是在主鍵上建立聚集索引的。 

　　通常，我們會在每個表中都建立一個ID列，以區分每條資料，並且這個ID列是自動增大的，步長一般為1。我們的這個辦公自動化的例項中的列 Gid就是如此。此時，如果我們將這個列設為主鍵，SQL SERVER會將此列預設為聚集索引。這樣做有好處，就是可以讓您的資料在資料庫中按照ID進行物理排序，但筆者認為這樣做意義不大。 

　　顯而易見，聚集索引的優勢是很明顯的，而每個表中只能有一個聚集索引的規則，這使得聚集索引變得更加珍貴。 

　　從我們前面談到的聚集索引的定義我們可以看出，使用聚集索引的最大好處就是能夠根據查詢要求，迅速縮小查詢範圍，避免全表掃描。在實際應用中， 因為ID號是自動生成的，我們並不知道每條記錄的ID號，所以我們很難在實踐中用ID號來進行查詢。這就使讓ID號這個主鍵作為聚集索引成為一種資源浪 費。其次，讓每個ID號都不同的欄位作為聚集索引也不符合“大數目的不同值情況下不應建立聚合索引”規則;當然，這種情況只是針對使用者經常修改記錄內容， 特別是索引項的時候會負作用，但對於查詢速度並沒有影響。 

　　在辦公自動化系統中，無論是系統首頁顯示的需要使用者簽收的檔案、會議還是使用者進行檔案查詢等任何情況下進行資料查詢都離不開欄位的是“日期”還有使用者本身的“使用者名稱”。 

　　通常，辦公自動化的首頁會顯示每個使用者尚未簽收的檔案或會議。雖然我們的where語句可以僅僅限制當前使用者尚未簽收的情況，但如果您的系統已 建立了很長時間，並且資料量很大，那麼，每次每個使用者開啟首頁的時候都進行一次全表掃描，這樣做意義是不大的，絕大多數的使用者1個月前的檔案都已經瀏覽過 了，這樣做只能徒增資料庫的開銷而已。事實上，我們完全可以讓使用者開啟系統首頁時，資料庫僅僅查詢這個使用者近3個月來未閱覽的檔案，通過“日期”這個欄位 來限制表掃描，提高查詢速度。如果您的辦公自動化系統已經建立的2年，那麼您的首頁顯示速度理論上將是原來速度8倍，甚至更快。 

　　在這裡之所以提到“理論上”三字，是因為如果您的聚集索引還是盲目地建在ID這個主鍵上時，您的查詢速度是沒有這麼高的，即使您在“日期”這個 欄位上建立的索引(非聚合索引)。下面我們就來看一下在1000萬條資料量的情況下各種查詢的速度表現(3個月內的資料為25萬條)： 

　　(1)僅在主鍵上建立聚集索引，並且不劃分時間段： 

　　Select gid,fariqi,neibuyonghu,title from tgongwen 

　　用時：128470毫秒(即：128秒) 

　　(2)在主鍵上建立聚集索引，在fariq上建立非聚集索引： 

　　select gid,fariqi,neibuyonghu,title from Tgongwen 

　　where fariqi> dateadd(day,-90,getdate()) 

　　用時：53763毫秒(54秒) 

　　(3)將聚合索引建立在日期列(fariqi)上： 

　　select gid,fariqi,neibuyonghu,title from Tgongwen 

　　where fariqi> dateadd(day,-90,getdate()) 

　　用時：2423毫秒(2秒) 

　　雖然每條語句提取出來的都是25萬條資料，各種情況的差異卻是巨大的，特別是將聚集索引建立在日期列時的差異。事實上，如果您的資料庫真的有 1000萬容量的話，把主鍵建立在ID列上，就像以上的第1、2種情況，在網頁上的表現就是超時，根本就無法顯示。這也是我摒棄ID列作為聚集索引的一個 最重要的因素。 

　　得出以上速度的方法是：在各個select語句前加： 

　　declare @d datetime 

　　set @d=getdate() 

　　並在select語句後加： 

　　select [語句執行花費時間(毫秒)]=datediff(ms,@d,getdate()) 

　2、只要建立索引就能顯著提高查詢速度 

　　事實上，我們可以發現上面的例子中，第2、3條語句完全相同，且建立索引的欄位也相同;不同的僅是前者在fariqi欄位上建立的是非聚合索引，後者在此欄位上建立的是聚合索引，但查詢速度卻有著天壤之別。所以，並非是在任何欄位上簡單地建立索引就能提高查詢速度。 

　　從建表的語句中，我們可以看到這個有著1000萬資料的表中fariqi欄位有5003個不同記錄。在此欄位上建立聚合索引是再合適不過了。在 現實中，我們每天都會發幾個檔案，這幾個檔案的發文日期就相同，這完全符合建立聚集索引要求的：“既不能絕大多數都相同，又不能只有極少數相同”的規則。 由此看來，我們建立“適當”的聚合索引對於我們提高查詢速度是非常重要的。 

　　3、把所有需要提高查詢速度的欄位都加進聚集索引，以提高查詢速度 

　　上面已經談到：在進行資料查詢時都離不開欄位的是“日期”還有使用者本身的“使用者名稱”。既然這兩個欄位都是如此的重要，我們可以把他們合併起來，建立一個複合索引(compound index)。 

　　很多人認為只要把任何欄位加進聚集索引，就能提高查詢速度，也有人感到迷惑：如果把複合的聚集索引欄位分開查詢，那麼查詢速度會減慢嗎?帶著這 個問題，我們來看一下以下的查詢速度(結果集都是25萬條資料)：(日期列fariqi首先排在複合聚集索引的起始列，使用者名稱neibuyonghu排在 後列) 

　　(1)select gid,fariqi,neibuyonghu,title from Tgongwen 

　　where fariqi>'2004-5-5' 

　　查詢速度：2513毫秒 

　　(2)select gid,fariqi,neibuyonghu,title from Tgongwen 

　　where fariqi>'2004-5-5' and neibuyonghu='辦公室' 

　　查詢速度：2516毫秒 

　　(3)select gid,fariqi,neibuyonghu,title from Tgongwen 

　　where neibuyonghu='辦公室' 

　　查詢速度：60280毫秒 

　　從以上試驗中，我們可以看到如果僅用聚集索引的起始列作為查詢條件和同時用到複合聚集索引的全部列的查詢速度是幾乎一樣的，甚至比用上全部的復 合索引列還要略快(在查詢結果集數目一樣的情況下);而如果僅用複合聚集索引的非起始列作為查詢條件的話，這個索引是不起任何作用的。當然，語句1、2的 查詢速度一樣是因為查詢的條目數一樣，如果複合索引的所有列都用上，而且查詢結果少的話，這樣就會形成“索引覆蓋”，因而效能可以達到最優。同時，請記 住：無論您是否經常使用聚合索引的其他列，但其前導列一定要是使用最頻繁的列。 

　　(四)其他書上沒有的索引使用經驗總結 

　　1、用聚合索引比用不是聚合索引的主鍵速度快 

　　下面是例項語句：(都是提取25萬條資料) 

　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen 

　　where fariqi='2004-9-16' 

　　使用時間：3326毫秒 

　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid<=250000 

　　使用時間：4470毫秒 

　　這裡，用聚合索引比用不是聚合索引的主鍵速度快了近1/4。 

　　2、用聚合索引比用一般的主鍵作order by時速度快，特別是在小資料量情況下 

　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by fariqi 

　　用時：12936 

　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by gid 

　　用時：18843 

　　這裡，用聚合索引比用一般的主鍵作order by時，速度快了3/10。事實上，如果資料量很小的話，用聚集索引作為排序列要比使用非聚集索引速度快得明顯的多;而資料量如果很大的話，如10萬以上，則二者的速度差別不明顯。 

　　3、使用聚合索引內的時間段，搜尋時間會按資料佔整個資料表的百分比成比例減少，而無論聚合索引使用了多少個 

　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen 

　　where fariqi>'2004-1-1' 

　　用時：6343毫秒(提取100萬條) 

　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen 

　　where fariqi>'2004-6-6' 

　　用時：3170毫秒(提取50萬條) 

　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen 

　　where fariqi='2004-9-16' 

　　用時：3326毫秒(和上句的結果一模一樣。如果採集的數量一樣，那麼用大於號和等於號是一樣的) 

　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen 

　　where fariqi>'2004-1-1' and fariqi<'2004-6-6' 

　　用時：3280毫秒 

　　4 、日期列不會因為有分秒的輸入而減慢查詢速度 

　　下面的例子中，共有100萬條資料，2004年1月1日以後的資料有50萬條，但只有兩個不同的日期，日期精確到日;之前有資料50萬條，有5000個不同的日期，日期精確到秒。 

　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen 

　　where fariqi>'2004-1-1' order by fariqi 

　　用時：6390毫秒 

　　select gid,fariqi,neibuyonghu,reader,title from Tgongwen 

　　where fariqi<'2004-1-1' order by fariqi 

　　用時：6453毫秒 

　　(五)其他注意事項 

　　“水可載舟，亦可覆舟”，索引也一樣。索引有助於提高檢索效能，但過多或不當的索引也會導致系統低效。過多的索引甚至會導致索引碎片。 

　　索引是從資料庫中獲取資料的最高效方式之一。95%的資料庫效能問題都可以採用索引技術得到解決。 

　　1. 不要索引常用的小型表 

　　不要為小型資料表設定任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。 

　　2. 不要把社會保障號碼(SSN)或身份證號碼(ID)選作鍵 

　　永遠都不要使用 SSN 或 ID 作為資料庫的鍵。除了隱私原因以外，SSN 或 ID 需要手工輸入。永遠不要使用手工輸入的鍵作為主鍵，因為一旦你輸入錯誤，你唯一能做的就是刪除整個記錄然後從頭開始。 

　　3. 不要用使用者的鍵 

　　在確定採用什麼欄位作為表的鍵的時候，可一定要小心使用者將要編輯的欄位。通常的情況下不要選擇使用者可編輯的欄位作為鍵。這樣做會迫使你採取以下兩個措施： 

　　4. 不要索引 memo/notes 欄位和不要索引大型文字欄位(許多字元) 

　　這樣做會讓你的索引佔據大量的資料庫空間 

　　5. 使用系統生成的主鍵 

　　假如你總是在設計資料庫的時候採用系統生成的鍵作為主鍵，那麼你實際控制了資料庫的索引完整性。這樣，資料庫和非人工機制就有效地控制了對儲存資料中每一行的訪問。 

　　採用系統生成鍵作為主鍵還有一個優點：當你擁有一致的鍵結構時，找到邏輯缺陷很容易。 

　　二、改善SQL語句 

　　很多人不知道SQL語句在SQL SERVER中是如何執行的，他們擔心自己所寫的SQL語句會被SQL SERVER誤解。比如： 

　　select * from table1 where name='zhangsan' and tID > 10000 

　　和執行: 

　　select * from table1 where tID > 10000 and name='zhangsan' 

　　一些人不知道以上兩條語句的執行效率是否一樣，因為如果簡單的從語句先後上看，這兩個語句的確是不一樣，如果tID是一個聚合索引，那麼後一句 僅僅從表的10000條以後的記錄中查詢就行了;而前一句則要先從全表中查詢看有幾個name='zhangsan'的，而後再根據限制條件條件 tID>10000來提出查詢結果。 

　　事實上，這樣的擔心是不必要的。SQL SERVER中有一個“查詢分析優化器”，它可以計算出where子句中的搜尋條件並確定哪個索引能縮小表掃描的搜尋空間，也就是說，它能實現自動優化。 

　　雖然查詢優化器可以根據where子句自動的進行查詢優化，但大家仍然有必要了解一下“查詢優化器”的工作原理，如非這樣，有時查詢優化器就會不按照您的本意進行快速查詢。 

　　在查詢分析階段，查詢優化器檢視查詢的每個階段並決定限制需要掃描的資料量是否有用。如果一個階段可以被用作一個掃描引數(SARG)，那麼就稱之為可優化的，並且可以利用索引快速獲得所需資料。 

　　SARG的定義：用於限制搜尋的一個操作，因為它通常是指一個特定的匹配，一個值得範圍內的匹配或者兩個以上條件的AND連線。形式如下： 

　　列名 操作符 <常數 或 變數> 

　　或 

　　<常數 或 變數> 操作符列名 

　　列名可以出現在操作符的一邊，而常數或變量出現在操作符的另一邊。如： 

　　Name=’張三’ 

　　價格>5000 

　　5000<價格 

　　Name=’張三’ and 價格>5000 

　　如果一個表示式不能滿足SARG的形式，那它就無法限制搜尋的範圍了，也就是SQL SERVER必須對每一行都判斷它是否滿足WHERE子句中的所有條件。所以一個索引對於不滿足SARG形式的表示式來說是無用的。 

　　介紹完SARG後，我們來總結一下使用SARG以及在實踐中遇到的和某些資料上結論不同的經驗： 

　　1、Like語句是否屬於SARG取決於所使用的萬用字元的型別 

　　如：name like ‘張%’ ，這就屬於SARG 

相關推薦

SQL Server的聚集索引和非聚集索引

轉載：http://www.cnblogs.com/tuyile006/archive/2009/08/28/1555615.html 微軟的SQL SERVER提供了兩種索引：聚集索引(clustered index，也稱聚類索引、簇集索引)和非聚集索引(nonclust

MySQL聚集索引和非聚集索引

高效 mar lock 包含 排列 查找 存儲 clust gin 索引分為聚集索引和非聚集索引，mysql中不同的存儲引擎對索引的底層實現可能會不同，這裏只關註mysql的默認存儲引擎InnoDB。 利用下面的命令可以查看默認的存儲引擎 show variables li

聚集索引和非聚集索引

details size font itl spa net blank http href https://blog.csdn.net/zc474235918/article/details/50580639 https://blog.csdn.net/jiadajing2

Innodb，MyIsam,聚集索引和非聚集索引

Innodb和Myisam是什麼和區別 Innodb和Myisam是兩種類型別，在navicat中可以看到，也可以修改。 下面介紹一下他們的區別： 區別 Innodb Myisam

BTREE索引和HASH索引，聚集索引和非聚集索引

https://www.jianshu.com/p/76530afa13cb https://blog.csdn.net/yifanSJ/article/details/79220044 BTREE索引和HASH索引 1、不同引擎的預設索引 不同的引擎對於索引有不同的支援：Innod

SQL server中聚焦索引和非聚焦索引的深度理解

SQL SERVER 聚集索引 非聚集索引 區別 連結 ： https://www.cnblogs.com/gered/p/8078715.html 這篇文章比較精簡的介紹了聚焦索引和非聚焦索引的區別，看完了的話，對於兩種結構有大致的兩個理解。 Sql Server之旅——第三站 解

聚集索引和非聚集索引的特點

2)非聚集索引 ：不影響表中的資料儲存順序，檢索效率比聚集索引低，索引佔用硬碟儲存         空間大（30%~40%），對資料新增/修改/刪除的影響很少。         特點：               (1) 一個表可以最多可以建立249個非聚集索引               (2) 先建聚集索

聚集索引和非聚集索引 簡析與對比

聚集（clustered）索引，也叫聚簇索引 定義：資料行的物理順序與列值（一般是主鍵的那一列）的邏輯順序相同，一個表中只能擁有一個聚集索引。 注：第一列的地址表示該行資料在磁碟中的實體地址，後面三列才是我們SQL裡面用的表裡的列，其中id是主鍵，建立了聚集索引。  &n

聚集索引和非聚集索引的根本區別

根本區別 聚集索引和非聚集索引的根本區別是表記錄的排列順序和與索引的排列順序是否一致。 聚集索引 聚集索引表記錄的排列順序和索引的排列順序一致，所以查詢效率快，只要找到第一個索引值記錄，其餘就連續性的記錄在物理也一樣連續存放。聚集索引對應的缺點就是修改慢，因為為了保證表中記錄的物

聚集索引和非聚集索引的區別

聚集索引和非聚集索引的根本區別是表記錄的排列順序和與索引的排列順序是否一致，聚集索引表記錄的排列順序與索引的排列順序一致，優點是查詢速度快，因為一旦具有第一個索引值的紀錄被找到，具有連續索引值的記錄也一定物理的緊跟其後。聚集索引的缺點是對錶進行修改速度較慢，這是為了保持表中

聚集索引和非聚集索引（整理）

官方說法： 聚集索引 　　一種索引，該索引中鍵值的邏輯順序決定了表中相應行的物理順序。 　　聚集索引確定表中資料的物理順序。聚集索引類似於電話簿，後者按姓氏排列資料。由於聚集索引規定資料在表中的物理儲存順序，因此一個表只能包含一個聚集索引。但該索引可以包含多個列（組合索

聚集索引和非聚集索引（整理） 例項講解

很好的一篇博文，值得轉載。 官方說法： 聚集索引 　　一種索引，該索引中鍵值的邏輯順序決定了表中相應行的物理順序。 　　聚集索引確定表中資料的物理順序。聚集索引類似於電話簿，後者按姓氏排列資料。由於聚集索引規定資料在表中的物理儲存順序，因此一個表只能包含一個聚集索引。但

MySQL的聚集索引和非聚集索引

一. MYSQL的索引 mysql中，不同的儲存引擎對索引的實現方式不同，大致說下MyISAM和InnoDB兩種儲存引擎。 MyISAM的B+Tree的葉子節點上的data，並不是資料本身，而是資料存放的地址。主索引和輔助索引沒啥區別，只是主索引中的key一定得是唯一的。這裡的索引都是非聚簇索引。 MyI

(轉)聚集索引和非聚集索引（整理）

聚集索引 　　一種索引，該索引中鍵值的邏輯順序決定了表中相應行的物理順序。  　　聚集索引確定表中資料的物理順序。聚集索引類似於電話簿，後者按姓氏排列資料。由於聚集索引規定資料在表中的物理儲存順序，因此一個表只能包含一個聚集索引。但該索引可以包含多個列（組合索引），就像電話簿按姓氏和名字進行組織一樣。  　

聚集索引和非聚集索引整理

聚集索引 　　一種索引，該索引中鍵值的邏輯順序決定了表中相應行的物理順序。 　　聚集索引確定表中資料的物理順序。聚集索引類似於電話簿，後者按姓氏排列資料。由於聚集索引規定資料在表中的物理儲存順序，因此一個表只能包含一個聚集索引。但該索引可以包含多個列（組合索引），就像電話簿按姓氏和名字進行組織一樣。 　　

【sqlserver】聚集索引和非聚集索引的比較

非聚集索引不會重新組織表中的資料，而是對每一行儲存索引列值並用一個指標指向資料所在的頁面。（一個值指向多行等於該值的資料）。sqlserver預設情況下建立的索引是非聚集索引。非聚集索引在排序時會對所有的取值進行排序，然後快速找到該值對應的所有資料，達到減少排序時間的效果，不需要全表掃描。

叢集索引和非叢集索引

索引體系結構分為叢集或非叢集。叢集索引是這樣的索引：其在資料頁面中的行的順序對應於索引中的行的順序。此順序是任何表中只能存在一個叢集索引的原因，而該表中可存在大量非叢集索引。在某些資料庫系統中，叢集索引的葉節點對應於實際資料，而不是對應於指向在其他位置上找到的資料的指標。 叢集索引和非叢集索引都

sqlserver繫結主鍵的聚焦索引和非聚焦索引的更換

ALTER table 表名 drop constraint PK_TCOLLECTBILLDETAIL --刪除主鍵同時清除主鍵聚焦索引 ALTER table 表名 ADD Constraint PK_TCOLLECTBILLDETAIL primary key nonclustered

建立 唯一索引和非唯一索引

步驟如下：一、建立唯一索引：1、開啟navicat premium ，開啟準備建立索引的資料庫的查詢編輯器；2、輸入命令：CREATE UNIQUE INDEX  索引名 on 表名（想要建立索引的列名） TABLESPACE 表空間名；CREATE UNIQUE INDEX

淺談sql server聚集索引與非聚集索引

今天同事的服務程式在執行批量插入資料操作時，會超時失敗，程式碼debug了幾遍一點問題都沒有，SQL單條插入也可以正常錄入資料，除錯了一上午還是很迷茫，場面一度很尷尬，最後還是發現了問題的根本，原來是另一個同事為了提升查詢效率濫用了索引在搞鬼，沒有合理的運用索引使每次新增和修改資料時效率極低，大批量插入和修改