好久沒有寫點東西了， 與其說是忙不如說是太懶。 先問個問題：[48,281,1,56,99,6]和[1,6,18,45,56,99,281]是兩個完全一樣的數組，前者是無規律可言的，后者是已經排好序的，要想把每個數組里邊大于100的數找出來或者排序 那一個更快一些？ 不用我說，地球人

好久沒有寫點東西了， 與其說是忙不如說是太懶。

先問個問題： [48,281,1,56,99,6] 和 [1,6,18,45,56,99,281] 是兩個完全一樣的數組，前者是無規律可言的，后者是已經排好序的，要想把每個數組里邊大于100的數找出來或者排序 那一個更快一些？ 不用我說，地球人除了傻子都知道是后者。索引就是數據表按照某一個字段或者幾個字段做出排序的數據結構。

因為已經存了這些字段的排列順序，我們就可以理解為這些數據是按照某些字段排好序的，這樣取數據的時候速度就會快樂好多倍， 當數據量較少的時候索引的優勢體現的并不明顯， 當數據量非常大的時候，你就會發現有沒有索引數據庫的性能會是天壤之別。

但是索引有幾個誤區：

1. 索引越多越好。

好多人都說這個是錯的，我看未必全錯！要根據實際情況來，如果你的數據庫是讀寫分開，在Master上寫數據，在Slave上讀數據， 完全可以單獨在Slave上多創建幾個索引 。

別的地方的解釋是索引會影響數據寫入的性能，還有索引多了會占用更多的硬盤空間。要想數據按照某一個或者多個字段有序地排列，系統會保存一個索引文件，多占一些硬盤空間是難免的， 另外插入記錄和修改記錄的時候要重新計算該記錄的排序位置，并更新索引文件， 所以讓insert和update 操作變慢也是肯定的。

這種想法基本上已經過時了，現在大多數的應用，尤其是數據量大到讓你不得不去看一些索引優化的時候，我個人覺得你的數據庫該考慮采用replication架構了，采用replication 架構的話一種提高性能非常主流又非常有效，那就是讀服務器和寫服務器分開。 Replication架構很好的一點就是， master 與 slave的結構可以不一樣，可以采用不同的存儲引擎，可以建不同的索引，他們是通過binlog來進行數據同步的， 但是主從數據庫不一致是有底線的， 你必須要保證你的程序生成的sql語句在master和slave上是都可以執行的而且效果一樣。 這樣的話插入在master上， 我們不建索引， 讀取在從服務器上我們可以多建一些索引，對數據庫的插入影響還是不大的。 另外現在還計較這些硬盤空間的人完全就是扯淡！！ 硬盤太便宜了，只要性能上的去， 流量上的去 還在乎這點空間嗎?

2. 索引建在要查詢的字段上

哥可以很負責任地告訴你， 這絕對是錯的！！ 我們可以分解查詢操作，沒有索引的時候，系統是這樣執行你的 select col1, col2 from table where col3=xxxx ：

系統先去查數據表table， 然后一條一條地計算 where 子句的東西 col3=xxx是否為true, 是true的話就取。索引的用途是不用再一條一條遍歷了,你要查詢的列已經基本有序， 采用二分法直接去查找就行了。效率節約到這里了， 跟你要查詢的列屁關系沒有。

當索引出現在 where 子句中有幾點要注意：

1. where sin(column) > 0.5 , 當索引列作為函數參數的時候， 系統不會采用索引， 解決的辦法就是換算一下，盡量不要索引列作為參數

2. where column like '%xxxx' ， 通配符出現在左邊的時候， 系統不會使用索引

（未完待續，待潤色）

聲明: 本文采用 CC BY-NC-SA 3.0 協議進行授權

轉載請注明來源：小景的博客

本文鏈接地址：http://www.phpv5.com/blog/archives/374/

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com