⑴ DB2資料庫索引問題-怎樣更快更效率
1.只對唯一性較強並且使用較頻繁的欄位建立單個索引，比如分別對key、a 建立索引。目前上海移動經分倉庫就是按這個大的原則建立的。
因為聯合索引的話對條件查詢的順序打亂就無效了，單獨建立索引用來適應大多數開發情況，且能較少數據冗餘。
2.針對某些特別慢的sql條件建立索引，這種情況是考慮某些SQL的及時性考慮，及時性高的，SQL的結果集重要的，單獨優化。
⑵ 在SQL SERVER中索引是什麼
一般格式為：
CREATE [UNIQUE] [CLUSTER] INDEX <索引名>
ON <表名> (<列名> [<次序>] [,<列名>[<次序>]]…);
索引的有關說明
可以動態地定義索引，即可以隨時建立和刪除索引
不允許用戶在數據操作中引用索引。索引如何使用完全由系統決定，這支持了數據的物理獨立性
應該在使用頻率高的、經常用於連接的列上建索引
一個表上可建多個索引。索引可以提高查詢效率，但索引過多耗費空間，且降低了插入、刪除、更新的效率
⑶ sql2000當對資料庫的數據進行增加和更新時，索引怎麼維護
可以自動，也可以手動。
你在SQL的企業管理器里，在你要維護的那資料庫右擊，選擇所有任務裡面的維護計劃命令。在設置的過程中就有這一個選項。
⑷ sql-server的視圖索引是靜態的還是動態的請說明原因
sqlserver 索引視圖 對 版本有 要求，體驗版沒這功能，開發，企業版倒是可以用。
如果是體驗版，建議你用表結構吧！
CREATEVIEWV_[ID],COUNT_BIG(*)asQumFROM[dbo].[StrText]_Remark_UCI_IDONV_Remark([ID])
⑸ 怎樣給sql語句索引
這個語句用不了索引,因為第一個謂詞title<>''是個不等於,使用索引掃描和表掃描是一樣的,第二個謂詞是字元串匹配,索引也無法起到作用.所以對這個查詢,資料庫肯定是要執行表掃描,而且在URL這個欄位上還要執行字元串匹配,所以很慢
⑹ 支持動態索引的資料庫有哪些
資料庫索引是為了增加查詢速度而對表欄位附加的一種標識。見過很多人機械的理解索引的概念，認為增加索引只有好處沒有壞處。這里想把之前的索引學習筆記總結一下： 首先明白為什麼索引會增加速度，DB在執行一條Sql語句的時候，默認的方式是根據搜索條件進行全表掃描，遇到匹配條件的就加入搜索結果集合。如果我們對某一欄位增加索引，查詢時就會先去索引列表中一次定位到特定值的行數，大大減少遍歷匹配的行數，所以能明顯增加查詢的速度。那麼在任何時候都應該加索引么？這里有幾個反例：1、如果每次都需要取到所有表記錄，無論如何都必須進行全表掃描了，那麼是否加索引也沒有意義了。2、對非唯一的欄位，例如「性別」這種大量重復值的欄位，增加索引也沒有什麼意義。3、對於記錄比較少的表，增加索引不會帶來速度的優化反而浪費了存儲空間，因為索引是需要存儲空間的，而且有個致命缺點是對於update/insert/delete的每次執行，欄位的索引都必須重新計算更新。
⑺ SQL資料庫中 索引的動態性是什麼
建立索引是查詢SQL時提高效率，一般可以根據where條件後的欄位建立索引
⑻ 如何利用索引提高SQLServer數據處理的效率
在良好的資料庫設計基礎上，能有效地使用索引是SQL Server取得高性能的基礎，SQL Server採用基於代價的優化模型，它對每一個提交的有關表的查詢，決定是否使用索引或用哪一個索引。因為查詢執行的大部分開銷是磁碟I/O，使用索引提高性能的一個主要目標是避免全表掃描，因為全表掃描需要從磁碟上讀表的每一個數據頁，如果有索引指向數據值，則查詢只需讀幾次磁碟就可以了。
所以如果建立了合理的索引，優化器就能利用索引加速數據的查詢過程。但是，索引並不總是提高系統的性能，在增、刪、改操作中索引的存在會增加一定的工作量，因此，在適當的地方增加適當的索引並從不合理的地方刪除次優的索引，將有助於優化那些性能較差的SQL Server應用。實踐表明，合理的索引設計是建立在對各種查詢的分析和預測上的，只有正確地使索引與程序結合起來,才能產生最佳的優化方案。本文就SQL Server索引的性能問題進行了一些分析和實踐。
一、聚簇索引(clustered indexes)的使用
聚簇索引是一種對磁碟上實際數據重新組織以按指定的一個或多個列的值排序。由於聚簇索引的索引頁面指針指向數據頁面，所以使用聚簇索引查找數據幾乎總是比使用非聚簇索引快。每張表只能建一個聚簇索引，並且建聚簇索引需要至少相當該表120%的附加空間，以存放該表的副本和索引中間頁。建立聚簇索引的思想是：
1、大多數表都應該有聚簇索引或使用分區來降低對表尾頁的競爭，在一個高事務的環境中，對最後一頁的封鎖嚴重影響系統的吞吐量。
2、在聚簇索引下，數據在物理上按順序排在數據頁上，重復值也排在一起，因而在那些包含范圍檢查(between、<、<=、>、>=)或使用group by或order by的查詢時，一旦找到具有范圍中第一個鍵值的行，具有後續索引值的行保證物理上毗連在一起而不必進一步搜索，避免了大范圍掃描，可以大大提高查詢速度。
3、在一個頻繁發生插入操作的表上建立聚簇索引時，不要建在具有單調上升值的列(如IDENTITY)上，否則會經常引起封鎖沖突。
4、在聚簇索引中不要包含經常修改的列，因為碼值修改後，數據行必須移動到新的位置。
5、選擇聚簇索引應基於where子句和連接操作的類型。
聚簇索引的侯選列是：
1、主鍵列,該列在where子句中使用並且插入是隨機的。
2、按范圍存取的列，如pri_order > 100 and pri_order < 200。
3、在group by或order by中使用的列。
4、不經常修改的列。
5、在連接操作中使用的列。
二、非聚簇索引(nonclustered indexes)的使用
SQL Server預設情況下建立的索引是非聚簇索引，由於非聚簇索引不重新組織表中的數據，而是對每一行存儲索引列值並用一個指針指向數據所在的頁面。換句話說非聚簇索引具有在索引結構和數據本身之間的一個額外級。一個表如果沒有聚簇索引時,可有250個非聚簇索引。每個非聚簇索引提供訪問數據的不同排序順序。在建立非聚簇索引時，要權衡索引對查詢速度的加快與降低修改速度之間的利弊。另外，還要考慮這些問題：
1、索引需要使用多少空間。
2、合適的列是否穩定。
3、索引鍵是如何選擇的，掃描效果是否更佳。
4、是否有許多重復值。
對更新頻繁的表來說，表上的非聚簇索引比聚簇索引和根本沒有索引需要更多的額外開銷。對移到新頁的每一行而言，指向該數據的每個非聚簇索引的頁級行也必須更新，有時可能還需要索引頁的分理。從一個頁面刪除數據的進程也會有類似的開銷，另外，刪除進程還必須把數據移到頁面上部，以保證數據的連續性。所以，建立非聚簇索引要非常慎重。非聚簇索引常被用在以下情況：
1、某列常用於集合函數(如Sum,....)。
2、某列常用於join,order by,group by。
3、查尋出的數據不超過表中數據量的20%。
三、覆蓋索引(covering indexes)的使用
覆蓋索引是指那些索引項中包含查尋所需要的全部信息的非聚簇索引，這種索引之所以比較快也正是因為索引頁中包含了查尋所必須的數據,不需去訪問數據頁。如果非聚簇索引中包含結果數據,那麼它的查詢速度將快於聚簇索引。
但是由於覆蓋索引的索引項比較多,要佔用比較大的空間。而且update操作會引起索引值改變。所以如果潛在的覆蓋查詢並不常用或不太關鍵，則覆蓋索引的增加反而會降低性能。
四、索引的選擇技術
p_detail是住房公積金管理系統中記錄個人明細的表，有890000行，觀察在不同索引下的查詢運行效果，測試在C/S環境下進行，客戶機是IBM PII350(內存64M),伺服器是DEC Alpha1000A(內存128M),資料庫為SYBASE11.0.3。
1、 select count(*) from p_detail where
op_date>』19990101』 and op_date<』
19991231』 and pri_surplus1>300
2、 select count(*),sum(pri_surplus1) from p_detail
where op_date>』19990101』 and
pay_month between『199908』 and』199912』
不建任何索引查詢1 1分15秒
查詢2 1分7秒
在op_date上建非聚簇索引查詢1 57秒
查詢2 57秒
在op_date上建聚簇索引查詢1 <1秒
查詢2 52秒
在pay_month、op_date、pri_surplus1上建索引查詢1 34秒
查詢2 <1秒
在op_date、pay_month、pri_surplus1上建索引查詢1 <1秒
查詢2 <1秒
從以上查詢效果分析，索引的有無，建立方式的不同將會導致不同的查詢效果，選擇什麼樣的索引基於用戶對數據的查詢條件,這些條件體現於where從句和join表達式中。一般來說建立索引的思路是：
(1)主鍵時常作為where子句的條件，應在表的主鍵列上建立聚簇索引，尤其當經常用它作為連接的時候。
(2)有大量重復值且經常有范圍查詢和排序、分組發生的列，或者非常頻繁地被訪問的列，可考慮建立聚簇索引。
(3)經常同時存取多列，且每列都含有重復值可考慮建立復合索引來覆蓋一個或一組查詢，並把查詢引用最頻繁的列作為前導列，如果可能盡量使關鍵查詢形成覆蓋查詢。
(4)如果知道索引鍵的所有值都是唯一的，那麼確保把索引定義成唯一索引。
(5)在一個經常做插入操作的表上建索引時，使用fillfactor(填充因子)來減少頁分裂，同時提高並發度降低死鎖的發生。如果在只讀表上建索引，則可以把fillfactor置為100。
(6)在選擇索引鍵時，設法選擇那些採用小數據類型的列作為鍵以使每個索引頁能夠容納盡可能多的索引鍵和指針，通過這種方式，可使一個查詢必須遍歷的索引頁面降到最小。此外，盡可能地使用整數為鍵值，因為它能夠提供比任何數據類型都快的訪問速度。
五、索引的維護
上面講到,某些不合適的索引影響到SQL Server的性能,隨著應用系統的運行,數據不斷地發生變化,當數據變化達到某一個程度時將會影響到索引的使用。這時需要用戶自己來維護索引。索引的維護包括：
1、重建索引
隨著數據行的插入、刪除和數據頁的分裂，有些索引頁可能只包含幾頁數據，另外應用在執行大塊I/O的時候，重建非聚簇索引可以降低分片，維護大塊I/O的效率。重建索引實際上是重新組織B-樹空間。在下面情況下需要重建索引：
(1)數據和使用模式大幅度變化。
(2)排序的順序發生改變。
(3)要進行大量插入操作或已經完成。
(4)使用大塊I/O的查詢的磁碟讀次數比預料的要多。
(5)由於大量數據修改，使得數據頁和索引頁沒有充分使用而導致空間的使用超出估算。
(6)dbcc檢查出索引有問題。
當重建聚簇索引時，這張表的所有非聚簇索引將被重建。
2、索引統計信息的更新
當在一個包含數據的表上創建索引的時候，SQL Server會創建分布數據頁來存放有關索引的兩種統計信息：分布表和密度表。優化器利用這個頁來判斷該索引對某個特定查詢是否有用。但這個統計信息並不動態地重新計算。這意味著，當表的數據改變之後，統計信息有可能是過時的，從而影響優化器追求最有工作的目標。因此，在下面情況下應該運行update statistics命令：
(1)數據行的插入和刪除修改了數據的分布。
(2)對用truncate table刪除數據的表上增加數據行。
(3)修改索引列的值。
六、結束語
實踐表明，不恰當的索引不但於事無補，反而會降低系統的執行性能。因為大量的索引在插入、修改和刪除操作時比沒有索引花費更多的系統時間。例如下面情況下建立的索引是不恰當的：
1、在查詢中很少或從不引用的列不會受益於索引，因為索引很少或從來不必搜索基於這些列的行。
2、只有兩個或三個值的列，如男性和女性(是或否)，從不會從索引中得到好處。
另外，鑒於索引加快了查詢速度，但減慢了數據更新速度的特點。可通過在一個段上建表，而在另一個段上建其非聚簇索引，而這兩段分別在單獨的物理設備上來改善操作性能。
⑼ 如何檢查sql資料庫索引填充因子是否產生碎片以及如何處理
這是收藏的一些資料：
SQLServer提供了一個資料庫命令――DBCC SHOWCONTIG――來確定一個指定的表或索引是否有碎片。
示例：
顯示資料庫里所有索引的碎片信息
DBCC SHOWCONTIG WITH ALL_INDEXES
顯示指定表的所有索引的碎片信息
DBCC SHOWCONTIG (authors) WITH ALL_INDEXES
顯示指定索引的碎片信息
DBCC SHOWCONTIG (authors,aunmind)
DBCC 執行結果：
掃描頁數：如果你知道行的近似尺寸和表或索引里的行數，那麼你可以估計出索引里的頁數。看看掃描頁數，如果明顯比你估計的頁數要高，說明存在內部碎片。
掃描擴展盤區數：用掃描頁數除以8,四捨五入到下一個最高值。該值應該和DBCC SHOWCONTIG返回的掃描擴展盤區數一致。如果DBCC SHOWCONTIG返回的數高，說明存在外部碎片。碎片的嚴重程度依賴於剛才顯示的值比估計值高多少。
擴展盤區開關數：該數應該等於掃描擴展盤區數減1。高了則說明有外部碎片。
每個擴展盤區上的平均頁數：該數是掃描頁數除以掃描擴展盤區數，一般是8。小於8說明有外部碎片。
掃描密度［最佳值:實際值］：DBCC SHOWCONTIG返回最有用的一個百分比。這是擴展盤區的最佳值和實際值的比率。該百分比應該盡可能靠近100％。低了則說明有外部碎片。
邏輯掃描碎片：無序頁的百分比。該百分比應該在0％到10％之間，高了則說明有外部碎片。
擴展盤區掃描碎片：無序擴展盤區在掃描索引葉級頁中所佔的百分比。該百分比應該是0％，高了則說明有外部碎片。
每頁上的平均可用位元組數：所掃描的頁上的平均可用位元組數。越高說明有內部碎片，不過在你用這個數字決定是否有內部碎片之前，應該考慮fill factor（填充因子）。
平均頁密度（完整）：每頁上的平均可用位元組數的百分比的相反數。低的百分比說明有內部碎片。
解決碎片問題 ：
1. 刪除並重建索引
2. 使用DROP_EXISTING子句重建索引
3. 執行DBCC DBREINDEX
4. 執行DBCC INDEXDEFRAG
刪除並重建索引 ：
用DROP INDEX和CREATE INDEX或ALTER TABLE來刪除並重建索引有些缺陷包括在刪除重建期間索引會消失。在索引刪除重建時，對於查詢它不在可用，查詢性能也許會受到明顯的影響，直到重建索引為止。另一個潛在的缺陷是當都請求索引的時候會引起阻塞，直到重建索引為止。通過其他的處理也能解決阻塞，就是索引被使用的時候不刪除索引。另一個主要的缺陷是在用DROP INDEX和CREATE INDEX重建聚集索引時會引起非聚集索引重建兩次。刪除聚集索引時非聚集索引的行指針會指向數據堆，聚集索引重建時非聚集索引的行指針又會指回聚集索引的行位置。
刪除並重建索引的確有一個好處就是通過重新排序索引頁，使索引頁緊湊並刪除不需要的索引頁來完全重建索引。你也許需要考慮那些內部和外部碎片都很高的情況下才使用，以使那些索引回到它們應該在的位置。
使用DROP_EXISTING子句重建索引 ：
為了避免在重建聚集索引時表上的非聚集索引重建兩次，可以使用帶DROP_EXISTING子句的CREATE INDEX語句。這個子句會保留聚集索引鍵值，以避免非聚集索引重建兩次。和刪除並重建索引一樣，該方法也可能會引起阻塞和索引消失的問題。該方法的另一個缺陷是也強迫你去分別發現和修復表上的每一個索引。
除了和上一個方法一樣的好處之外，該方法的好處是不必重建非聚集索引兩次。這樣可以對那些帶約束的索引提供正確的索引定義以符合約束的要求。
執行DBCC DBREINDEX ：
DBCC DBREINDEX類似於第二種方法，但它物理地重建索引，允許SQLServer給索引分配新頁來減少內部和外部碎片。DBCC DBREINDEX也能動態的重建帶約束的索引，不象第二種方法。
DBCC DBREINDEX的缺陷是會遇到或引起阻塞問題。DBCC DBREINDEX是作為一個事務來運行的，所以如果在完成之前中斷了，那麼你會丟失所有已經執行過的碎片。
執行DBCC INDEXDEFRAG ：
DBCC INDEXDEFRAG（在SQLServer2000中可用）按照索引鍵的邏輯順序，通過重新整理索引里存在的葉頁來減少外部碎片，通過壓縮索引頁里的行然後刪除那些由此產生的不需要的頁來減少內部碎片。它不會遇到阻塞問題但它的結果沒有其他幾個方法徹底。這是因為DBCC INDEXDEFRAG跳過了鎖定的頁且不使用任何新頁來重新排序索引。如果索引的碎片數量大的話你也許會發現DBCC INDEXDEFRAG比重建索引花費的時間更長。DBCC INDEXDEFRAG比其他方法的確有好處的是在其他過程訪問索引時也能進行碎片整理，不會引起其他方法的阻塞問題。
⑽ SQL注入以及如何防止和索引
1.永遠不要信任用戶的輸入，要對用戶的輸入進行校驗，可以通過正則表達式，或限制長度，對單引號和雙"-"進行轉換等。
2.永遠不要使用動態拼裝SQL，可以使用參數化的SQL或者直接使用存儲過程進行數據查詢存取。
3.永遠不要使用管理員許可權的資料庫連接，為每個應用使用單獨的許可權有限的資料庫連接。
4.不要把機密信息明文存放，請加密或者hash掉密碼和敏感的信息。
5.應用的異常信息應該給出盡可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝，把異常信息存放在獨立的表中。