mysql關於索引的一些零碎知識點

1、is null可以使用索引（網上很多文章存在誤導，這個確實可以使用索引），is not null無法使用索引。

2、為什麼重複資料較多的列不適合使用索引？

假如索引列type有5個鍵值，如果有1萬條資料，那麼 where type = 1將訪問表中的2000個資料塊。

再加上訪問索引塊，一共要訪問大於2000個的資料塊。

如果全表掃瞄，假設10條資料乙個資料塊，那麼只需訪問1000個資料塊，既然全表掃瞄訪問的資料塊少一些，肯定就不會利用索引了。

b樹索引具有範圍查詢和字首查詢的能力，對於有n節點的b樹，檢索一條記錄的複雜度為o(logn)。相當於二分查詢。

雜湊索引只能做等於查詢，但是無論多大的hash表，查詢複雜度都是o(1)。

顯然，如果值的差異性大，並且以等值查詢（=、 <、>、in）為主，hash索引是更高效的選擇，它有o(1)的查詢複雜度。

如果值的差異性相對較差，並且以範圍查詢為主，b樹是更好的選擇，它支援範圍查詢。

4、字段型別和傳入型別不一致會導致索引失效，例如name=9999,應該寫成name='9999'

5、雜湊索引只儲存雜湊值和行指標不儲存資料，因此無法使用雜湊索引來避免讀取行

6、雜湊索引不是按照索引值順序儲存的，所以無法用於排序。雜湊索引只支援等值比較（如：=,in(),<=>），不支援大於，小於等比較

7、在索引的分類中，我們可以按照索引的鍵是否為主鍵來分為「主索引」和「輔助索引」，使用主鍵鍵值建立的索引稱為「主索引」，其它的稱為「輔助索引」。因此主索引只能有乙個，輔助索引可以有很多個

8、使用mysql內部函式導致索引失效.對於這樣情況應當建立基於函式的索引. 

錯誤的例子：select * from test where round(id)=10; 

說明，此時id的索引已經不起作用了 正確的例子：首先建立函式索引， 

create index test_id_fbi_idx on test(round(id)); 

然後 select * from test where round(id)=10; 這時函式索引起作用了

not in和<>操作都不會使用索引將進行全表掃瞄。not in可以not exists代替，id<>3則可使用id>3 or id<3來代替。

11、復合索引中只要有一列含有null值，那麼這一列對於此復合索引就是無效的。所以我們在資料庫設計時不要讓字段的預設值為null。

12、 show session status like

'handler_read%

'; 可以檢視索引使用情況。詳情點選這裡

13、執行計畫explain中type表示mysql在表中找到所需行的方式，又稱「訪問型別」

all, index,  range, ref, eq_ref, const, system, null（從左到右，效能從最差到最好）

關於生活的一些零碎感悟

問自己幾個最本源也最無厘頭的問題 1 從 來？2 為什麼來？3 來幹嘛？4 能幹嘛？5 怎麼幹？然後以自己的理解嘗試回答下 1 來自父母，來自自然的更迭。2 父母的期望。3 因人而異。做 bill gates 賓拉登.很多人根本沒想過這個問題。4 有人能舉起地球，有人是穿山甲 對於那些有偉大理想的人...

關於git的一些零碎知識

git檔案的三個狀態 已修改，已暫存，已提交 git的三個區域 工作區，暫存區，物件庫 git的幾個指標 以master為例 遠端有個master，本地有個master，本地有個指標是指向遠端的master的叫origin master 唯讀分支 git add 與git add 的區別 都是提交所...

一些零碎的東西

可以說。國內幾大bsp提供的blog service都是一團糟！難道就不能有幾個好一點點的designer和好一點的template啊，css都定義得那麼糟糕！也許做程式的只會code結構，而不理會使用者感受，那麼，糟透了，竟然還有人津津樂道。我暈！改動了下，沒興致再改了。將就吧。也只有將就了。連c...