資料庫索引原理的作用

㈠ 為什麼資料庫表要建立索引

索引是以表列來為基礎的資料庫對象自。索引中保存著表中排序的索引列，並且紀錄了索引列在資料庫表中的物理存儲位置，實現了表中數據的邏輯排序。通過索引，可以加快數據的查詢速度和減少系統的響應時間;可以使表和表之間的連接速度加快。 用SQL建立索引： 為了給一個表建立索引，啟動任務欄SQL Sever程序組中的ISQL/w程序。進入查詢窗口後，輸入下面的語句： CREATE [UNIQUE] [CLUSER] INDEX ON (); UNIQUE 表明此索引的每一個索引值只對應唯一的數據記錄 CLUSTER 表明要建立的是聚簇索引（指索引項的順序與表中記錄的物理順序一致） 例：CREATE CLUSER INDEX Stuname ON Student(Sname); 在student表的sname列建立一個聚簇索引，student中記錄按照sname值的升序排列 參考資料： <

㈡ 資料庫索引原理

資料庫索引原理如下：

使用索引可快速訪問資料庫表中的特定信息。如果想按特定職員的姓來查找人員，則與在表中搜索所有的行相比，索引有助於更快地獲取信息。

索引的實現通常使用B樹及其變種B+樹。在數據之外，資料庫系統還維護著滿足特定查找演算法的數據結構，這些數據結構以某種方式引用（指向）數據，這樣就可以在這些數據結構上實現高級查找演算法。

(2)資料庫索引原理的作用擴展閱讀：

對於有些列不應該創建索引。一般來說，不應該創建索引的的這些列具有下列特點：

1、查詢很少：

對於那些在查詢中很少使用或者參考的列不應該創建索引。這是因為，既然這些列很少使用到，因此有索引或者無索引，並不能提高查詢速度。相反，由於增加了索引，反而降低了系統的維護速度和增大了空間需求。

2、少數據值：

對於那些只有很少數據值的列也不應該增加索引。這是因為，由於這些列的取值很少，例如人事表的性別列，在查詢的結果中，結果集的數據行佔了表中數據行的很大比例，即需要在表中搜索的數據行的比例很大。增加索引，並不能明顯加快檢索速度。

3、定義類型：

對於那些定義為text, image和bit數據類型的列不應該增加索引。這是因為，這些列的數據量要麼相當大，要麼取值很少。

㈢ 資料庫中的索引是什麼意思有什麼用途

索引是一種單獨的、物理的對資料庫表中一列或多列的值進行排序的一種存儲結構，它是某個表中一列或若干列值的集合和相應的指向表中物理標識這些值的數據頁的邏輯指針清單。索引的作用相當於圖書的目錄，可以根據目錄中的頁碼快速找到所需的內容。

一個索引是存儲的表中一個特定列的值數據結構（最常見的是B-Tree,還有哈希表索引和R-tree）。索引是在表的列上創建。所以，要記住的關鍵點是索引包含一個表中列的值，並且這些值存儲在一個數據結構中。請記住記住這一點：索引是一種數據結構

使用索引的全部意義就是通過縮小一張表中需要查詢的記錄（行）的數目來加快搜索的速度。

假設有一張學生名單表，有一百條數據。要查詢其中名字為 小明 的學生。

一般採取select * from students where name ='小明';由於我們想要得到每一個名字為小明的學生信息，在查詢到第一個符合條件的行後，不能停止查詢，因為可能還有其他符合條件的行。所以，必須一行一行的查找直到最後一行-這就意味資料庫不得不檢查上千行數據才能找到所以名字為小明的學生。這就是所謂的全表掃描。

假設我們在 name這一列上創建一個B-Tree索引。當我們用SQL查找名字是『小明』的學生時，不需要再掃描全表。而是用索引查找去查找名字為『小明』的學生，因為索引已經按照按字母順序排序。索引已經排序意味著查詢一個名字會快很多，因為名字首字母為『小』的學生都是排列在一起的。另外重要的一點是，索引同時存儲了表中相應行的指針以獲取其他列的數據。

㈣ 資料庫索引有什麼作用和好處

資料庫索引是為了增加查詢速度而對表欄位附加的一種標識。見過很多人機械的理解索引的概念，認為增加索引只有好處沒有壞處。這里想把之前的索引學習筆記總結一下：
首先明白為什麼索引會增加速度，DB在執行一條Sql語句的時候，默認的方式是根據搜索條件進行全表掃描，遇到匹配條件的就加入搜索結果集合。如果我們對某一欄位增加索引，查詢時就會先去索引列表中一次定位到特定值的行數，大大減少遍歷匹配的行數，所以能明顯增加查詢的速度。那麼在任何時候都應該加索引么？這里有幾個反例：1、如果每次都需要取到所有表記錄，無論如何都必須進行全表掃描了，那麼是否加索引也沒有意義了。2、對非唯一的欄位，例如「性別」這種大量重復值的欄位，增加索引也沒有什麼意義。3、對於記錄比較少的表，增加索引不會帶來速度的優化反而浪費了存儲空間，因為索引是需要存儲空間的，而且有個致命缺點是對於update/insert/delete的每次執行，欄位的索引都必須重新計算更新。
那麼在什麼時候適合加上索引呢？我們看一個Mysql手冊中舉的例子，這里有一條sql語句：
SELECT
c.companyID,
c.companyName
FROM
Companies
c,
User
u
WHERE
c.companyID
=
u.fk_companyID
AND
c.numEmployees
>=
0
AND
c.companyName
LIKE
'%i%'
AND
u.groupID
IN
(SELECT
g.groupID
FROM
Groups
g
WHERE
g.groupLabel
=
'Executive')
這條語句涉及3個表的聯接，並且包括了許多搜索條件比如大小比較，Like匹配等。在沒有索引的情況下Mysql需要執行的掃描行數是77721876行。而我們通過在companyID和groupLabel兩個欄位上加上索引之後，掃描的行數只需要134行。在Mysql中可以通過Explain
Select來查看掃描次數。可以看出來在這種聯表和復雜搜索條件的情況下，索引帶來的性能提升遠比它所佔據的磁碟空間要重要得多。
那麼索引是如何實現的呢？大多數DB廠商實現索引都是基於一種數據結構——B樹。因為B樹的特點就是適合在磁碟等直接存儲設備上組織動態查找表。B樹的定義是這樣的：一棵m(m>=3)階的B樹是滿足下列條件的m叉樹：
1、每個結點包括如下作用域(j,
p0,
k1,
p1,
k2,
p2,
...
ki,
pi)
其中j是關鍵字個數，p是孩子指針
2、所有葉子結點在同一層上，層數等於樹高h
3、每個非根結點包含的關鍵字個數滿足[m/2-1]<=j<=m-1
4、若樹非空，則根至少有1個關鍵字，若根非葉子，則至少有2棵子樹，至多有m棵子樹
看一個B樹的例子，針對26個英文字母的B樹可以這樣構造：
可以看到在這棵B樹搜索英文字母復雜度只為o(m)，在數據量比較大的情況下，這樣的結構可以大大增加查詢速度。然而有另外一種數據結構查詢的虛度比B樹更快——散列表。Hash表的定義是這樣的：設所有可能出現的關鍵字集合為u，實際發生存儲的關鍵字記為k，而|k|比|u|小很多。散列方法是通過散列函數h將u映射到表T[0,m-1]的下標上，這樣u中的關鍵字為變數，以h為函數運算結果即為相應結點的存儲地址。從而達到可以在o(1)的時間內完成查找。
然而散列表有一個缺陷，那就是散列沖突，即兩個關鍵字通過散列函數計算出了相同的結果。設m和n分別表示散列表的長度和填滿的結點數，n/m為散列表的填裝因子，因子越大，表示散列沖突的機會越大。
因為有這樣的缺陷，所以資料庫不會使用散列表來做為索引的默認實現，Mysql宣稱會根據執行查詢格式嘗試將基於磁碟的B樹索引轉變為和合適的散列索引以追求進一步提高搜索速度。我想其它資料庫廠商也會有類似的策略，畢竟在資料庫戰場上，搜索速度和管理安全一樣是非常重要的競爭點。

㈤ 為了測試資料庫查詢的效率是否提升,經常使用索引來實現,請問什麼是索引 有什麼作用 原理是什麼

一、什麼是索引？

索引就像是書的目錄，是與表或者視圖關聯磁碟上的結構，可以加快從表中內或者視圖容中檢索行的速度。素銀中包含表或者視圖中的一行或者多列生成的鍵。這些鍵存儲在一個結構（BTree）中，使SQL可以快速有效的查找與鍵值關聯的行。

二、有什麼用？即索引的優點

1. 建立索引的行可以保證行的唯一性，生成唯一的word

2. 建立索引可以有效的縮短數據的檢索時間

3. 建立索引可以加快表與表之間的 連接

4. 為用來排序或者是分組的欄位添加索引可以加快和排序順序

• 無索引，直接去讀表數據存放的磁碟快，督導數據緩沖區中再去查找需要的數據

• 有索引，先讀入索引表，通過索引表直接去找到需要數據的物理地址，並把數據讀入數據緩沖區中。

三、索引的原理

通過不斷地縮小想要獲取數據的范圍來篩選出最終想要的結果，同時把隨機的事件變成順序的事件，也就是說，有了這種索引機制，我們可以總是用同一種查找方式來鎖定數據。

㈥ 資料庫中常見的「索引」是什麼意思有什麼用途

相當於書的目錄，提高查詢，更新，刪除的速率