MYSQL取數(shù)據(jù)和發(fā)數(shù)據(jù)的流程（邊讀邊發(fā)）

• 1.服務(wù)端，獲取一行數(shù)據(jù)，存到net_buffer中，可以理解為結(jié)果集
• 2.繼續(xù)讀取數(shù)據(jù)，直到net_buffer寫滿，調(diào)用網(wǎng)絡(luò)接口發(fā)出去
• 3.如果發(fā)送成功，就清空net_buffer
• 4.如果發(fā)送失敗，就說明socket send buffer 寫滿了，進入等待，直到有足夠的空間可寫，再繼續(xù)發(fā)送。

注意net_buffer滿了就發(fā)給客戶端而不是等查詢語句查詢完所有數(shù)據(jù)才發(fā)，其中net_buffer默認(rèn)大小是16k,所以服務(wù)器占用內(nèi)存最多是16k，不會因為查詢200G的數(shù)據(jù)導(dǎo)致內(nèi)存爆掉。

如果客戶端接收數(shù)據(jù)太慢，就會導(dǎo)致數(shù)據(jù)在socket send buffer 堆積，導(dǎo)致發(fā)送數(shù)據(jù)到客戶端的線程進入等待，由于net_buffer數(shù)據(jù)沒有發(fā)送出去，net_buffer一直沒法清空，查詢語句就要等待net_buffer清空才能繼續(xù)執(zhí)行，導(dǎo)致服務(wù)端查詢速度變慢。

Sending to client

假設(shè)使用show processlist發(fā)現(xiàn)一條語句的state是“Sending to client”，就是上面說的在等待socket send buffer 有足夠空間可以將net_buffer中的數(shù)據(jù)寫進去發(fā)送給客戶端。

Sending Data

一個查詢語句的狀態(tài)是這樣的：

• 1.首先將語句狀態(tài)寫成Sending Data
• 2.將查詢需要的列信息發(fā)送給客戶端
• 3.繼續(xù)執(zhí)行查詢
• 4.完成查詢，將狀態(tài)寫成空

但是MYSQL8好像改了，我看到的是executing

LRU(Least Recently Used )算法

最近最少使用算法是一種內(nèi)存淘汰機制，核心是--內(nèi)存空間不足時，將最少使用的數(shù)據(jù)頁淘汰

innodb管理Buffer Pool 的LRU算法，是通過鏈表來實現(xiàn)的，每個鏈表節(jié)點就是一個數(shù)據(jù)頁。

• 1.鏈表中任意一個數(shù)據(jù)頁被訪問到時，就將這個節(jié)點放在鏈表的頭節(jié)點
• 2.當(dāng)訪問一個鏈表中沒有的數(shù)據(jù)頁，需要加載到BufferPool并且放在頭節(jié)點
• 3.當(dāng)新節(jié)點要進來時，如果鏈表空間不足了，就把鏈表尾節(jié)點從鏈表中刪除。

但是這個LRU在某些場景時有很大問題的

比如一個語句查詢了歷史數(shù)據(jù)表（非業(yè)務(wù)熱點數(shù)據(jù)表）的所有數(shù)據(jù)，這就會把鏈表中之前維護的熱點數(shù)據(jù)頁都淘汰掉，留下一些非業(yè)務(wù)熱點數(shù)據(jù)頁，會導(dǎo)致緩存命中率急劇降低，磁盤IO壓力倍增。

針對這種清空，Innodb對LRU算法進行了優(yōu)化

就是對鏈表進行了分區(qū)，前5/8是young區(qū)，后3/8是old區(qū)。

• 1.如果young的數(shù)據(jù)頁被訪問到了，和普通LRU算法一樣，移到鏈表頭部。
• 2.如果鏈表空間滿了，此時有個新的數(shù)據(jù)頁要加進來，和普通LRU算法一樣首先把鏈表尾部的數(shù)據(jù)頁淘汰，不過這個新的數(shù)據(jù)頁不是放在鏈表頭部，而是放在old區(qū)的第一個位置。
• 3.對于old區(qū)的數(shù)據(jù)頁，每次訪問都要進行判斷：

如果該數(shù)據(jù)頁在old待的時間大于1秒，就移動到整個鏈表的頭節(jié)點。

如果小于1秒，就不改變位置。

這個1秒是由innodb_old_blocks_time參數(shù)控制的。

這樣一來，短時間內(nèi)的非熱點數(shù)據(jù)只會存在于old區(qū)，一段時間內(nèi)不被訪問就慢慢掉到尾部被淘汰了，不會影響到真正的熱點數(shù)據(jù)，它們會一直在young區(qū)。保證了不影響正常業(yè)務(wù)。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論