資料庫索引原理

如果沒有這樣的索引，innodb會隱式定義乙個主鍵來作為聚簇索引。

select * from
user
where age = ？ ;
select * from
user
where age = ? and
name = ?;

create
index idx_age_name on
user(age, name)

select age，name from user

where age=？

select
count(*) from
user

select id,name from

user

因為每當增刪資料時，b+樹都要進行調整，如果建立多個索引，多個b+樹都要進行調整，而樹越多、結構越龐大，這個調整越是耗時耗資源。如果減少了這些不必要的索引，磁碟的使用率可能會大大降低。

索引資料長度越小，每個塊中儲存的索參數量越多，一次io獲取的值更多。

where 條件中in和or可以使用索引， not in 和 <>操作無法使用索引；

如果是not

in或<>，面對b+樹，引擎根本不知道應該從哪個節點入手。

多用指定列查詢，只返回自己想到的資料列，少用select *；

不需要查詢無用字段，並且不使用*可能還會命中覆蓋索引哦；

最左匹配原則；

聯合索引中如果查詢中有某個列的範圍查詢，則其右邊的所有列都無法使用索

查詢優化器不一定會使用索引

在執行sql時，查詢優化器會判斷使用索引的效率問題，如果優化器認為使用索引還不如全表掃瞄高效，那麼就會棄用索引而使用全表掃瞄。

萬國碼，無需轉碼，無亂碼風險，曾經線上oracle曾經因為生僻字改字符集utf-8，煩的一筆。

解放資料庫cpu，將計算轉移到服務層，併發量大時這些功能很可能將資料庫拖死，業務邏輯放到服務層具備更好的擴充套件性，能夠輕易實現「增機器就加效能」。資料庫擅長儲存與索引，cpu計算還是上移吧

禁止使用外來鍵，如果有外來鍵完整性約束，需要應用程式控制

外來鍵會導致表與表之間耦合，update與delete操作都會涉及相關聯的表，十分影響sql 的效能，甚至會造成死鎖。高併發情況下容易造成資料庫效能

a）null的列使索引/索引統計/值比較都更加複雜，對mysql來說更難優化 b）null 這種型別mysql內部需要進行特殊處理，增加資料庫處理記錄的複雜性；同等條件下，表中有較多空字段的時候，資料庫的處理效能會降低很多 c）null值需要更多的儲存空，無論是表還是索引中每行中的null的列都需要額外的空間來標識 d）對null 的處理時候，只能採用is null或is notnull，而不能採用=、in、<、<>、!=、not

in這些操作符號。如：where name!=』shenjian』，如果存在name為null值的記錄，查詢結果就不會包含name為null值的記錄

會浪費更多的磁碟和記憶體空間，非必要的大量的大字段查詢會淘汰掉熱資料，導致記憶體命中率急劇降低，影響資料庫效能

a）增加新的enum值要做ddl操作

b）enum的內部實際儲存就是整數，你以為自己定義的是字串？

a）更新會變更b+樹，更新頻繁的字段建立索引會大大降低資料庫效能

b）「性別」這種區分度不大的屬性，建立索引是沒有什麼意義的，不能有效過濾資料，效能與全表掃瞄類似

能夠更加有效的過濾資料

讀取不需要的列會增加cpu、io消耗；不能有效的利用覆蓋索引

select uid from t_user where phone=13812345678 會導致全表掃瞄，而不能命中phone索引

select uid from t_user where from_unixtime(day)>='2017-02-15' 會導致全表掃瞄
正確的寫法是：select uid from t_user where
day>= unix_timestamp('2017-02-15 00:00:00')

a）負向查詢條件：not、!=、<>、!<、!>、not in、not like等，會導致全表掃瞄
b）%開頭的模糊查詢，會導致全表掃瞄

會產生臨時表，消耗較多記憶體與cpu，極大影響資料庫效能。這個視業務而定

舊版本mysql的or查詢是不能命中索引的，即使能命中索引，為何要讓資料庫耗費更多的cpu幫助實施查詢優化呢？

資料庫索引原理

資料庫資料庫索引原理

資料庫原理索引

資料庫索引原理

資料庫索引原理

資料庫 資料庫索引原理

資料庫原理 索引

資料庫索引原理

相關推薦

資料庫資料庫索引原理

資料庫原理索引