sql重建表索引

❶ sql server镐庝箞寤虹珛绱㈠紩

浠涔堟槸绱㈠紩
𨰾挎眽璇瀛楀吀镄勭洰褰曢〉锛堢储寮曪级镓撴瘆鏂癸细姝ｅ傛眽璇瀛楀吀涓镄勬眽瀛楁寜椤靛瓨鏀句竴镙凤纴SQL Server涓镄勬暟鎹璁板綍涔熸槸鎸夐〉瀛樻斁镄勶纴姣忛〉瀹归噺涓鑸涓4K 銆备负浜嗗姞蹇镆ユ垒镄勯熷害锛屾眽璇瀛楋纸璇嶏级鍏镐竴鑸閮芥湁鎸夋嫾阔炽佺玛鐢汇佸亸镞侀儴棣栫瓑鎺掑簭镄勭洰褰曪纸绱㈠紩锛夛纴鎴戜滑鍙浠ラ夋嫨鎸夋嫾阔虫垨绗旂敾镆ユ垒鏂瑰纺锛屽揩阃熸煡镓惧埌闇瑕佺殑瀛楋纸璇嶏级銆
钖岀悊锛孲QL Server鍏佽哥敤鎴峰湪琛ㄤ腑鍒涘缓绱㈠紩锛屾寚瀹氭寜镆愬垪棰勫厛鎺掑簭锛屼粠钥屽ぇ澶ф彁楂樻煡璇㈤熷害銆
• SQL Server涓镄勬暟鎹涔熸槸鎸夐〉锛 4KB 锛夊瓨鏀
• 绱㈠紩锛氭槸SQL Server缂栨帓鏁版嵁镄勫唴閮ㄦ柟娉曘傚畠涓篠QL Server鎻愪緵涓绉嶆柟娉曟潵缂栨帓镆ヨ㈡暟鎹銆
• 绱㈠紩椤碉细鏁版嵁搴扑腑瀛桦偍绱㈠紩镄勬暟鎹椤碉绂绱㈠紩椤电被浼间簬姹夎瀛楋纸璇嶏级鍏镐腑鎸夋嫾阔虫垨绗旂敾鎺掑簭镄勭洰褰曢〉銆
• 绱㈠紩镄勪綔鐢锛氶氲繃浣跨敤绱㈠紩锛屽彲浠ュぇ澶ф彁楂樻暟鎹搴撶殑妫绱㈤熷害锛屾敼锽勬暟鎹搴撴ц兘銆

绱㈠紩绫诲瀷
• 鍞涓绱㈠紩锛氩敮涓绱㈠紩涓嶅厑璁镐袱琛屽叿链夌浉钖岀殑绱㈠紩鍊
• 涓婚敭绱㈠紩锛氢负琛ㄥ畾涔変竴涓涓婚敭灏呜嚜锷ㄥ垱寤轰富阌绱㈠紩锛屼富阌绱㈠紩鏄鍞涓绱㈠紩镄勭壒娈婄被鍨嬨备富阌绱㈠紩瑕佹眰涓婚敭涓镄勬疮涓鍊兼槸鍞涓镄勶纴骞朵笖涓嶈兘涓虹┖
• 镵氶泦绱㈠紩(Clustered)锛氲〃涓钖勮岀殑鐗╃悊椤哄簭涓庨敭鍊肩殑阃昏緫锛堢储寮曪级椤哄簭鐩稿悓锛屾疮涓琛ㄥ彧鑳芥湁涓涓
• 闱炶仛闆嗙储寮(Non-clustered)锛氶潪镵氶泦绱㈠紩鎸囧畾琛ㄧ殑阃昏緫椤哄簭銆傛暟鎹瀛桦偍鍦ㄤ竴涓浣岖疆锛岀储寮曞瓨鍌ㄥ湪鍙︿竴涓浣岖疆锛岀储寮曚腑鍖呭惈鎸囧悜鏁版嵁瀛桦偍浣岖疆镄勬寚阍堛傚彲浠ユ湁澶氢釜锛屽皬浜249涓

绱㈠紩绫诲瀷锛氩啀娆＄敤姹夎瀛楀吀镓撴瘆鏂癸纴甯屾湜澶у惰兘澶熸槑锏借仛闆嗙储寮曞拰闱炶仛闆嗙储寮曡繖涓や釜姒傚康銆

鍞涓绱㈠紩锛
鍞涓绱㈠紩涓嶅厑璁镐袱琛屽叿链夌浉钖岀殑绱㈠紩鍊笺
濡傛灉鐜版湁鏁版嵁涓瀛桦湪閲嶅岖殑阌鍊硷纴鍒椤ぇ澶氭暟鏁版嵁搴挞兘涓嶅厑璁稿皢鏂板垱寤虹殑鍞涓绱㈠紩涓庤〃涓璧蜂缭瀛樸傚綋鏂版暟鎹灏嗕娇琛ㄤ腑镄勯敭鍊奸吨澶嶆椂锛屾暟鎹搴扑篃𨰾掔粷鎺ュ弹姝ゆ暟鎹銆备緥濡傦纴濡傛灉鍦╯tuInfo琛ㄤ腑镄勫﹀憳锻樿韩浠借瘉鍙(stuID) 鍒椾笂鍒涘缓浜嗗敮涓绱㈠紩锛屽垯镓链夊﹀憳镄勮韩浠借瘉鍙蜂笉鑳介吨澶嶃
鎻愮ず锛氩垱寤轰简鍞涓绾︽潫锛屽皢镊锷ㄥ垱寤哄敮涓绱㈠紩銆傚敖绠″敮涓绱㈠紩链夊姪浜庢垒鍒颁俊鎭锛屼絾涓轰简銮峰缑链浣虫ц兘锛屽缓璁浣跨敤涓婚敭绾︽潫鎴栧敮涓绾︽潫銆

涓婚敭绱㈠紩锛
鍦ㄦ暟鎹搴揿叧绯诲浘涓涓鸿〃瀹氢箟涓涓涓婚敭灏呜嚜锷ㄥ垱寤轰富阌绱㈠紩锛屼富阌绱㈠紩鏄鍞涓绱㈠紩镄勭壒娈婄被鍨嬨备富阌绱㈠紩瑕佹眰涓婚敭涓镄勬疮涓鍊兼槸鍞涓镄勚傚綋鍦ㄦ煡璇涓浣跨敤涓婚敭绱㈠紩镞讹纴瀹冭缮鍏佽稿揩阃熻块梾鏁版嵁銆

镵氶泦绱㈠紩锛坈lustered index锛
鍦ㄨ仛闆嗙储寮曚腑锛岃〃涓钖勮岀殑鐗╃悊椤哄簭涓庨敭鍊肩殑阃昏緫锛堢储寮曪级椤哄簭鐩稿悓銆傝〃鍙鑳藉寘钖涓涓镵氶泦绱㈠紩銆备緥濡傦细姹夎瀛楋纸璇嶏级鍏搁粯璁ゆ寜𨰾奸煶鎺掑簭缂栨帓瀛楀吀涓镄勬疮椤甸〉镰併傛嫾阔冲瓧姣峚锛宐锛宑锛宒钬︹x锛寉锛寊灏辨槸绱㈠紩镄勯昏緫椤哄簭锛岃岄〉镰1锛2锛3钬︹﹀氨鏄鐗╃悊椤哄簭銆傞粯璁ゆ寜𨰾奸煶鎺掑簭镄勫瓧鍏革纴鍏剁储寮曢‘搴忓拰阃昏緫椤哄簭鏄涓镊寸殑銆傚嵆𨰾奸煶椤哄簭杈冨悗镄勫瓧锛堣瘝锛夊瑰簲镄勯〉镰佷篃杈冨ぇ銆傚傛嫾阔抽梙a鍦板瑰簲镄勫瓧(璇)椤电爜灏辨瘆𨰾奸煶阃梑a鍦 瀵瑰簲镄勫瓧(璇)椤电爜闱犲悗銆

闱炶仛闆嗙储寮(Non-clustered)
濡傛灉涓嶆槸镵氶泦绱㈠紩锛岃〃涓钖勮岀殑鐗╃悊椤哄簭涓庨敭鍊肩殑阃昏緫椤哄簭涓嶅尮閰嶃傝仛闆嗙储寮曟瘆闱炶仛闆嗙储寮曪纸nonclustered index锛夋湁镟村揩镄勬暟鎹璁块梾阃熷害銆备緥濡傦纴鎸夌玛鐢绘帓搴忕殑绱㈠紩灏辨槸闱炶仛闆嗙储寮曪纴阃1鍦扮敾镄勫瓧锛堣瘝锛夊瑰簲镄勯〉镰佸彲鑳芥瘆阃3鍦扮敾镄勫瓧锛堣瘝锛夊瑰簲镄勯〉镰佸ぇ锛堥潬钖庯级銆
鎻愮ず锛歋QL Server涓锛屼竴涓琛ㄥ彧鑳藉垱寤1涓镵氶泦绱㈠紩锛屽氢釜闱炶仛闆嗙储寮曘傝剧疆镆愬垪涓轰富阌锛岃ュ垪灏遍粯璁や负镵氶泦绱㈠紩

濡备綍鍒涘缓绱㈠紩
浣跨敤T-SQL璇鍙ュ垱寤虹储寮旷殑璇娉曪细
CREATE [UNIQUE] [CLUSTERED|NONCLUSTERED]
INDEX index_name
ON table_name (column_name钬)
[WITH FILLFACTOR=x]
q UNIQUE琛ㄧず鍞涓绱㈠紩锛屽彲阃
q CLUSTERED銆丯ONCLUSTERED琛ㄧず镵氶泦绱㈠紩杩樻槸闱炶仛闆嗙储寮曪纴鍙阃
q FILLFACTOR琛ㄧず濉鍏呭洜瀛愶纴鎸囧畾涓涓0鍒100涔嬮棿镄勫硷纴璇ュ兼寚绀虹储寮曢〉濉婊＄殑绌洪棿镓鍗犵殑锏惧垎姣

鍦╯tuMarks琛ㄧ殑writtenExam鍒楀垱寤虹储寮曪细
USE stuDB
GO
IF EXISTS (SELECT name FROM sysindexes
WHERE name = 'IX_writtenExam')
DROP INDEX stuMarks.IX_writtenExam
/*--绗旇瘯鍒楀垱寤洪潪镵氶泦绱㈠紩锛氩～鍏呭洜瀛愪负30锛--*/
CREATE NONCLUSTERED INDEX IX_writtenExam
ON stuMarks(writtenExam)
WITH FILLFACTOR= 30
GO
/*-----鎸囧畾鎸夌储寮 IX_writtenExam 镆ヨ----*/
SELECT * FROM stuMarks (INDEX=IX_writtenExam)
WHERE writtenExam BETWEEN 60 AND 90
铏界劧鎴戜滑鍙浠ユ寚瀹歋QL Server鎸夊摢涓绱㈠紩杩涜屾暟鎹镆ヨ锛屼絾涓鑸涓嶉渶瑕佹垜浠浜哄伐鎸囧畾銆係QL Server灏嗕细镙规嵁鎴戜滑鍒涘缓镄勭储寮曪纴镊锷ㄤ紭鍖栨煡璇銆

绱㈠紩镄勪紭缂虹偣
• 浼樼偣
钬 锷犲揩璁块梾阃熷害
钬 锷犲己琛岀殑鍞涓镐
• 缂虹偣
钬 甯︾储寮旷殑琛ㄥ湪鏁版嵁搴扑腑闇瑕佹洿澶氱殑瀛桦偍绌洪棿
钬 镎岖旱鏁版嵁镄勫懡浠ら渶瑕佹洿闀跨殑澶勭悊镞堕棿锛屽洜涓哄畠浠闇瑕佸圭储寮曡繘琛屾洿鏂

鍒涘缓绱㈠紩镄勬寚瀵煎师鍒
• 璇锋寜镦т笅鍒楁爣鍑嗛夋嫨寤虹珛绱㈠紩镄勫垪銆
钬 璇ュ垪鐢ㄤ簬棰戠箒鎼灭储
钬 璇ュ垪鐢ㄤ簬瀵规暟鎹杩涜屾帓搴
• 璇蜂笉瑕佷娇鐢ㄤ笅闱㈢殑鍒楀垱寤虹储寮曪细
钬 鍒椾腑浠呭寘钖鍑犱釜涓嶅悓镄勫笺
钬 琛ㄤ腑浠呭寘钖鍑犺屻备负灏忓瀷琛ㄥ垱寤虹储寮曞彲鑳戒笉澶鍒掔畻锛屽洜涓篠QL Server鍦ㄧ储寮曚腑鎼灭储鏁版嵁镓鑺辩殑镞堕棿姣斿湪琛ㄤ腑阃愯屾悳绱㈡墍鑺辩殑镞堕棿镟撮暱

❷ 姹傝В锛屽叧浜岙QL缁栾〃鍒涘缓绱㈠紩鍜岃嗗浘镄勯梾棰桡纴钖勪綅甯甯蹇

绱㈠紩镄勪娇鐢ㄦ槸鏁版嵁搴撹嚜锷ㄥ畬鎴愮殑锛屼笉闇瑕佺壒鍒璋幂敤锛佷娇鐢ㄧ储寮曞彲浠ュ姞蹇镆ヨ㈤熷害锛屽彲浠ュ弬钥冧互涓嬬殑锏惧害锏剧戣存槑锛

浣跨敤绱㈠紩鍙蹇阃熻块梾琛ㄤ腑镄勭壒瀹氢俊鎭銆傜储寮曟槸瀵规暟鎹搴撹〃涓涓鍒楁垨澶氩垪镄勫艰繘琛屾帓搴忕殑涓绉岖粨鏋勶纴渚嫔 employee 琛ㄧ殑濮掳纸name锛夊垪銆傚傛灉瑕佹寜濮撴煡镓剧壒瀹氲亴锻桡纴涓庡繀椤绘悳绱㈣〃涓镄勬墍链夎岀浉姣旓纴绱㈠紩浼氩府锷╂偍镟村揩鍦拌幏寰楄ヤ俊鎭銆
銆銆鍦ㄥ叧绯绘暟鎹搴扑腑锛岀储寮曟槸涓绉崭笌琛ㄦ湁鍏崇殑鏁版嵁搴撶粨鏋勶纴瀹冨彲浠ヤ娇瀵瑰簲浜庤〃镄凷QL璇鍙ユ墽琛屽缑镟村揩銆傜储寮旷殑浣灭敤鐩稿綋浜庡浘涔︾殑鐩褰曪纴鍙浠ユ牴鎹鐩褰曚腑镄勯〉镰佸揩阃熸垒鍒版墍闇镄勫唴瀹广傚綋琛ㄤ腑链夊ぇ閲忚板綍镞讹纴鑻ヨ佸硅〃杩涜屾煡璇锛岀涓绉嶆悳绱淇℃伅鏂瑰纺鏄鍏ㄨ〃鎼灭储锛屾槸灏嗘墍链夎板綍涓涓鍙栧嚭锛屽拰镆ヨ㈡浔浠惰繘琛屼竴涓瀵规瘆锛岀劧钖庤繑锲炴弧瓒虫浔浠剁殑璁板綍锛岃繖镙峰仛浼氭秷钥楀ぇ閲忔暟鎹搴撶郴缁熸椂闂达纴骞堕犳垚澶ч噺纾佺洏I/O镎崭綔锛涚浜岀嶅氨鏄鍦ㄨ〃涓寤虹珛绱㈠紩锛岀劧钖庡湪绱㈠紩涓镓惧埌绗﹀悎镆ヨ㈡浔浠剁殑绱㈠紩鍊硷纴链钖庨氲繃淇濆瓨鍦ㄧ储寮曚腑镄凴OWID锛堢浉褰扑簬椤电爜锛夊揩阃熸垒鍒拌〃涓瀵瑰簲镄勮板綍銆
銆銆绱㈠紩鏄涓涓鍗旷嫭镄勚佺墿鐞嗙殑鏁版嵁搴撶粨鏋勶纴瀹冩槸镆愪釜琛ㄤ腑涓鍒楁垨鑻ュ共鍒楀肩殑闆嗗悎鍜岀浉搴旂殑鎸囧悜琛ㄤ腑鐗╃悊镙囱瘑杩欎簺鍊肩殑鏁版嵁椤电殑阃昏緫鎸囬拡娓呭崟銆
銆銆绱㈠紩鎻愪緵鎸囧悜瀛桦偍鍦ㄨ〃镄勬寚瀹氩垪涓镄勬暟鎹鍊肩殑鎸囬拡锛岀劧钖庢牴鎹鎭ㄦ寚瀹氱殑鎺掑簭椤哄簭瀵硅繖浜涙寚阍堟帓搴忋傛暟鎹搴扑娇鐢ㄧ储寮旷殑鏂瑰纺涓庢偍浣跨敤涔︾睄涓镄勭储寮旷殑鏂瑰纺寰堢浉浼硷细瀹冩悳绱㈢储寮曚互镓惧埌鐗瑰畾鍊硷纴铹跺悗椤烘寚阍堟垒鍒板寘钖璇ュ肩殑琛屻
銆銆鍦ㄦ暟鎹搴揿叧绯诲浘涓锛屾偍鍙浠ュ湪阃夊畾琛ㄧ殑钬灭储寮/阌钬濆睘镐ч〉涓鍒涘缓銆佺紪杈戞垨鍒犻櫎姣忎釜绱㈠紩绫诲瀷銆傚綋淇濆瓨绱㈠紩镓闄勫姞鍒扮殑琛锛屾垨淇濆瓨璇ヨ〃镓鍦ㄧ殑鍏崇郴锲炬椂锛岀储寮曞皢淇濆瓨鍦ㄦ暟鎹搴扑腑銆

涓鑸鏁版嵁搴揿湪寤虹珛镞剁殑榛樿ょ储寮曟槸涓婚敭锛屼絾鏄鍦ㄤ娇鐢ㄦ煡璇㈣繃绋嬩腑链変簺瀛楁靛线寰浣滀负缁忓父镄勬绱㈡浔浠讹纴姣旀柟璇村叆搴撴椂闂淬佸揿悕銆佺岖被绛夈傚傛灉涓嶅熀浜庝富阌镄勬煡璇㈢粡甯稿彂鐢熺殑璇濓纴鍦ㄨ繖浜涙煡璇㈠瓧娈典笂寤虹珛绱㈠紩鍙浠ュ姞蹇镆ヨ㈤熷害锛屾彁浜ょ▼搴忕殑鍙嶅簲镐ц兘锛

瀵逛簬瑙嗗浘锛屼竴涓鏄绠鍗曟柟渚挎煡璇锛屽悓镞朵篃鎻愰珮瀹夊叏镐э纴鍙鍙傝幂栌搴︾栌绉戜粙缁
銆銆* 绠鍗曟с傜湅鍒扮殑灏辨槸闇瑕佺殑銆傝嗗浘涓崭粎鍙浠ョ亩鍖栫敤鎴峰规暟鎹镄勭悊瑙ｏ纴涔熷彲浠ョ亩鍖栦粬浠镄勬搷浣溿傞偅浜涜缁忓父浣跨敤镄勬煡璇㈠彲浠ヨ瀹氢箟涓鸿嗗浘锛屼粠钥屼娇寰楃敤鎴蜂笉蹇呬负浠ュ悗镄勬搷浣沧疮娆℃寚瀹氩叏閮ㄧ殑𨱒′欢銆

銆銆* 瀹夊叏镐с傞氲繃瑙嗗浘鐢ㄦ埛鍙鑳芥煡璇㈠拰淇鏀逛粬浠镓鑳借佸埌镄勬暟鎹銆傛暟鎹搴扑腑镄勫叾瀹冩暟鎹鍒欐棦鐪嬩笉瑙佷篃鍙栦笉鍒般傛暟鎹搴撴巿𨱒冨懡浠ゅ彲浠ヤ娇姣忎釜鐢ㄦ埛瀵规暟鎹搴撶殑妫绱㈤檺鍒跺埌鐗瑰畾镄勬暟鎹搴揿硅薄涓婏纴浣嗕笉鑳芥巿𨱒冨埌鏁版嵁搴撶壒瀹氲屽拰鐗瑰畾镄勫垪涓娿傞氲繃瑙嗗浘锛岀敤鎴峰彲浠ヨ闄愬埗鍦ㄦ暟鎹镄勪笉钖屽瓙闆嗕笂锛

銆銆浣跨敤𨱒冮檺鍙琚闄愬埗鍦ㄥ彟涓瑙嗗浘镄勪竴涓瀛愰泦涓婏纴鎴栨槸涓浜涜嗗浘鍜屽熀琛ㄥ悎骞跺悗镄勫瓙闆嗕笂銆

銆銆* 阃昏緫鏁版嵁镫绔嬫с傝嗗浘鍙甯锷╃敤鎴峰睆钄界湡瀹炶〃缁撴瀯鍙桦寲甯︽潵镄勫奖鍝嶃

❸ sqlserver 怎么建索引

（1）在SQL Server Management Studio中，选择并右击要创建索引的表，从弹出菜单中选择“设计”，打开表设计器。右键单击表设计器，从弹出菜单中选择“索引/键”命令，打开“索引/键”对话框。对话框中列出了已经存在的索引，如下图所示。
（2）单击“添加”按钮。在“选定的主/唯一键或索引”框显示系统分配给新索引的名称。
（3）在“列”属性下选择要创建索引的列。可以选择多达16列。为获得最佳性能，最好只选择一列或两列。对所选的每一列，可指出索引是按升序还是降序组织列值。
（4）如果要创建唯一索引，则在“是唯一的”属性中选择“是”。
（5）设置完成后，单击“确定”按钮。
（6）当保存表时，索引即创建在数据库中。
使用CREATE INDEX语句创建索引：
复制内容到剪贴板
代码:
CREATE[ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX索引名
ON {表名|视图名} (列名[ ASC | DESC ] [ ,...n ] )
例：
在数据库HrSystem中为表Employees创建基于IDCard列的唯一索引IX_Employees，可以使用以下命令：
复制内容到剪贴板
代码:
USE HrSystem
GO
CREATE UNIQUE NONCLUSTERED INDEX [IX_Employees]ONdbo.Employees(IdCard)
GO
例：
为表Employees创建基于列IDCard的唯一、聚集索引IX_Employees1，可以使用以下命令：
复制内容到剪贴板
代码:
USE HrSystem
GO
CREATE UNIQUE CLUSTERED INDEX [IX_Employees1] ON [dbo].[Employees](IdCard)
GO
需要注意的是，在一个表中只允许存在一个聚集索引。因此，如果表Employees中已经存在一个聚集索引，则执行上面的语句时将会提示下面的错误信息。
消息1902，级别16，状态3，第1行
无法对表'dbo.Employees'创建多个聚集索引。请在创建新聚集索引前删除现有的聚集索引'PK__Employee__263E2DD300551192'。 例：
对表Employees的列Emp_name按照降序创建索引，可以使用以下命令：
复制内容到剪贴板
代码:
USE HrSystem
GO
CREATENONCLUSTERED INDEX [IX_Employees2] ON [dbo].[Employees]
(
[Emp_name] DESC
)
GO
在CREATE INDEX语句中使用INCLUDE子句，可以在创建索引时定义包含的非键列，其语法结构如下：
复制内容到剪贴板
代码:
CREATENONCLUSTERED INDEX 索引名
ON { 表名| 视图名 } ( 列名 [ ASC | DESC ] [ ,...n ] )
INCLUDE (<列名1>, <列名2>, [,… n])
例： 在表Employees上创建非聚集索引IX_Wage，索引中的键列为Wage，非键列为Emp_name、Sex和Title，具体语句如下：
复制内容到剪贴板
代码:
USEHrSystem
GO
CREATENONCLUSTERED INDEX IX_Wage
ON Employees ( Wage )
INCLUDE (Emp_name, Sex, Title)
GO
例： 在创建索引IX_Wage后，当表Employees中的数据量比较大时，执行下面的SELECT语句将会明显地改进查询效率。
复制内容到剪贴板
代码:
USEHrSystem
GO
SELECTEmp_name, Sex, Title, Wage
FROMEmployees
WHEREWage BETWEEN 1000 AND 3000
GO
修改索引：
在SQL Server Management Studio中，选择并右击要创建索引的表，从弹出的菜单中选择“设计表”，打开表设计器。右键单击表设计器，从弹出菜单中选择“索引/键”命令，打开“索引/键”对话框，并查看已经存在的索引及修改索引的属性信息。
也可以使用ALTER INDEX语句修改索引，其基本语法如下：
复制内容到剪贴板
代码:
ALTER INDEX { 索引名| ALL }
ON <表名|视图名>
{ REBUILD | DISABLE | REORGANIZE }[ ; ]
ALTER INDEX语句的参数比较复杂，这里只介绍它的基本使用情况。参数说明如下：
REBUILD指定重新生成索引。 DISABLE指定将索引标记为已禁用。 REORGANIZE指定将重新组织的索引叶级。
例：
要禁用索引IX_Employees，可以使用下面的语句：
复制内容到剪贴板
代码:
USE HrSystem
GO
ALTERINDEX IX_Employees ON Employees DISABLE
GO
删除索引：
在SQL Server Management Studio中，选择并右击要创建索引的表，从弹出的菜单中选择“设计表”。打开表设计器。右键单击表设计器，从弹出菜单中选择“索引/键”命令，在打开的“索引/键”对话框中列出了已经存在的索引。单击“删除”按钮，即可删除索引信息。
复制内容到剪贴板
代码:
DROP INDEX 表名.索引名|视图名.索引名[ ,...n ]
总结：
o（1）索引并非越多越好，一个表中如果有大量的索引，不仅占用大量的磁盘空间，而且会影响INSERT、DELETE、UPDATE等语句的性能。因为当表中数据更改的同时，索引也会进行调整和更新。
o（2）避免对经常更新的表进行过多的索引，并且索引中的列尽可能少。而对经常用于查询的字段应该创建索引，但要避免添加不必要的字段。
o（3）数据量小的表最好不要使用索引，由于数据较少，查询花费的时间可能比遍历索引的时间还要短，索引可能不会产生优化效果。
o（4）在条件表达式中经常用到的、不同值较多的列上建立索引，在不同值少的列上不要建立索引。比如在学生表的“性别”字段上只有“男”与“女”两个不同值，因此就无须建立索引。如果建立索引，不但不会提高查询效率，反而会严重降低更新速度。
o（5）当唯一性是某种数据本身的特征时，指定唯一索引。使用唯一索引能够确保定义的列的数据完整性，提高查询速度。
o（6）在频繁进行排序或分组（即进行GROUPBY或ORDERBY操作）的列上建立索引，如果待排序的列有多个，可以在这些列上建立组合索引。

❹ sql server merger into如何建索引

第一步，我们打开数据库，找到一个表，打开索引文件夹，你会发现已经有一个索引了，它是表的主键。
第二步，我们选择索引文件夹，右键单击选择新建索引选项。
第三步，在弹出的新建索引界面，如果你的索引类型选择聚集的话，会提示你已经存在聚集索引，这是因为主键默认就是聚集索引。
第四步，然后添加索引列，同时在索引新建界面给索引起一个索引名称，勾选唯一。
索引创建好了以后，你就会在索引文件夹下面看到你刚才创建的索引了。

❺ SQL表字段如何建立索引难道就是添加SQL查询语句

1、创建测试表，

create table test_index(id varchar2(20)， v_date date);

❻ 如何重建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

❼ 在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的数据源是基表