「人家真的 不是目錄」
索引的原理
聚簇索引
索引存在的問題
常見的索引有:主鍵索引、唯一索引、普通索引和全文索引。
索引能夠在海量資料的查詢中大大加快檢索速率,提高系統效能。這個過程不用加記憶體、不用改程式、不用調sql,索引真是物美價廉!德才兼備!
建立主鍵索引:
建立唯一索引://直接加primery key即可自動生成索引
create table user1
(id int primery key,name varchar(10
));//乙個表中最多只能有乙個主鍵,不可為null,key值不能重複
建立普通索引://直接加unique即可自動生成索引
create table user1
(id int primery key,name varchar(10
) unique)
;//一張表中可以有多個unique索引
//不能重複
//如果在乙個unique上指定not null等價於主鍵索引
鑑於全文索引要求引擎必須是myisam,已退出歷史舞台,此處不表。alter table table_name add index
(column_name)
;//乙個表中可以有多個普通索引,可支援重複值
drop
index index_name on table_name;
mysql>
explain
select
*from articles where body like
'%database%'\g**
****
****
****
****
****
****
*1.row***
****
****
****
****
****
****
id: 1
select_type: ******
table: articles
type: all
possible_keys: null
key: null
-- null表示沒有用到索引,'%database'當然不會用到啦
key_len: null
ref: null
rows: 6
extra: using
where
1row
inset
(0.00 sec)
show
keys
from teble_name;
show
index
from table_name;
desc table_name;
b樹、b+和hash。mysql>
show
keys
from goods\g**
****
****
*1.row***
****
****
table: goods <= 表名
non_unique: 0
<=
0表示唯一索引
key_name: primary
<= 主鍵索引
seq_in_index: 1
column_name: goods_id <= 索引在哪列
collation: a
cardinality: 0
sub_part: null
packed: null
null:
index_type: btree
<= 以二叉樹形式的索引
comment:
1row
inset
(0.00 sec)
索引的資料結構型別和引擎相關,innodb預設的索引資料結構是b+樹。
雜湊索引(雜湊果然果然是我的本命資料結構,會遲到但絕不會缺席在任何為難我的地方)。其本質是雜湊雜湊,所以適合查詢單條記錄,在使用雜湊索引時,資料庫欄位中的資料轉換成定長的hash值,與這條資料的行指標一起存入雜湊表對應的位置,雜湊衝突由鏈位址法解決。
b樹和b+樹索引。
innodb只支援這兩種索引方式。我們先來看看這二者的定義和結構:
b樹的定義:b樹可以看作是對2-3查詢樹的一種擴充套件,是一種絕對平衡樹,這意味著根節點到葉子節點的長度是固定的,io的讀寫次數是可控的,這也是為什麼不用紅黑樹等其它資料結構的原因。
b樹要求:b樹的結構是(其實有page):每個節點最多 3 個子節點;
除了跟節點和葉節點,其他節點至少有2個子節點; 根節點如果不是葉節點,至少有2個子節點;
非葉節點中關鍵字數量n, 則 2 <= n <= 3;
b+樹:b+ 樹是 b 樹的一種變體,也是一種多路平衡查詢樹, 它和 b 樹主要不同點在:
每個節點最多含有 m 個關鍵字;所有的葉節點中包含了全部關鍵字資訊,以及指向還有這些關節字記錄的指標,且葉節點本身按照關鍵字順序相互連線;
所有非葉節點可以看成是索引部門,節點中僅包含其子樹中最大關鍵字。
換而言之,相較於b樹,b+樹是只在葉節點存放資料的,葉子節點之間使用鍊錶的形式串起來。這大大提高了遍歷的效率,節省了空間和io次數,尤其是在使用where進行範圍查詢的時候。
b+樹還有乙個很好的點,即在滿足聚簇索引時無需回表。
說起回表。。。。首先還是看什麼是聚簇索引吧。。。
聚簇索引將資料儲存與索引放在了一起,找到了索引也就找到了資料。顯然,innode使用的是聚簇索引,由mysql自動建立。myisam則是非聚簇索引,它將索引和資料分開放入兩個檔案。聚簇索引是自動建立的,如果有primary或者unique則會按其建立乙個主鍵/唯一聚簇索引,如果沒有,mysql也會自動生成乙個隱藏的聚簇索引,並按照聚簇索引排序。如果將普通列作為where查詢條件,將無法走索引而是走全表掃瞄,這是非常不合算的,由此,提出了輔助索引。
輔助索引是建立在聚簇索引的基礎上的,在查詢時,會把主鍵索引和輔助索引的列單獨拿出來,形成新錶,按照輔助列進行排序建立新的磁碟塊並以輔助索引的列名做索引。在查詢時,如果輔助索引中有要查的列,則取出資料,如果沒有,則返回主鍵索引搜尋,這個動作稱為回表。
使用多個字段同時建立乙個索引,如果想要查詢(命中)索引,需要按照建立索引時的字段挨個查詢。
天下沒有白吃的午餐,索引的查詢效率如此之高是以增刪改的效率為代價的,在資料庫中進行每一次的增刪改都會重新建立索引,因此,不必要的索引會大大降低資料庫的效能。
其次,對於海量資料的刪除應當先刪除索引,然後刪除無用的資料,再建立新的索引才是正道。(畢竟直接刪除萬一中斷,然後回滾。。。)
最後,瑕不掩瑜,索引依舊是提高資料庫查詢效率的首選。
樹 一種資料結構(二)
通過樹形結構的構造,進行組合設計模式 composite 的實現 node作為基類 本身不持有資料,用於維護共同的節點結構 class node protected node size t id,boost shared ptrp parent p id id 通過建構函式傳遞進來的父類指標建立與其...
Redis五種資料結構
redis除了儲存鍵之外還可以儲存常見的5種資料型別,分別是 string list set zset hash。結構型別 結構儲存的值 結構的讀寫能力 string字串 可以是字串 整數或浮點數 對整個字串或字串的一部分進行操作 對整數或浮點數進行自增或自減操作 list列表 乙個鍊錶,鍊錶上的每...
Redis五種資料結構
對redis來說,所有的key 鍵 都是字串,所謂的5種資料結構是指針對value而言 資料結構型別 說明使用場景 常用方法 其他鏈結 string字串型別1 redis中最基本的資料型別,乙個key對應乙個value。2 是二進位制安全的,意思是 redis 的 string 可以包含任何資料。如...