本文不討論全文索引,出現類似需求直接換「elasticsearch」簡單了解b+樹,太難不多講,也講不明白
關於b+樹的文章
介面上生產,效能不達標有很多因素導致,最容易被當嫌疑犯的就是資料庫。因為用法不過關,導致了資料庫背鍋。甚至有同學了為了讓介面達標,還沒沒怎麼優化資料庫就過早的開始加入redis,memcache等快取。
值得慶幸的是儘管開源,mysql還是優秀到它姥姥家的一款資料庫。
先從理論上手。
單列索引
組合索引
索引順序與物理順序相同,意味著這個索引效率最高
索引b+樹葉子結點儲存了物理行。意味著找到主鍵,就找到了行記錄
每個葉子結點都可以找到相鄰的葉子。思考下:cursor.next在底層的實現
一張表只能有乙個主鍵
a. 如果表定義了pk,則pk就是聚集索引;
b. 如果表沒有定義pk,則第乙個not null unique列是聚集索引;
c. 沒有定義以上,innodb會建立乙個隱藏的row-id作為聚集索引;
普通索引也叫二級索引,為什麼叫二級索引???這個要特別注意!
普通索引也是b+樹
與主鍵索引的主要區別在於葉子結點只包含了主鍵值,還有乙個標籤,用來告訴儲存引擎在**可以找到這行資料。
普通索引被命中後,需要回表,用主鍵id去獲取行資料
因為有回表的動作,所以才叫,二級索引
綜述:普通索引不能與主鍵的效能相提並論!
聯合幾個字段一起索引
建立組合索引示例
alter
table
user
addindex login_index (
user
,password)
b+樹體現:葉子結點儲存的是第乙個字段!在葉子結點額外儲存了其它字段!也即是說,
select
user
, password, nickname from
user
where
user
='somkelee'
這種用法會造成回表,去查詢nickname,雖然不影響索引效果,但會「回表」。
select
user
, password,
session
from
user
where
session
='***xx'
anduser
='***x'
這種情況下,索引不生效!
正確用法
select
user
,password from
user
where
user
='smokelee'
後面加上 and password=
'***' 也生效
總結:聯合索引,務必讓第乙個字段位於where子句的第乙個,索引才會生效!select子句字段不能包含聯合索引之外的字段,否則會引發「回表」
讓SQL飛起來
讓sql飛起來 人們在使用sql時往往會陷入乙個誤區,即太關注於所得的結果是否正確,而忽略了不同的實現方法之間可能存在的效能差異,這種效能差異在大型的或是複雜的資料庫環境中 如聯機事務處理oltp或決策支援系統dss 中表現得尤為明顯。筆者在工作實踐中發現,不良的sql往往來自於不恰當的索引設計 不...
讓你的程式飛起來
本方法可以讓c語言指令進一步接近彙編指令的執行效率,提高微控制器 嵌入式系統的速度和穩定性,但程式設計時應採取函式化的程式設計法 例如使用swap 函式時,必要時加注釋。0.位運算心法 1.如果乘上乙個2的倍數數值,可以改用左移運算 left shift 加速 300 x x 2 x x 64 改為...
與時俱進,讓思維飛起來
聽說過這樣一句話 好的idea會比eclipse好用。說得很是貼切,盲目的揮手敲打 開發應用毫無疑問是做的無用功。其實乙個好的idea並不是一觸即發,也是需要做足夠的功課,蒐集相關資料,分析目前市場的形式 使用者的需求 使用者習慣 消費水平等等。現在的我正處於乙個資料蒐集的狀態,也給大家分享分享蒐集...