索引
什麼是索引
索引是一種數據結構, 爲了快速定位到數據而存在
爲什麼使用索引
1 索引可以減少IO次數
2 索引可以把隨機IO轉換爲順序IO
3 在分組和排序的時候避免使用臨時表
使用什麼算法
1 B+樹算法
爲什麼不使用二叉查找樹
首先說一下二叉查找樹的規則
1 左節點要小於根節點
2 右節點要大於根節點
缺點
二叉查找樹可能會把樹的結構轉換爲一個線性鏈表的結構
爲什麼不使用平衡二叉樹
規則
首先平衡二叉樹也是滿足左小於根,右大於根的規則
但是它的左右節點的高度差不能超過1
平衡二叉樹解決了二叉查找樹 線性鏈表的問題
平衡二叉樹存儲了什麼數據
1 關鍵字
2 數據區
3 子節點引用
缺點
數據存在的層數,決定了我們要進行多少次IO操作
並每個磁盤塊保存的數據量太小, 沒有充分利用好操作系統的磁盤存儲
爲什麼不使用B-樹(多路平衡查找樹)(balance)
規則
1 處根節點和葉子節點以外,其他的每個節點必須有m/2個孩子節點
2 所有葉子節點必須在同一層
3 符合平衡二叉樹的觀點, 左右節點高度差不會超過1
4 B樹裏面所有的節點都存儲了數據, 這樣的導致查詢數據的時候,導致性能會減低
5 使用的是索引順序IO,根據二分法查找數據
缺點: 在B樹的節點上存儲了數據, 減少了保存其他鍵值的空間,數的高度決定了我們要進行多少次IO操作.
爲什麼使用B+樹
B-樹解決了磁盤IO性能,但是並沒有解決元素遍歷效率低問題, 而B+樹只需要遍歷葉子節點就可以遍歷整顆樹
規則
1 左小右大
2 非葉子節點之存儲數據索引,所有數據必須要找找到葉子節點才能獲取,所以每次數據查詢次數都是一樣的
3 保存了父節點的所有鍵值和鍵值對應的數據,每個葉子節點的鍵值從小到大連接
MyISAM B+索引實現
1 葉子節點存儲了索引的值(myisam的主鍵和輔助主鍵沒有區別,所以他沒有主外鍵)
Innodb B+索引實現
myisam葉子節點存儲的數據地址, innodb葉子節點存儲的是數據,索引的key就是索引主鍵,
什麼叫做聚集索引
聚集索引的意思就是葉子節點存儲的是data,則表示這種索引就是聚集索引,
聚集索引,非聚集索引,覆蓋索引
聚集索引
給表建立一個主鍵, 表在磁盤上的整齊排列的順序轉換爲樹狀結構, 整個錶轉換爲了一個索引, 當整個表變成一個索引的時候那麼他就是聚集索引
鍵值的邏輯順序決定了表中對應行的物理順序(內容本身就是按照一定的規則排列的目標成爲聚集索引)
非聚集索引
表示非主鍵字段創建索引,如果跟表裏的多個字段創建索引,那麼會出現多個獨立的索引結構,每個非聚集索引互相之間不存在關聯
該索引中索引的邏輯順序與磁盤上行的物理存儲順序不同, 他的葉子節點存儲的是指針,而不是數據data
聚集索引和非聚集索引的區別: 聚集索引是有序排列,葉子節點存儲的是data, 非聚集索引是無序的存儲數據,也就是葉子節點存儲的是指針(可以用innodb和myisam中B+樹的存儲結構做對比)
覆蓋索引
表示沒有走的葉子節點就已經找到data
Mysql 查詢執行的路徑
客戶端和服務端建立連接
使用的是半雙工模式
當出現故障問題的時候使用show processlist進行查看鏈接狀態
查詢緩存
查詢優化器
解析器:把SQL解析成樹, 預處理:是否正確
執行引擎
mysiam innodb
返回給客戶端
優化
explain 解釋器包含內容
select_type: select簡單的查詢, primary 包含子查詢
type: system, const, eq_ref . ref.range, index , all
possible_keys: 查詢過程中可能用到的索引
key:用到的索引
rows:掃描的行數
索引失效原因 爲什麼?
沒有左查詢
在B+數中我們是按照左必右開的思想去查詢的,也就是從做邊開始查詢,所以在底層的查詢的時候首先根據第一個索引去找,但是如果你如果沒有使用第一個索引,那麼這個時候他就找不到了,所以全表掃描了
使用%立刻
如果使用模糊查詢,不明確,所以也會全表掃描
使用or
字符串沒有""號
mysql還需要幫你加"",她會認爲不使用索引可能會更快
使用 is null
mysql中不存儲null值,所以全表掃描
如何定位慢SQL
1 通過項目中的durid查看
2 打開mysql的慢日誌查看: set global show_query_log=on
3 使用explain解析SQL爲什麼慢
事物
事物特性
A
原子性: 不可分割
C
一致性:事物操作的數據以及狀態改變是一致的
I
隔離性:一個事物在操作數據提交之前,對其他事物是可見的.
D
持久化:存儲到磁盤上
隔離級別如何實現
通過MVCC和鎖實現的
什麼是MVCC
Multiversion concurrent control 多版本併發控制
每張表中存儲了2個字段, 數據行版本號,刪除版本號
有的時候我們會發現當我們更新數據之後,假如沒有commit,爲什麼還能查詢以前的數據呢 ,就是因爲mvcc的多版本控制,讓我們可以查詢上一個版本的內容
MVCC插入邏輯流程
當我們進行操作的時候,首先會拿到事物的id, 然後插入數據到表中,把事物id插入到數據行版本號中
MVCC刪除邏輯流程
拿去當前事物id,放入到刪除版本號裏面
MVCC更新
1 copy一行數據
2 在把當前到的事物id更新到數據行版本號上, 然後把上一個的刪除版本號更改當前的事物id
MVCC查詢邏輯流程
1 查詢拿着事物id,當前事物id小於查詢數據行的版本號
2 再拿着事物id查詢,事物id大於刪除版本號,或者刪除版本號爲null的
undo log 什麼
可以把數據返回到某一個狀態,因爲在數據操作之前會備份數據到undo log中
爲什麼 會有undo log
undo
undo log 有什麼功能
解決了mysql併發問題, 保證數據的一致性
MVCC與Undo Log關係
mvcc的方法是基於undo log
當前讀和快照讀
當前讀表示增刪改
快照讀表示普通select,從緩存中讀取
Redo log
減少每次事物的提交都需要進行IO操作, 所以讓事物提交的時候首先把數據方道平Redo log的緩衝區裏面,然後再更新磁盤
Mysql鎖
什麼是鎖
互相霸佔着彼此的資源不放手
表鎖和行鎖的區別
行鎖表示在where條件我們使用了索引,則產生的行鎖
如果Where條件沒有索引,那麼他會全表掃描,所以會出現表鎖
mysql鎖類型
共享鎖
S鎖: 加S鎖,可以讀取數據當時不可以更新數據,讀鎖,可以加讀鎖
排它鎖
X鎖:加X鎖, 排它鎖,表示什麼鎖都不可以加, 只允許他一個事物讀和寫
意向鎖共享IS
在加S鎖的時候,判斷是否有意向鎖共享,如果有則不加
意向鎖排他鎖IX
在加X鎖的時候,判斷是否有意向排它鎖,如果有則不加
臨鍵鎖(Next key)innodb默認行鎖算法
假如使用的是排它鎖,並且還使用where條件的進行範圍查詢,並且where條件後面使用了索引, 他會鎖住當前空間和下一個空間,也就是左開右必
爲什麼Innodb默認選擇臨鍵鎖
innodb默認採用的不可重複讀, 並且解決了幻讀的問題, 當B+樹命中這塊空間的時候,則不能再次進行插入,所以解決了幻讀問題.
什麼間隙鎖
只鎖住範圍之內的數據
什麼是記錄鎖
主鍵索引,鎖住一行數據,一般用的type爲eq_ref
鎖解決併發問題
X鎖解決髒讀問題
S鎖解決了重複讀問題
臨鍵鎖解決了幻讀問題,主要是記錄鎖和間隙的結合體
死鎖避免
1 同一個事物儘可能做到一次鎖定所有資源,減少死鎖概率
2 添加合理的索引,這樣可以快速
3 減少鎖的佔用時間
三範式
1 原子性,屬性不可以再分割
2 一張表裏只有一個主鍵
3 一個表裏面不可以存儲其他表中的字段