壓縮鍵索引

1. 如何檢查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比其他方法的確有好處的是在其他過程訪問索引時也能進行碎片整理，不會引起其他方法的阻塞問題。

2. mySQL的索引功能

索引是一種特殊的文件（InnoDB 數據表上的索引是表空間的一個組成部分），它們包含著對數據表裡所有記錄的引用指針。索引不是萬能的，索引可以加快數據檢索操作，但會使數據修改操作變慢。每修改數據記錄，索引就必須刷新一次。為了在某種程度上彌補這一缺陷，許多 SQL 命令都有一個 DELAY_KEY_WRITE 項。這個選項的作用是暫時制止 MySQL 在該命令每插入一條新記錄和每修改一條現有之後立刻對索引進行刷新，對索引的刷新將等到全部記錄插入/修改完畢之後再進行。在需要把許多新記錄插入某個數據表的場合，DELAY_KEY_WRITE 選項的作用將非常明顯。另外，索引還會在硬碟上佔用相當大的空間。因此應該只為最經常查詢和最經常排序的數據列建立索引。注意，如果某個數據列包含許多重復的內容，為它建立索引就沒有太大的實際效果。
從理論上講，完全可以為數據表裡的每個欄位分別建一個索引，但 MySQL 把同一個數據表裡的索引總數限制為16個。
1．InnoDB 數據表的索引
與 InnoDB數據表相比，在 InnoDB 數據表上，索引對 InnoDB 數據表的重要性要大得多。在 InnoDB 數據表上，索引不僅會在搜索數據記錄時發揮作用，還是數據行級鎖定機制的苊、基礎。「數據行級鎖定」的意思是指在事務操作的執行過程中鎖定正在被處理的個別記錄，不讓其他用戶進行訪問。這種鎖定將影響到（但不限於）SELECT、LOCKINSHAREMODE、SELECT、FORUPDATE 命令以及 INSERT、UPDATE 和 DELETE 命令。出於效率方面的考慮，InnoDB 數據表的數據行級鎖定實際發生在它們的索引上，而不是數據表自身上。顯然，數據行級鎖定機制只有在有關的數據表有一個合適的索引可供鎖定的時候才能發揮效力。
2．限制
如果 WHERE 子句的查詢條件里有不等號（WHERE coloum !=），MySQL 將無法使用索引。類似地，如果 WHERE 子句的查詢條件里使用了函數（WHERE DAY（column）=），MySQL 也將無法使用索引。在 JOIN 操作中（需要從多個數據表提取數據時），MySQL 只有在主鍵和外鍵的數據類型相同時才能使用索引。
如果 WHERE 子句的查詢條件里使用比較操作符 LIKE 和 REGEXP，MySQL 只有在搜索模板的第一個字元不是通配符的情況下才能使用索引。比如說，如果查詢條件是 LIKE 'abc%『，MySQL 將使用索引；如果查詢條件是 LIKE '%abc』，MySQL 將不使用索引。
在 ORDER BY 操作中，MySQL 只有在排序條件不是一個查詢條件表達式的情況下才使用索引。（雖然如此，在涉及多個數據表查詢里，即使有索引可用，那些索引在加快 ORDER BY 方面也沒什麼作用）。如果某個數據列里包含許多重復的值，就算為它建立了索引也不會有很好的效果。比如說，如果某個數據列里包含的凈是些諸如 「0/1」 或 「Y/N」 等值，就沒有必要為它創建一個索引。 1．普通索引
普通索引（由關鍵字 KEY 或 INDEX 定義的索引）的唯一任務是加快對數據的訪問速度。因此，應該只為那些最經常出現在查詢條件（WHERE column =）或排序條件（ORDER BY column）中的數據列創建索引。只要有可能，就應該選擇一個數據最整齊、最緊湊的數據列（如一個整數類型的數據列）來創建索引。
2．唯一索引
普通索引允許被索引的數據列包含重復的值。比如說，因為人有可能同名，所以同一個姓名在同一個「員工個人資料」數據表裡可能出現兩次或更多次。
如果能確定某個數據列將只包含彼此各不相同的值，在為這個數據列創建索引的時候就應該用關鍵字UNIQUE 把它定義為一個唯一索引。這么做的好處：一是簡化了 MySQL 對這個索引的管理工作，這個索引也因此而變得更有效率；二是 MySQL 會在有新記錄插入數據表時，自動檢查新記錄的這個欄位的值是否已經在某個記錄的這個欄位里出現過了；如果是，MySQL 將拒絕插入那條新記錄。也就是說，唯一索引可以保證數據記錄的唯一性。事實上，在許多場合，人們創建唯一索引的目的往往不是為了提高訪問速度，而只是為了避免數據出現重復。
3．主索引
在前面已經反復多次強調過：必須為主鍵欄位創建一個索引，這個索引就是所謂的「主索引」。主索引與唯一索引的唯一區別是：前者在定義時使用的關鍵字是 PRIMARY 而不是 UNIQUE。
4．外鍵索引
如果為某個外鍵欄位定義了一個外鍵約束條件，MySQL 就會定義一個內部索引來幫助自己以最有效率的方式去管理和使用外鍵約束條件。
5．復合索引
索引可以覆蓋多個數據列，如像 INDEX (columnA, columnB) 索引。這種索引的特點是 MySQL 可以有選擇地使用一個這樣的索引。如果查詢操作只需要用到 columnA 數據列上的一個索引，就可以使用復合索引 INDEX(columnA, columnB)。不過，這種用法僅適用於在復合索引中排列在前的數據列組合。比如說，INDEX (A，B，C) 可以當做 A 或 (A,B) 的索引來使用，但不能當做 B、C 或 (B,C) 的索引來使用。 在為 CHAR 和 VARCHAR 類型的數據列定義索引時，可以把索引的長度限制為一個給定的字元個數（這個數字必須小於這個欄位所允許的最大字元個數）。這么做的好處是可以生成一個尺寸比較小、檢索速度卻比較快的索引文件。在絕大多數應用里，資料庫中的字元串數據大都以各種各樣的名字為主，把索引的長度設置為10~15 個字元已經足以把搜索范圍縮小到很少的幾條數據記錄了。在為 BLOB 和 TEXT 類型的數據列創建索引時，必須對索引的長度做出限制；MySQL 所允許的最大索引全文索引文本欄位上的普通索引只能加快對出現在欄位內容最前面的字元串（也就是欄位內容開頭的字元）進行檢索操作。如果欄位里存放的是由幾個、甚至是多個單詞構成的較大段文字，普通索引就沒什麼作用了。這種檢索往往以的形式出現，這對 MySQL 來說很復雜，如果需要處理的數據量很大，響應時間就會很長。
這類場合正是全文索引（full-textindex）可以大顯身手的地方。在生成這種類型的索引時，MySQL 將把在文本中出現的所有單詞創建為一份清單，查詢操作將根據這份清單去檢索有關的數據記錄。全文索引即可以隨數據表一同創建，也可以等日後有必要時再使用下面這條命令添加：
ALTER TABLE tablename ADD FULLTEXT（column1，column2）有了全文索引，就可以用 SELECT 查詢命令去檢索那些包含著一個或多個給定單詞的數據記錄了。下面是這類查詢命令的基本語法：
SELECT * FROM tablename
WHERE MATCH (column1,column2) AGAINST('word1','word2','word3')
上面這條命令將把 column1 和 column2 欄位里有 word1、word2 和 word3 的數據記錄全部查詢出來。
註解：InnoDB 數據表不支持全文索引。 只有當資料庫里已經有了足夠多的測試數據時，它的性能測試結果才有實際參考價值。如果在測試資料庫里只有幾百條數據記錄，它們往往在執行完第一條查詢命令之後就被全部載入到內存里，這將使後續的查詢命令都執行得非常快--不管有沒有使用索引。只有當資料庫里的記錄超過了 1000 條、數據總量也超過了 MySQL 伺服器上的內存總量時，資料庫的性能測試結果才有意義。
在不確定應該在哪些數據列上創建索引的時候，人們從 EXPLAIN SELECT 命令那裡往往可以獲得一些幫助。這其實只是簡單地給一條普通的 SELECT 命令加一個 EXPLAIN 關鍵字作為前綴而已。有了這個關鍵字，MySQL 將不是去執行那條 SELECT 命令，而是去對它進行分析。MySQL 將以表格的形式把查詢的執行過程和用到的索引等信息列出來。
在 EXPLAIN 命令的輸出結果里，第1列是從資料庫讀取的數據表的名字，它們按被讀取的先後順序排列。type列指定了本數據表與其它數據表之間的關聯關系（JOIN）。在各種類型的關聯關系當中，效率最高的是 system，然後依次是 const、eq_ref、ref、range、index 和 All（All 的意思是：對應於上一級數據表裡的每一條記錄，這個數據表裡的所有記錄都必須被讀取一遍——這種情況往往可以用一索引來避免）。
possible_keys 數據列給出了 MySQL 在搜索數據記錄時可選用的各個索引。key 數據列是 MySQL 實際選用的索引，這個索引按位元組計算的長度在 key_len 數據列里給出。比如說，對於一個 INTEGER 數據列的索引，這個位元組長度將是4。如果用到了復合索引，在 key_len 數據列里還可以看到 MySQL 具體使用了它的哪些部分。作為一般規律，key_len 數據列里的值越小越好。
ref 數據列給出了關聯關系中另一個數據表裡的數據列的名字。row 數據列是 MySQL 在執行這個查詢時預計會從這個數據表裡讀出的數據行的個數。row 數據列里的所有數字的乘積可以大致了解這個查詢需要處理多少組合。
最後，extra 數據列提供了與 JOIN 操作有關的更多信息，比如說，如果 MySQL 在執行這個查詢時必須創建一個臨時數據表，就會在 extra 列看到 usingtemporary 字樣。

3. oracle 索引使用鍵壓縮的問題

就是壓縮兩列的意思，你那個例子就是壓縮ename,esex這兩例

使用Oracle索引壓縮技術,減少空間佔用,並提高大數據量訪問情況下的速度.
索引壓縮僅用於復合索引,即多個欄位建立一個索引的情況,通過compress參數指定壓縮哪些欄位.
雖然壓縮後的索引,相對來說需要花費更多的CPU時間來處理,
但是,這樣做後,可以在高速緩沖區中緩存更多的索引塊,當大范圍的掃描時,能夠減少物理IO的數量.