資料來源是4000000萬條員工資料
1.一般方法
2.延遲關聯優化方法
優化思路:
3.利用上一次limit查詢主鍵值
select * from emp where empno >1000000 limit 20對比速度下來第一種方法速度最慢平均需要時間0.748，第二種次之平均耗時0.599，第三種0.125，對比下來第三種效能是最快的
如果員工資料表主鍵不是自增字段而是uuid之類的又會發生什麼變化.
比如現在有這麼乙個需求:
查詢 2017-11-19時間點之後入職的第100001~到100020的20條資料
一般方法
select * from emp where hiredate >'2017-11-19' limit 100000,20;select * from emp inner
join (select empno from emp where hiredate >'2017-11-19' limit 100000,20)as emmid using(empno);
由於hiredate不像主鍵一樣是唯一的，所以我們不能使用基於主鍵的第三種分頁方法
我發現第一種方法要比第二種方法執行的要快，快了接近0.05s,為了找出原因，我查詢了執行計畫
發現第一種查詢方法使用了一種mrr的執行計畫
我將該mrr計畫關閉後再次測試了1000次一般查詢方式
這一次一般方法比優化過後的方法慢了0.017s
當利用二級索引作為分頁條件時候並且使用mrr情況下，沒有必要使用延遲關聯進行優化
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...