對於低效的查詢，我們發現通過以下兩個步驟分析很有效：
（1）確認應用程式是否在檢索大量超過需要的資料。這通常意味著訪問了太多的行，但有時候也可能是訪問了太多的行
（2）確認mysql伺服器層是否在分析大量超過需要的資料行
優化查詢的方法如下：
（1）是否向資料庫請求了不需要的資料
對於查詢資料是，可能應用程式會查詢了太多不需要的資料，這會造成兩方面的缺點
①會給mysql伺服器帶來額外的負擔，並增加網路開銷
②另外也會消耗應用伺服器的cpu
這裡有一些典型的案例：
①查詢不需要的記錄：mysql在查詢時，實際上會先返回全部的結果集然後再進行計算，並不是只返回需要的資料。這也就是說如果你先select大量的資料然後再擷取前幾條記錄的話，那麼就意味著會浪費效能。因為mysql實際上是先查詢出全部的結果集再拋棄大部分資料給你，並不是返回你要的那幾條資料。最簡單有效的就是加乙個limit進行限制
②多表關聯時返回全部列：
對於以上寫法應改成
③總是取出所有列：盡量不要使用select *的寫法。因為這會導致優化器無法完成索引覆蓋這類優化，還會為伺服器帶來額外的i/o，記憶體和cpu的消耗。當然查詢返回超過需要的資料並不總是壞事，比如當應用程式使用了某種快取機制，或者有其他考慮，獲取超過需要的資料葉可能是有其好處，打不要忘記這樣做的代價。獲取並快取所有的列的查詢，相比多個獨立的只獲取部分列的查詢可能就更有好處
（2）mysql是否在掃瞄額外的記錄
對於mysql最簡單的衡量查詢開銷的三個指標：①響應時間 ②掃瞄的行數 ③返回的行數。沒有那個指標能夠完美的衡量查詢的開銷，但他們可以大致的反應mysql在內部執行查詢時需要訪問多少資料，並可以大概推算出查詢執行的世界。這三個指標會被記錄在mysql的慢查詢中，所以查詢慢日誌記錄是找出掃瞄行數過多的查詢的好辦法
然而在不同型別的應用壓力下，響應時間並沒有一致的規律或者公式。諸如儲存引擎的鎖、高併發資源競爭、硬體響應等諸多因素都會影響響應時間。所以響應時間既可能是乙個問題的結果也可能是乙個問題的原因，不同案例情況不同。
所以當你看到乙個響應時間的時候，首先要問問自己這個響應時間是不是乙個合理的值
②掃瞄的行數和返回的行數：掃瞄的行數對於我們分析查詢時非常有幫助了，這在一定程度上能夠說明該查詢找出需要的資料的效率高不高。對於找出那些糟糕的查詢，這個指標可能還不夠完美，因為並不是所有的行的訪問代價都是相同的。較短的行的訪問速度更快，記憶體中的行也比磁碟中的行的訪問速度要快得多
理想情況下掃瞄的行數=返回到行數。但是現實很殘酷，一般沒有這種操作。
③掃瞄的行數和訪問型別：在評估查詢開銷的時候，需要考慮一下從表中找到某一行資料的成本。mysql有好幾種訪問方式可以查詢並返回一行結果。有些訪問方式可能需要掃瞄很多行才能返回一行，也有些訪問方式可能無需掃瞄就能返回結果。
在explain語句中的type列反映了訪問型別。訪問型別有很多種，從權標掃瞄到索引掃瞄、範圍掃瞄、唯一索引查詢、常數引用等。這裡列的這些，速度從慢到快，掃瞄的行數從小到大。
如果查詢沒有辦法找到合適的訪問型別，那麼解決的最好辦法通常就是增加乙個合適的索引（索引讓mysql以最高效、掃瞄函式最少的方式找到需要的記錄）
如果發現查詢需要掃瞄大量的資料但是只返回少數的行，那麼通常可以使用下面的技巧進行優化
①使用索引覆蓋掃瞄，把索引需要用的列都放到索引當中，這樣儲存引擎無需回表獲取對應行就可以返回結果 ②該錶庫表結果。例如使用單獨的彙總表 ③重寫這個複雜的查詢，讓mysql優化器能夠以更優化的方式執行這個查詢。
Mysql優化 慢查詢
先查詢是否開啟 開啟慢查詢日誌 set global slow query log 1 檢視引數設定 show variables like long query time 這裡查詢的是查過多少時間才會記錄成慢查詢 預設10 秒以上的s ql語句記錄到日誌中 修改引數 set global long...
Mysql慢查詢優化
二 優化這些慢查詢 3.細節優化 一般的應用系統，讀寫比例在10 1左右，而且插入操作和一般的更新操作很少出現效能問題，遇到最多的，也是最容易出問題的，還是一些複雜的查詢操作 修改配置檔案 在 my.ini 增加幾行 slow query log on log slow queries 儲存路徑 l...
Mysql 慢查詢優化
mysql 慢查詢的相關引數 使用show variables來查詢，set global來設定 slow query log 是否開啟慢查詢日誌，1表示開啟，0表示關閉。slow query log file mysql資料庫慢查詢日誌儲存路徑。可以不設定該引數，系統則會預設給乙個預設的檔案hos...