1. sql server索引的問題，關於聚集索引和非聚集索引。謝謝
聚集索引： 數據的索引位置就是數據本身，顯然一個表只能有一個聚集索引，所以才需要非聚集索引來按更多的欄位來索引。
非聚集索引：數據的索引位置是一個指針，這個指針再指向數據本身。
2. sql中關於聚集索引的問題
不是沒有必要再建立，而是不能建立：
1、聚簇索引（也就是你說的聚集索引），在每張表上只能建立一個，是唯一的哦。
2、假設這個表沒有索引，要建立聚簇索引也不能建立在s_name欄位上，因為你無法保證學生中不會有重名的，例如：【id】是「5」號的學生叫「張三」，可能【id】是「89」的學生也叫「張三」，聚簇索引只能建立在該列無重復數據的欄位上。
---------------------------------------------------------------------
其實，一個表的索引（無論聚簇索引、非聚簇索引）越少越好，否則會降低資料庫的效能。
3. 如何用sql語句在列上建立聚集索引
可以用如下語句
create clustered index 索引名 on 表名(欄位名)
4. sql server中如何刪除聚集索引
刪除索引的語句:
DROP INDEX sy ON salary ;
5. 如何用SQL語句刪除不唯一、非聚集索引
drop index index_name 就好了 啊
6. SQL聚集索引的問題——有請高手！！！！！！！！！
在創建聚集索引時,資料庫會將所有的數據重新按順序重新排序,在數據結構(邏輯上)連續順序,同時在硬碟的位置(也就是物理上)也是連續地按順序擺放的
一般來說,新增數據時資料庫都會根據主鍵的值按之前排好的順序插入其中,而不是單純的放到最後面;
之前說過聚集索引在物理上是連續順序的,但是隨著不斷的插入新數據,物理上預留的位置不足夠,那麼新的記錄就會存放在硬碟的其他地方,從而導致物理上不連續;但是邏輯上還是連續順序的;隨著時間的推移物理上數據將越來越分散,最終導致查詢的性能,這是則可以通過重建索引的方法,使數據保持連續順序; 如果樓主還想有更深入的了解,建議到博客園關注CareySon 的博客,真正的大牛,我是他的粉絲之一,PS:網路知道不給放鏈接
7. 如何設置聚集索引(Cluster Index)
聚集索引的好處就是可以讓數據按照此索引的順序進行物理位置存放，用blog_Comment表來說明，此表有comm_idcomm_logidcomm_author comm_posttime等欄位 比如說posttime between DATE1 and DATE2,OK這樣的話聚集索引利用到了，因為這個區間段的數據是非常親密地靠在一起的，可以用最少的I/O開銷取得所需的結果集。可是我們知道，更多的時候我們是在顯示一個article時然後讀取它的所有comments，這時，過濾條件就成了comm_logid = ID了，如果聚集索引被comm_id心安理得地佔用的話，那麼很可能我們這批comments需要多個數據頁才能得到，這樣的話，就大大地增加了時間，因為I/O的開銷比CPU在內存上的數據查找排序都是要高一個數據級的。 但是聚集索引的改變同樣會給其它的查詢帶來負面影響，比如說comm_id = ID的查詢，在原來只需要在PK_blog_Comment_comm_id的聚集索引上查找記錄，然後得到的指針指向就是實際數據塊的存放位置了，但是現在，在此非聚集的唯一索引上查找得到的指針是指向IX_blog_Comment_comm_logid的的位置，所以需要多一次的Bookmark Lookup才能取得所需數據。 其實使用的方法很簡單，當你需要頻繁地取得批量數據時，把聚集索引放在最有可能定位區間的欄位上。 另外blog_Article的聚集索引我放在posttime上了，因為經常要對此欄位進行order by的查詢，雖然logid和posttime的排序方向是一樣的，但是我這樣可能通過cluster index的lookup 節省一個order by的時間，不過到底孰優孰劣我還不敢下結論。 其它的blog_Archive,blog_Category的聚集索引都在authorid上，因為這個都是對於authorid = ID的查詢。 也許隨著數據量的增長，情況會有不同，這個以後再看情況調整了。
8. sql索引問題，我要建立一個聚集索引是不是要取消表裡的主鍵
可以將原來的主鍵取消，設置成唯一並不為空，再設置聚集索引列
這樣原來的主鍵列同樣具有主鍵的同樣的效果
9. SQL聚集索引和非聚集索引的區別
資料庫的索引，聽起來挺神秘的，仔細想想。這些索引，其實就是平時咱們查東西時候常用的兩種手段。無非就是為了提高我們找東西的效率而已。那麼我們平時又是怎麼查東西呢？
聚集索引：
聚集索引，來源於生活嘗試。這中索引可以說是按照數據的物理存儲進行劃分的。對於一堆記錄來說，使用聚集索引就是對這堆記錄 進行 堆劃分。即主要描述的是物理上的存儲。
舉個例子：
比如圖書館新進了一批書。那麼這些書需要放到圖書館內。書如何放呢？一般都有一個規則，雜志類的放到101房間，文學類的放到102房間，理工類的放到103房間等等。這些存儲的規則決定了每本書應該放到哪裡。而這個例子中聚集索引為書的類別。
正式因為這種存儲規則，才導致 聚集索引的唯一性。
誤區：
有的人認為，聚集索引的欄位是唯一的。這是因為sql server 中添加主鍵的時候，自動給主鍵所在的欄位生成一個聚集索引。所以人們會認為聚集索引所加的欄位是唯一的。
思考一下上面這個問題。雜志類的書放到101房間。那麼如果雜志類的書太多，一個101房間存放不下。那麼可能101，201兩個房間來存放雜志類的書籍。如果這樣分析的話，那麼一個雜志類對應多個房間。放到表存儲的話，那麼這個類別欄位 就不是唯一的了。
非聚集索引：
非聚集索引，也可以從生活中找到映射。非聚集索引強調的是邏輯分類。可以說是定義了一套存儲規則，而需要有一塊控制項來維護這個規則，這個被稱之為索引表。
繼續使用上述提到的例子：
同學如果想去圖書館找一本書，而不知道這本書在哪裡？那麼這個同學首先應該找的就是 檢索室吧。對於要查找一本書來說，在檢索室查是一個非常快捷的的途徑了吧。但是，在檢索室中你查到了該書在XX室XX書架的信息。你的查詢結束了嗎？沒有吧。你僅僅找到了目的書的位置信息，你還要去該位置去取書。
對於這種方式來說，你需要兩個步驟：
1、查詢該記錄所在的位置。
2、通過該位置去取要找的記錄。
區別：
聚集索引：可以幫助把很大的范圍，迅速減小范圍。但是查找該記錄，就要從這個小范圍中Scan了。
非聚集索引：把一個很大的范圍，轉換成一個小的地圖。你需要在這個小地圖中找你要尋找的信息的位置。然後通過這個位置，再去找你所需要的記錄。
索引與主鍵的區別
主鍵：主鍵是唯一的，用於快速定位一條記錄。
聚集索引：聚集索引也是唯一的。（因為聚集索引的劃分依據是物理存儲）。而聚集索引的主要是為了快速的縮小查找范圍，即記錄數目未定。
主鍵和索引沒有關系。他們的用途相近。如果聚集索引加上唯一性約束之後，他們的作用就一樣了。
使用場景
基於上述的兩種規則，那麼在什麼時候適合聚集索引，什麼時候適合非聚集索引？