當前位置:首頁 » 編程語言 » sql庫索引重建
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

sql庫索引重建

發布時間: 2022-05-19 09:31:16

『壹』 如何重建sql索引 要具體的命令

USE TableName
DECLARE @TableName varchar(255)
DECLARE TableCursor CURSOR FOR
SELECT table_name FROM information_schema.tables
WHERE table_type = 'base table'
OPEN TableCursor
FETCH NEXT FROM TableCursor INTO @TableName
WHILE @@FETCH_STATUS = 0
BEGIN
DBCC DBREINDEX(@TableName,' ',90)
FETCH NEXT FROM TableCursor INTO @TableName
END
CLOSE TableCursor
DEALLOCATE TableCursor

『貳』 sqlserver2000 必須要重建索引嗎

這個東西沒有必須,誰也無法規定你一定要怎樣,搞清楚做這件事是為了什麼,你才知道有沒有必要做。

重建索引的目的是為了讓索引更高效的工作,如果一個索引長時間的沒有整理,那麼整個索引上的數據就會雜亂無章的排列,無法起到提高效率的作用,這樣的索引並沒有什麼卵用。所以對於頻繁寫入數據的表,適時重建索引是需要的。對於不頻繁的表,可以延長索引重建的時間,如果一個表完全只用於查詢而從來不寫入,那可以永遠不需要重建索引。重建索引主要解決索引碎片問題,索引碎片會導致更多的磁碟IO,而磁碟IO恰恰是最消耗時間的操作。

以聚集索引為例,原理在於:

當一個表新增數據時,數據是依次寫入數據頁,索引同理;

而數據寫入並不一定會按順序,例如公司新增員工,你並不能確定每次新增員工他們的姓氏一定就是按照A-Z的順序來的;

那麼時間一長,以字母A為首字母的用戶信息將會遍布整個索引,從頭到尾;

這對於數據檢索沒有什麼好處,假如索引存儲用了1000頁,那麼你需要讀取1000頁的數據來檢索信息;

這時就需要通過索引重建,來把數據按照規則重新排列,以期望在檢索字母A開頭的員工時,可以讓資料庫知道,這些數據都是聚集在前200頁的;

從而讓資料庫減少讀取,提高讀取速度。

更多的細節上的東西,你需要學習2個知識點就可以知道了,

  1. 資料庫中的數據是怎麼存儲的,索引又是怎麼存儲的,是什麼結構

  2. 索引碎片對性能的影響

『叄』 如何重建sql資料庫索引

數據更新是一種常見的操作,然後數據倉庫的概念一般要求的是數據是集成、穩定的。HIVE作為一種分布式環境下以HDFS為支撐的數據倉庫,它同樣更多的要求數據是不可變的。
然而現實很多任務中,往往需要對數據進行更新操作,經查,Hive自0.11版本之後就提供了更新操作。於是想著試驗一下,看看HIVE更新的操作和性能。

『肆』 sql問題,索引的修改。alter index語句如何使用,謝謝

alter index常用的語法如下:
(1)重建指定索引:
ALTER INDEX ind ON TA
REBUILD;
(2)重建全部索引:
ALTER INDEX ALL ON TA
REBUILD;
(3)禁用索引:
ALTER INDEX ALL ON TA
DISABLE;
(再次啟用使用REBUILD重建而不是ENABLED)
(4)指定參數重建索引:
ALTER INDEX ALL ON TA
REBUILD WITH(FILLFACTOR=80);
(5)指定參數修改索引:
ALTER INDEX ALL ON TA
SET(IGNORE_DUP_KEY = ON);

注意:alter index語法,不能用於修改索引定義,如添加或刪除列,或更改列的順序

『伍』 sql怎麼建立索引

進入查詢窗口後,輸入下面的語句:

CREATE INDEX mycolumn_index ON mytable (myclumn)

這個語句建立了一個名為mycolumn_index的索引。你可以給一個索引起任何名字,但你應該在索引名中包含所索引的欄位名,這對你將來弄清楚建立該索引的意圖是有幫助的。

注意:

在本書中你執行任何SQL語句,都會收到如下的信息:

This command did not return data,and it did not return any rows

這說明該語句執行成功了。

索引mycolumn_index對表mytable的mycolumn欄位進行。這是個非聚簇索引,也是個非唯一索引。(這是一個索引的預設屬性)

如果你需要改變一個索引的類型,你必須刪除原來的索引並重建 一個。建立了一個索引後,你可以用下面的SQL語句刪除它:

DROP INDEX mytable.mycolumn_index

注意在DROP INDEX 語句中你要包含表的名字。在這個例子中,你刪除的索引是mycolumn_index,它是表mytable的索引。

要建立一個聚簇索引,可以使用關鍵字CLUSTERED。)記住一個表只能有一個聚簇索引。(這里有一個如何對一個表建立聚簇索引的例子:

CREATE CLUSTERED INDEX mycolumn_clust_index ON mytable(mycolumn)

如果表中有重復的記錄,當你試圖用這個語句建立索引時,會出現錯誤。但是有重復記錄的表也可以建立索引;你只要使用關鍵字ALLOW_DUP_ROW把這一點告訴SQL Sever即可:

CREATE CLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn)

WITH ALLOW_DUP_ROW

這個語句建立了一個允許重復記錄的聚簇索引。你應該盡量避免在一個表中出現重復記錄,但是,如果已經出現了,你可以使用這種方法。

要對一個表建立唯一索引,可以使用關鍵字UNIQUE。對聚簇索引和非聚簇索引都可以使用這個關鍵字。這里有一個例子:

CREATE UNIQUE COUSTERED INDEX myclumn_cindex ON mytable(mycolumn)

這是你將經常使用的索引建立語句。無論何時,只要可以,你應該盡量對一個對一個表建立唯一聚簇索引來增強查詢操作。

最後,要建立一個對多個欄位的索引——復合索引——在索引建立語句中同時包含多個欄位名。下面的例子對firstname和lastname兩個欄位建立索引:

CREATE INDEX name_index ON username(firstname,lastname)

這個例子對兩個欄位建立了單個索引。在一個復合索引中,你最多可以對16個欄位進行索引。

用事務管理器建立索引

用事務管理器建立索引比用SQL語句容易的多。使用事務管理器,你可以看到已經建立的索引的列表,並可以通過圖形界面選擇索引選項。

使用事務管理器你可以用兩種方式建立索引:使用Manage Tables窗口或使用Manage Indexes窗口。

要用Manage Tables 窗口建立一個新索引,單擊按鈕Advanced Options(它看起來象一個前面有一加號的表)。這樣就打開了Advanced Options對話框。這個對話框有一部分標名為Primary Key(見圖11.1)。

圖11。1

要建立一個新索引,從下拉列表中選擇你想對之建立索引的欄位名。如果你想建立一個對多欄位的索引,你可以選擇多個欄位名。你還可以選擇索引是聚簇的還是非聚簇的。在保存表信息後,索引會自動被建立。在Manage Tables窗口中的欄位名旁邊,會出現一把鑰匙。

你已經為你的表建立了「主索引」。主索引必須對不包含空值的欄位建立。另外,主索引強制一個欄位成為唯一值欄位。

要建立沒有這些限制的索引,你需要使用Manage Indexes窗口。從菜單中選擇Manage|Indexes,打開Manage Indexes 窗口。在Manage Indexes 窗口中,你可以通過下拉框選擇表和特定的索引。(見圖11.2)。要建立一個新索引,從Index下拉框中選擇New Index.,然後就可以選擇要對之建立索引的欄位。單擊按鈕Add,把欄位加人到索引中。

圖11。2

你可以為你的索引選擇許多不同的選項。例如,你可以選擇該索引是聚簇的還是非聚簇的。你還可以指定該索引為唯一索引。設計好索引後,單擊按鈕Build,建立該索引。

注意:

唯一索引是指該欄位不能有重復的值,而不是只能建立這一個索引。

SQL核心語句

在第十章,你學會了如何用SQL SELECT 語句從一個表中取數據。但是,到現在為止,還沒有討論如何添加,修改或刪除表中的數據。在這一節中,你將學習這些內容。

插入數據

向表中添加一個新記錄,你要使用SQL INSERT 語句。這里有一個如何使用這種語句的例子:

INSERT mytable (mycolumn) VALUES (『some data')

這個語句把字元串'some data'插入表mytable的mycolumn欄位中。將要被插入數據的欄位的名字在第一個括弧中指定,實際的數據在第二個括弧中給出。

INSERT 語句的完整句法如下:

INSERT [INTO] {table_name|view_name} [(column_list)] {DEFAULT VALUES |

Values_list | select_statement}

如果一個表有多個欄位,通過把欄位名和欄位值用逗號隔開,你可以向所有的欄位中插入數據。假設表mytable有三個欄位first_column,second_column,和third_column。下面的INSERT語句添加了一條三個欄位都有值的完整記錄:

INSERT mytable (first_column,second_column,third_column)

VALUES (『some data','some more data','yet more data')

注意:

你可以使用INSERT語句向文本型欄位中插入數據。但是,如果你需要輸入很長的字元串,你應該使用WRITETEXT語句。這部分內容對本書來說太高級了,因此不加討論。要了解更多的信息,請參考Microsoft SQL Sever 的文檔。

如果你在INSERT 語句中只指定兩個欄位和數據會怎麼樣呢?換句話說,你向一個表中插入一條新記錄,但有一個欄位沒有提供數據。在這種情況下,有下面的四種可能:

如果該欄位有一個預設值,該值會被使用。例如,假設你插入新記錄時沒有給欄位third_column提供數據,而這個欄位有一個預設值'some value'。在這種情況下,當新記錄建立時會插入值'some value'。
如果該欄位可以接受空值,而且沒有預設值,則會被插入空值。
如果該欄位不能接受空值,而且沒有預設值,就會出現錯誤。你會收到錯誤信息:
The column in table mytable may not be null.

最後,如果該欄位是一個標識欄位,那麼它會自動產生一個新值。當你向一個有標識欄位的表中插入新記錄時,只要忽略該欄位,標識欄位會給自己賦一個新值。
注意:

向一個有標識欄位的表中插入新記錄後,你可以用SQL變數@@identity來訪問新記錄

的標識欄位的值。考慮如下的SQL語句:

INSERT mytable (first_column) VALUES(『some value')

INSERT anothertable(another_first,another_second)

VALUES(@@identity,'some value')

如果表mytable有一個標識欄位,該欄位的值會被插入表anothertable的another_first欄位。這是因為變數@@identity總是保存最後一次插入標識欄位的值。

欄位another_first應該與欄位first_column有相同的數據類型。但是,欄位another_first不能是應該標識欄位。Another_first欄位用來保存欄位first_column的值。

刪除記錄

要從表中刪除一個或多個記錄,需要使用SQL DELETE語句。你可以給DELETE 語句提供WHERE 子句。WHERE子句用來選擇要刪除的記錄。例如,下面的這個DELETE語句只刪除欄位first_column的值等於'Delete Me'的記錄:

DELETE mytable WHERE first_column='Deltet Me'

DELETE 語句的完整句法如下:

DELETE [FROM] {table_name|view_name} [WHERE clause]

在SQL SELECT 語句中可以使用的任何條件都可以在DELECT 語句的WHERE子句中使用。例如,下面的這個DELETE語句只刪除那些first_column欄位的值為'goodbye'或 second_column欄位的值為 'so long'的記錄:

DELETE mytable WHERE first_column='goodby' OR second_column='so long'

如果你不給DELETE 語句提供WHERE 子句,表中的所有記錄都將被刪除。你不應該有這種想法。如果你想刪除應該表中的所有記錄,應使用第十章所講的TRUNCATE TABLE語句。

注意:

為什麼要用TRUNCATE TABLE 語句代替DELETE語句?當你使用TRUNCATE TABLE語句時,記錄的刪除是不作記錄的。也就是說,這意味著TRUNCATE TABLE 要比DELETE快得多

『陸』 SQL Server 2000資料庫中如何重建索引

當對數據的更改影響到索引時,索引中的信息可能會在資料庫中分散開來。重建索引可以重新組織索引數據(對於聚集索引還包括表數據)的存儲,清除碎片。這可通過減少獲得請求數據所需的頁讀取數來提高磁碟性能。
在Microsoft

『柒』 在PL-SQL中如何給oracle資料庫重建索引

重建索引有多種方式,如drop and re-create、rebuild、rebuild online等。下面簡單比較這幾種方式異同以及優缺點:
首先建立測試表及數據:
SQL> CREATE TABLE TEST AS SELECT CITYCODE C1 FROM CITIZENINFO2;
Table created
SQL> ALTER TABLE TEST MODIFY C1 NOT NULL;
Table altered
SQL> SELECT COUNT(1) FROM TEST;
COUNT(1)
----------
16000000
一、drop and re-create和rebuild
首先看看正常建立索引時,對表的加鎖情況。
suk@ORACLE9I> @show_sid
SID
----------
14
suk@ORACLE9I> CREATE INDEX IDX_TEST_C1 ON TEST(C1);
索引已創建。
SQL> SELECT OBJECT_NAME,LMODE FROM V$LOCK L,DBA_OBJECTS O WHERE O.OBJECT_ID=L.ID1 AND L.TYPE='TM' AND SID=14;
OBJECT_NAME LMODE
------------------------------ ----------
OBJ$ 3
TEST 4
可見,普通情況下建立索引時,oracle會對基表加share鎖,由於share鎖和 row-X是不兼容的,也就是說,在建立索引期間,無法對基表進行DML操作。
對於刪除重建索引的方法就不介紹了,它與上面的描述是一樣的,下面我們看看用rebuild的方式建立索引有什麼特別。
suk@ORACLE9I> ALTER INDEX IDX_TEST_C1 REBUILD;
索引已更改。
另開一個會話,查詢此時test的加鎖情況:
SQL> SELECT OBJECT_NAME,LMODE FROM V$LOCK L,DBA_OBJECTS O WHERE O.OBJECT_ID=L.ID1 AND L.TYPE='TM' AND SID=14;
OBJECT_NAME LMODE
------------------------------ ----------
TEST 4
可見,rebuild的方式對基表的加鎖方式與CREATE時是一樣的。
另開一個會話,在索引正在rebuild時,執行如下SQL:
suk@ORACLE9I> SET AUTOTRACE TRACE
suk@ORACLE9I> SELECT /*+ INDEX(TEST) */ COUNT(1) FROM TEST WHERE ROWNUM<10;
執行計劃
----------------------------------------------------------
0 SELECT STATEMENT ptimizer=CHOOSE (Cost=26 Card=1)
1 0 SORT (AGGREGATE)
2 1 COUNT (STOPKEY)
3 2 INDEX (FULL SCAN) OF 'IDX_TEST_C1' (NON-UNIQUE) (Cost=
26 Card=1986621)
可以看到索引在重建時,查詢仍然可以使用舊索引。實際上,oracle在rebuild時,在創建新索引過程中,並不會刪除舊索引,直到新索引rebuild成功。
從這點可以知道rebuild比刪除重建的一個好處是不會影響原有的SQL查詢,但也正由於此,用rebuild方式建立索引需要相應表空間的空閑空間是刪除重建方式的2倍。
重建索引有多種方式,如drop and re-create、rebuild、rebuild online等。下面簡單比較這幾種方式異同以及優缺點:
相關文章:
oracle重建索引(一)
二、rebuild 和rebuild online
首先我們跟蹤一下rebuild online的過程。
另開一個會話查看鎖的信息:
SQL> SELECT OBJECT_NAME,LMODE FROM V$LOCK L,DBA_OBJECTS O WHERE O.OBJECT_ID=L.ID1 AND L.TYPE='TM' AND SID=14;
OBJECT_NAME LMODE
------------------------------ ----------
SYS_JOURNAL_10499 4
TEST 2
SQL> INSERT INTO TEST VALUES(11);
1 row inserted
SQL> COMMIT;
Commit complete
可以看到,在rebuild online期間,oracle對基表加的是RS所,此時我們可以對基表進行DML操作。但奇怪的話在相同的session中有一個SYS_JOURNAL_10499表被加SHARE鎖,這個表是干什麼用的呢?
我們看看trace文件,有這樣的信息:
create table "SUK"."SYS_JOURNAL_10499" (C0 NUMBER(6,0), opcode char(1),
partno number, rid rowid, primary key( C0 , rid )) organization index
TABLESPACE "TEST"
CREATE UNIQUE INDEX "SUK"."SYS_IOT_TOP_10605" on
"SUK"."SYS_JOURNAL_10499"("C0","RID") INDEX ONLY TOPLEVEL TABLESPACE "TEST"
NOPARALLEL
drop table "SUK"."SYS_JOURNAL_10499"
我們在查查10499是什麼東西:
SQL> SELECT OBJECT_NAME,OBJECT_TYPE FROM DBA_OBJECTS WHERE OBJECT_ID=10499;
OBJECT_NAME OBJECT_TYPE
------------------------------ ------------------
IDX_TEST_C1 INDEX
從這些信息可以推測:表SYS_JOURNAL_10499就是實現在重建索引時不阻塞DML操作而設計的,它存儲的是在索引重建期間發生在基表的數據變化。可以推測,CREATE INDEX .... ONLINE應該也有一張類似的表。
實際上,oracle之所以在創建索引時鎖表阻止DML操作就是為了防止不能索引新變化的數據,在online方式重建時,有了臨時表SYS_JOURNAL_XXXX,oracle就可以放心大膽地讓用戶操作了,因為所有重建索引期間的數據變化信息都會保留在SYS_JOURNAL_XXX表中,當索引重建完後再加上SYS_JOURNAL_XXX記錄的數據,就不會漏索引數據了。(XXX是被重建的索引對應的OBJECT_ID)
導讀:
重建索引有多種方式,如drop and re-create、rebuild、rebuild online等。下面簡單比較這幾種方式異同以及優缺點:
相關文章:
oracle重建索引(一)
oracle重建索引(二)
三、rebuild和rebuild online的數據源
網上一直有這樣一個說法:重建索引是以原索引作為數據源的。那麼,這種說法是否准確呢?我們做實驗來驗證一下:
suk@ORACLE9I> COL SEGMENT_NAME FORMAT A30
--首先看看錶和索引的大小
suk@ORACLE9I> SELECT SEGMENT_NAME,BYTES FROM USER_SEGMENTS WHERE SEGMENT_NAME IN ('TEST','IDX_TEST_C1');
SEGMENT_NAME BYTES
------------------------------ ----------
TEST 201326592
IDX_TEST_C1 293601280
suk@ORACLE9I> EXPLAIN PLAN FOR ALTER INDEX IDX_TEST_C1 REBUILD;
已解釋。
suk@ORACLE9I> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------
| 0 | ALTER INDEX STATEMENT | | | | |
| 1 | INDEX BUILD NON UNIQUE| IDX_TEST_C1 | | | |
| 2 | SORT CREATE INDEX | | | | |
| 3 | TABLE ACCESS FULL | TEST | | | |
-----------------------------------------------------------------------
Note: rule based optimization
已選擇11行。
--從執行計劃可以看出,當索引比表大時,rebuild索引用的數據源是基表。
suk@ORACLE9I> EXPLAIN PLAN FOR ALTER INDEX IDX_TEST_C1 REBUILD ONLINE;
已解釋。
suk@ORACLE9I> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------
| 0 | ALTER INDEX STATEMENT | | | | |
| 1 | INDEX BUILD NON UNIQUE| IDX_TEST_C1 | | | |
| 2 | SORT CREATE INDEX | | | | |
| 3 | TABLE ACCESS FULL | TEST | | | |
-----------------------------------------------------------------------
Note: rule based optimization
已選擇11行。
--從執行計劃可以看出,當索引比表大時,rebuild online索引用的數據源是基表。
--我們為TEST添加一列,使得表比索引大
suk@ORACLE9I> ALTER TABLE TEST ADD(C2 CHAR(30) DEFAULT '1');
表已更改。
suk@ORACLE9I> SELECT SEGMENT_NAME,BYTES FROM USER_SEGMENTS WHERE SEGMENT_NAME IN ('TEST','IDX_TEST_C
1');
SEGMENT_NAME BYTES
------------------------------ ----------
TEST 1476395008
IDX_TEST_C1 293601280
suk@ORACLE9I> EXPLAIN PLAN FOR ALTER INDEX IDX_TEST_C1 REBUILD;
已解釋。
suk@ORACLE9I> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------
| 0 | ALTER INDEX STATEMENT | | | | |
| 1 | INDEX BUILD NON UNIQUE| IDX_TEST_C1 | | | |
| 2 | SORT CREATE INDEX | | | | |
| 3 | INDEX FAST FULL SCAN| IDX_TEST_C1 | | | |
-----------------------------------------------------------------------
Note: rule based optimization
已選擇11行。
--從執行計劃可以看出,當表比索引大時,執行計劃已經改變,rebuild索引是以索引作為數據源的。
suk@ORACLE9I> EXPLAIN PLAN FOR ALTER INDEX IDX_TEST_C1 REBUILD ONLINE;
已解釋。
suk@ORACLE9I> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------
| 0 | ALTER INDEX STATEMENT | | | | |
| 1 | INDEX BUILD NON UNIQUE| IDX_TEST_C1 | | | |
| 2 | SORT CREATE INDEX | | | | |
| 3 | TABLE ACCESS FULL | TEST | | | |
-----------------------------------------------------------------------
Note: rule based optimization
已選擇11行。
--從執行計劃可以看出,當表比索引大時,rebuild online仍然以基表作為數據源。
rebuild模式下,因為表數據不會產生變化,oracle主要考慮性能問題,把更快掃描完成的段作為數據源。在上面的例子中,我們並沒有對表進行分析,故oracle應該根據數據段的大小來決定那個作為數據源的。一般索引欄位比較多,或者對索引欄位的DML操作較多,可能會導致索引比表大,這時oracle就會使用基表作為新索引的數據源進行rebuild了。
而在rebuild online模式下,因為允許DML操作,而表數據變化的同時索引也會跟著變化,為了索引與基表數據的一致性,比如採用基表數據作為數據源,而不能用原索引數據作為數據源。
我們用反證法證明不能用原索引作為新索引的數據源。
例如:
T1發出rebuild online命令
T2刪除某條數據,刪數據的同時,oracle會自動維護了舊索引
T3掃描經過T2數據所在索引節點
T4插入一條記錄,新記錄對應的索引節點剛好重用了T2刪除的數據對應的索引節點空間
如果是這樣的話,新建的索引將不包含T4插入的記錄的信息。所以,rebuild online情況下新索引的數據源不能是原索引。
rebuild online情況下,如果非用原索引作為新索引的數據源的話,用中間表記錄索引變化的方法應該是可以實現的,但由於數據變化會同時引起索引變化的特定決定了這種方法將異常復雜及效率底下,所以oracle不考慮舊索引作為新索引的數據源是有道理的。
結論:
1、rebuild會阻塞對基表的DML操作,但不會影響rebuild期間查詢對原有索引的使用。
2、rebuild的數據源可能是基表,也可能是原索引。取決於基表和原索引的大小,那個小,rebuild時就會用那個作為數據源。這也說明了網上盛傳的rebuild以原索引作為資料庫的說法是不完全正確的。
3、rebuild online運行用戶在索引重建期間執行DML操作。
4、rebuild online的數據源是基表

『捌』 Sql server 創建索引後,只有查詢後重建才會生效,不知為什麼

應該和設置當前索引有關。例如ADO借口中就有這類的參數。Foxpro中有set
index
to等語句。

『玖』 sql server如何重建索引到其它文件組

在日常工作中,我們發現很多實施案例中,sql server的資料庫數據與索引在一起。我見過一個客戶的,他的資料庫總共大小才60g,但索引與數據完全混在一起,從管理資料庫的直覺來看,性能方面肯定有問題,所以我建議他們,不管怎麼樣,把索引與資料庫分開,對性能是有好處的!但是sql server的索引,想要通過重建的方式,把數據與索引分開,並不是一件容易的事懷,在使用rebuild時,並不能增加文件組選項。後來研究發現,可以通過以下方式把數據與非聚簇索引分開,具體如下:
set nocount on

declare @index table
(
object_id int,
objectName sysname,
index_id int,
indexName sysname,
fill_factor tinyint,
allow_row_locks bit,
allow_page_locks bit,
is_padded bit,
indexText varchar(max),
indexTextEnd varchar(max)
)

declare @indexColumn table
(
object_id int,
index_id int,
column_id int,
index_column_id int,
max_index_column_id int,
is_descending_key bit,
is_included_column bit,
columnName varchar(255),
indexText varchar(max) null
)

insert into @index
select
i.object_id,
object_name(i.object_id),
i.index_id,
i.name,
fill_factor,
allow_row_locks,
allow_page_locks,
is_padded,
'CREATE NONCLUSTERED INDEX [' + i.name + '] ON [dbo].[' + object_name(i.object_id) + '] ' + char(13),
'WITH (PAD_INDEX = ' +
CASE WHEN is_padded = 1 THEN ' ON ' ELSE ' OFF ' END +
', STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = ON, ONLINE = OFF, ALLOW_ROW_LOCKS = ' +
CASE WHEN allow_row_locks = 1 THEN ' ON ' ELSE ' OFF ' END +
', ALLOW_PAGE_LOCKS = ' +
CASE WHEN allow_page_locks = 1 THEN ' ON ' ELSE ' OFF ' END +
CASE WHEN fill_factor > 0 THEN ', FILLFACTOR = ' + convert(varchar(3), fill_factor) ELSE '' END +
') ON [IndexFG];print('''+i.name+' @ '+object_name(i.object_id)+''')' --+ CHAR(13) + ' GO;'+ CHAR(13) --注意標紅的地方,這是新的文件組的名稱
from sys.indexes i
where i.type = 2 and not exists(select 1 from sys.key_constraints kc where kc.name=i.name)
and objectproperty(i.object_id , 'IsUserTable') = 1
order by object_name(i.object_id), i.name

insert into @indexColumn
select
i.object_id,
i.index_id,
ic.column_id,
ic.index_column_id,
max(ic.index_column_id) over (partition by i.object_id, i.index_id, is_included_column),
is_descending_key,
is_included_column,
'[' + c.name + ']',
null
from @index i
join sys.index_columns ic
on i.object_id = ic.object_id
and i.index_id = ic.index_id
join sys.columns c
on ic.object_id = c.object_id
and ic.column_id = c.column_id
order by i.object_id, i.index_id, ic.index_column_id

declare @fields varchar(max)
declare @object_id int, @index_id int

select @fields = null, @object_id = -1, @index_id = -1

update @indexColumn
set @fields = indexText =
case when object_id = isnull(@object_id, object_id) and index_id = isnull(@index_id, index_id)
then isnull(@fields + ', ', ' ') + columnName + case when is_descending_key = 0 then ' ASC' else ' DESC' end
else columnName + case when is_descending_key = 0 then ' ASC' else ' DESC' end
end,
@object_id = case when object_id <> @object_id
then object_id else @object_id end,
@index_id = case when index_id <> @index_id
then index_id else @index_id end
from @indexColumn
where is_included_column = 0

select @fields = null, @object_id = -1, @index_id = -1

update @indexColumn
set @fields = indexText =
case when object_id = isnull(@object_id, object_id) and index_id = isnull(@index_id, index_id)
then isnull(@fields + ', ', ' ') + columnName
else columnName
end,
@object_id = case when object_id <> @object_id
then object_id else @object_id end,
@index_id = case when index_id <> @index_id
then index_id else @index_id end
from @indexColumn
where is_included_column = 1

update @index
set indexText = i.indexText + '( ' + char(13) + char(9) + ic.indexText + char(13) + ') '
from @index i join @indexColumn ic
on i.object_id = ic.object_id
and i.index_id = ic.index_id
and ic.index_column_id = ic.max_index_column_id
and ic.is_included_column = 0

update @index
set indexText = i.indexText + 'INCLUDE ( ' + char(13) + char(9) + ic.indexText + char(13) + ') '
from @index i join @indexColumn ic
on i.object_id = ic.object_id
and i.index_id = ic.index_id
and ic.index_column_id = ic.max_index_column_id
and ic.is_included_column = 1

update @index
set indexText = indexText + indexTextEnd
from @index

select indexText, objectName, indexName
from @index

最後的查詢結果第一行就是執行的命令!

『拾』 SQL中如何重建一張表的索引

SELECT
tab.name AS [表名],
idx.name AS [索引名稱],
col.name AS [列名]
FROM
sys.indexes idx
JOIN sys.index_columns idxCol
ON (idx.object_id = idxCol.object_id
AND idx.index_id = idxCol.index_id
)
JOIN sys.tables tab
ON (idx.object_id = tab.object_id)
JOIN sys.columns col
ON (idx.object_id = col.object_id
AND idxCol.column_id = col.column_id);