索引優化策略
1.高性能索引策略
對於innodb而言,因為節點下有數據文件,因此節點的分裂將會比較慢.
對於innodb的主鍵,盡量用整型,而且是遞增的整型.如果是無規律的數據,將會產生的頁的分裂,影響速度.
2. 索引覆蓋
索引覆蓋是指 如果查詢的列恰好是索引的一部分,那麽查詢只需要在索引文件上進行,不需要回行到磁盤再找數據.
這種查詢速度非常快,稱為”索引覆蓋”
3. 理想的索引
1:查詢頻繁 2:區分度高 3:長度小 4: 盡量能覆蓋常用查詢字段.
索引長度直接影響索引文件的大小,影響增刪改的速度,並間接影響查詢速度(占用內存多).
針對列中的值,從左往右截取部分,來建索引
1: 截的越短, 重復度越高
2: 截的越長, 重復度越低,區分度越高, 索引效果越好,但帶來的影響也越大--增刪改變慢,並間影響查詢速度.
所以, 我們要在 區分度 + 長度 兩者上,取得一個平衡.
慣用手法: 截取不同長度,並測試其區分度,
select count(distinct left(word,6))/count(*) from dict;
對於一般的系統應用: 區別度能達到0.1,索引的性能就可以接受.
對於左前綴不易區分的列 ,建立索引的技巧
如 url列
http://www.baidu.com
http://www.zixue.it
列的前11個字符都是一樣的,不易區分
1: 把列內容倒過來存儲,並建立索引
Moc.udiab.www//:ptth
Ti.euxiz.www//://ptth
這樣左前綴區分度大,
2: 偽hash索引效果
同時存 url_hash列
3:多列索引
多列索引的考慮因素--- 列的查詢頻率 , 列的區分度
4.索引與排序
排序可能發生2種情況:
1: 對於覆蓋索引,直接在索引上查詢時,就是有順序的, using index
2: 先取出數據,形成臨時表做filesort(文件排序,但文件可能在磁盤上,也可能在內存中)
我們的爭取目標-----取出來的數據本身就是有序的! 利用索引來排序.
比如
where cat_id=N order by shop_price ,可以利用索引來排序,
select goods_id,cat_id,shop_price from goods order by shop_price;
// using where,按照shop_price索引取出的結果,本身就是有序的.
select goods_id,cat_id,shop_price from goods order by click_count;
// using filesort 用到了文件排序,即取出的結果再次排序
5. 重復索引與冗余索引
重復索引
是指 在同1個列(如age), 或者 順序相同的幾個列(age,school), 建立了多個索引,
稱為重復索引, 重復索引沒有任何幫助,只會增大索引文件,拖慢更新速度, 去掉.
冗余索引
冗余索引是指2個索引所覆蓋的列有重疊, 稱為冗余索引
比如 x,m,列 , 加索引 index x(x), index xm(x,m)
x,xm索引, 兩者的x列重疊了, 這種情況,稱為冗余索引.
甚至可以把 index mx(m,x) 索引也建立, mx, xm 也不是重復的,因為列的順序不一樣.
6. 索引碎片與維護
在長期的數據更改過程中, 索引文件和數據文件,都將產生空洞,形成碎片.
我們可以通過一個nop操作(不產生對數據實質影響的操作), 來修改表.
比如: 表的引擎為innodb
alter table 表名 engine innodb
optimize table 表名
註意: 修復表的數據及索引碎片,就會把所有的數據文件重新整理一遍,使之對齊.
這個過程,如果表的行數比較大,也是非常耗費資源的操作.
所以,不能頻繁的修復.
如果表的Update操作很頻率,可以按周/月,來修復.
如果不頻繁,可以更長的周期來做修復.
索引優化策略