第一步：查看是否需要維護，查看掃描密度/Scan Density是否為100%
declare @table_id int
set @table_id=object_id('表名')
dbcc showcontig(@table_id)
第二步:重構表索引
dbcc dbreindex('表名',pk_索引名,100)
重做第一步，如發現掃描密度/Scan Density還是小於100%則重構表的所有索引
dbcc dbreindex('表名','',100)
B. SQL 修改 索引
select num from table num <=2
union all
select num from table num = 6
union all
select num from table num >=3 and num <> 6
要不就根據需要寫個存儲過程，沒有直接的方法
C. 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語法，不能用於修改索引定義，如添加或刪除列，或更改列的順序
D. sql2000當對資料庫的數據進行增加和更新時，索引怎麼維護
可以自動，也可以手動。
你在SQL的企業管理器里，在你要維護的那資料庫右擊，選擇所有任務裡面的維護計劃命令。在設置的過程中就有這一個選項。
E. sql 怎麼 更新索引
可以創建索引、修改索引和優化索引，沒聽說過更新索引
如果確實有，請告知。謝謝。
F. 如何重建sql資料庫索引
數據更新是一種常見的操作，然後數據倉庫的概念一般要求的是數據是集成、穩定的。HIVE作為一種分布式環境下以HDFS為支撐的數據倉庫，它同樣更多的要求數據是不可變的。
然而現實很多任務中，往往需要對數據進行更新操作，經查，Hive自0.11版本之後就提供了更新操作。於是想著試驗一下，看看HIVE更新的操作和性能。
G. 在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的數據源是基表
H. 如何重建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
I. SQL Server 2000資料庫中如何重建索引
連續索引頁由從一個頁到下一個頁的指針鏈接在一起。當對數據的更改影響到索引時，索引中的信息可能會在資料庫中分散開來。重建索引可以重新組織索引數據（對於聚集索引還包括表數據)的存儲，清除碎片。這可通過減少獲得請求數據所需的頁讀取數來提高磁碟性能。 在Microsoft�0�3 SQL Server�6�4 2000 中，如果要用一個步驟重新創建索引，而不想刪除舊索引並重新創建同一索引，則使用 CREATE INDEX 語句的 DROP_EXISTING 子句可以提高效率。這一優點既適用於聚集索引也適用於非聚集索引。 以刪除舊索引然後重新創建同一索引的方式重建聚集索引，是一種昂貴的方法，因為所有二級索引都使用聚集鍵指向數據行。如果只是刪除聚集索引然後重新創建，則會使所有非聚集索引都被刪除和重新創建兩次。一旦刪除聚集索引並再次重建該索引，就會發生這種情形。通過在一個步驟中重新創建索引，可以避免這一昂貴的做法。在一個步驟中重新創建索引時，會告訴 SQL Server 要重新組織現有索引，避免了刪除和重新創建非聚集索引這些不必要的工作。該方法的另一個重要優點是可以使用現有索引中的數據排序次序，從而避免了對數據重新排序。這對於聚集索引和非聚集索引都十分有用，可以顯著減少重建索引的成本。另外，通過使用 DBCC DBREINDEX 語句，SQL Server 還允許對一個表重建（在一個步驟中）一個或多個索引，而不必單獨重建每個索引。 DBCC DBREINDEX 也可用於重建執行 PRIMARY KEY 或 UNIQUE 約束的索引，而不必刪除並創建這些約束（因為對於為執行 PRIMARY KEY 或 UNIQUE 約束而創建的索引，必須先刪除該約束，然後才能刪除該索引）。