關於 .net exp 大於 發現 ges 主鍵 dump ref

數據庫優化目的

避免出現頁面訪問錯誤

1、由於數據庫鏈接timeout產生頁面5xxx錯我

2、由於慢查詢造成頁面無法加載

3、由於阻塞造成數據無法提交

如何發現有問題的sql

使用mysql慢查日誌對有效率問題的sql進行監控

show variables like ‘%slow%‘;

set global log_queries_not_using_indexes=on;

代表 記錄下沒有使用索引的sql 後面進行優化 ,記錄未使用索引的 打開

long_query_time 單位是秒 一般設置成100ms，也就是0.1秒

如果慢查日誌時間短，會有大量的日誌，磁盤空間可能會被沾滿 第一款MySQL官方的mysqldumpslow
分析慢查工具 安裝好mysql後自帶的工具，mysqldumpslow -t 3 慢查日誌路徑 | more 查看

但是結果信息不是很全面

所以用pt-query-digest

--limit=A 參數 -review expain 執行計劃 如掃描行數很多，發送到客戶端的很少，代表了索引不是很好

第一部分是頭顯示了基本信息，時間範圍 sql數量 第二部表統計信息 第三部分 sql信息

舉例說明 就是，這個sql 執行了一次，但是執行時間占用了百分之73百分比，這種sql重點關註，就是執行次數多，占用總時間的百分比大。數據庫主要瓶頸在io這，這個主要關註的是掃描行數，如果掃描的行數越多，說明他的io消耗也會越大。

第一個關註執行次數和執行時間占比，第二關註掃描行數examine，說明他的io消耗也會越大，第三 通過掃描行數 和發送行數，如果examine的掃描行數，遠遠大於send發送行數，說明sql索引命中率不高

找到慢的語句後如何進行優化

首先是用explaim這個從句，可以顯示出sql的執行計劃，原理數據庫中的sql，先對執行計劃分析，再對sql進行具體執行，那執行計劃側面的反應了sql的執行效率，

table 是這一行的數據是關於哪張表的 。

type這一列 const性能最好 性能最差就是ALL

const說明是個常數查找，一般是主鍵呢唯一索引進行查找，

eq-reg 是一種範圍的查找，一般呢是唯一索引呢主鍵的範圍查找，

ref 比較常見於連接的查詢中，一個表是基於某個索引的查找，

range是索引的範圍查找，

index是索引的掃描，

ALL是表掃描
沒有where條件所以沒有用到索引

key-len 索引的長度越短越好，因為mysql中的查詢化過程中，索引長度越小越好的，mysql每次讀取都是以頁為單位的，一頁中如果存儲的索引數量越大，它的查詢效率也就會越高。

rows 實際上就是表掃描的行數，

擴展列 一個是

filesort查詢結果用到文件排序方式來進行優化，文件排序呢主要是在orderby程序中比較常見，

temporary 這個呢用到了臨時表，無論filesort 或是temporpary都使用了外部文件或是臨時表進行數據的存儲，這種sql一般出現在order by group by 從句中，這樣的sql也是要重點關註的。以上是explain 從句使用方式還有返回的一些值，執行計劃

mysql數據庫優化之語句優化