索引效能分析
sql優化
優化策略
慢查詢日誌
鎖機制b樹
對比項myisam
innnodb
主外來鍵不支援
支援事物
不支援支援
行表鎖表鎖，即使操作一條記錄
行鎖快取
只快取索引，不快取真實資料
索引與資料都會快取，堆記憶體要求較高，
且記憶體大小對效能有決定性的影響
表空間小
大關注點
效能事物
預設安裝yy
mysql官方對索引的定義為：索引(index)是幫助mysql高校獲取資料的資料結構。
可以得到索引的本質：索引是資料結構。
資料本身之外,資料庫還維護著乙個滿足特定查詢演算法的資料結構，這些資料結構以某種方式指向資料，
這樣就可以在這些資料結構的基礎上實現高階查詢演算法,這種資料結構就是索引。
我們平時所說的索引，如果沒有特別指明，都是指b樹(多路搜尋樹，並不一定是二叉樹)結構組織的索引。其中聚集索引，次要索引，覆蓋索引，復合索引，字首索引，唯一索引預設都是使用b+樹索引，統稱索引。當然,除了b+樹這種型別的索引之外，還有雜湊索引(hash index)等。
單值索引
唯一索引
復合索引
基本語法
覆蓋索引
全文索引
只有在myisam引擎上才能使用，而且只能在char,varchar,text型別欄位上使用全文索引。
聚集索引（myisam）
b+樹葉子節點只會儲存資料行（資料檔案）的指標，簡單來說資料和索引不在一起，就是非聚集索引
id：select查詢的序列號，包含一組數字，表示查詢中執行select子句或操作表的順序
包括三種情況
select_type：查詢的型別，主要用於區別普通查詢、聯合查詢、子查詢等的複雜查詢，包括六種
table：顯示這一行的資料是關於哪張表的
type：顯示查詢使用了何種型別，從最好到最差依次是：system>const>eq_ref>ref>range>index>all
possible_keys：顯示可能應用在這張表中的索引,乙個或多個。查詢涉及的字段上若存在索引，則該索引將被列出，但不一定被查詢實際使用
key：實際使用的索引。如果為null則沒有使用索引，查詢中若使用了覆蓋索引，則索引和查詢的select欄位重疊
key_len：表示索引中使用的位元組數，可通過該列計算查詢中使用的索引的長度。在不損失精確性的情況下，長度越短越好，key_len顯示的值為索引最大可能長度，並非實際使用長度，即key_len是根據表定義計算而得，不是通過表內檢索出的
ref：顯示索引那一列被使用了，如果可能的話，是乙個常數。那些列或常量被用於查詢索引列上的值
rows：根據表統計資訊及索引選用情況，大致估算出找到所需的記錄所需要讀取的行數
extra：包含不適合在其他列中顯示但十分重要的額外資訊
全值匹配我最愛
最佳左字首法則-如果索引了多例，要遵守最左字首法則。指的是查詢從索引的最左前列開始並且不跳過索引中的列。（例如復合索引中，第乙個索引欄位沒被使用，則後面的也不會被使用）
不在索引列上做任何操作（計算、函式、（自動or手動）型別轉換），會導致索引失效而轉向全表掃瞄
儲存引擎不能使用索引中範圍條件右邊的列
盡量使用覆蓋索引（只訪問索引列的查詢（索引列和查詢列一致）），減少select*
mysql在使用不等於（！=或者<>）的時候無法使用索引會導致全表掃瞄
is null,is not null 也無法使用索引
like以萬用字元開頭（』$abc…』）mysql索引失效會變成全表掃瞄操作
字串不加單引號索引失效
少用or,用它連線時會索引失效
單路排序
結論延申出的問題
2）嘗試提高 short_buffer_ size
不管用那種演算法，提高這個引數，都會提高效率，當然，要根據系統能力去提高，因為這個引數是針對每個程序。
3）嘗試 提高 max_length_for_short_data
提高這個引數，會增加使用改進演算法的概率。但是如果設定太高，資料總量超出 short_buffer_ size 的概率增大，明顯症狀高的io活動和低的處理器使用率。
檢視：
show variables like
'%slow_query_log%'
set
global slow_query_log =
1
show variables like
'long_query_time%'
;
set
global long_query_time=
3;
slow_query_log=1;
slow_query_log_file=/var/lib/mysql/slow.log
long_query_time=3;
log_output=file
偏向myisam儲存引擎，開銷小，加鎖快，無死鎖，鎖定粒度大，發生鎖衝突的概率最高，併發最低
加讀鎖：
lock
table
### read
lock
table
### write
總結：簡而言之就是讀鎖會阻塞寫，但不會阻塞讀；而寫鎖會把讀和寫阻塞。
特點偏向innodb儲存引擎，開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的概率最低，併發度也最高。innodb與myisam的最大不同有兩點：一是支援事務（transaction）;二是採用了行級鎖
事物的隔離級別
無索引行鎖公升級為表鎖
varchar 不用 』 』 導致系統自動轉換型別, 行鎖變表鎖
間隙鎖當我們使用範圍條件而不是相等條件檢索資料，並請求共享或排它鎖時，innodb會給符合條件的已有資料記錄的索引項加鎖；對於鍵值在條件範圍內但並不存在的記錄叫做「間隙」，innodb也會對這個「間隙」加鎖，這種鎖機制就叫間隙鎖。
危害：在執行過程中通過範圍查詢的話，他會鎖定整個範圍內所有的索引鍵值，即使這個鍵值不存在。
如何鎖定一行
使用 select ** for update；使用之後其他操作會被阻塞，直到鎖定的行會話提交 commit。
優化建議
組成部分：
btree索引(或balanced tree)，是一種很普遍的資料庫索引結構，。其特點是定位高效、利用率高、自我平衡，特別適用於高基數字段，定位單條或小範圍資料非常高效。理論上，使用btree在億條資料與100條資料中定位記錄的花銷相同。
若差找的資料是29，首先會將磁碟塊1載入到記憶體中，此時發生一次io，在記憶體中使用二分查詢定誒29在17和35之間，鎖定磁碟塊1的p2指標沒通過這個指標的磁碟位址將磁碟塊3載入到記憶體，發生第二次io，同樣根據二分查詢定位資料在磁碟塊3的p2指標，通過指標載入磁碟塊8到記憶體中，發生第三次io，同時使用而分查詢找到29，結束查詢，總計三次io。
b樹和b+樹的最大區別在於非葉子節點是否儲存資料的問題。
mysql 效能分析 Mysql效能分析
優化mysql資料庫效能的十個引數 1 max connections 允許的同時客戶的數量。增加該值增加 mysqld 要求的檔案描述符的數量。這個數字應該增加，否則，你將經常看到 too many connections 錯誤。預設數值是100，我把它改為1024 2 record buffer...
mysql高效能索引 mysql高效能索引（ ）
在開發中，我們知道大多數應用的瓶頸在於sql語句的執行時耗，在這裡並不討論sql語句的安全，僅僅討論高效能sql語句，而與高效能sql語句緊密相連的就是傳說中的 索引。索引 一種工作在儲存引擎端的用於快速找到記錄的一種資料結構。mysql使用索引的方式是 先找到索引的值，再根據索引的值找到資料行。索...
mysql效能分析與優化
hash索引的限制 hash索引必須進行二次查詢 hash索引無法用於排序 hash索引不支援部分索引查詢，也不支援範圍查詢 hash索引中hash碼的計算可能存在hash衝突 為什麼要使用索引 索引大大減少了儲存引擎需要掃瞄的資料量 索引可以幫助我們進行排序以避免使用臨時表 索引可以把隨機i o變...