206_mysql_innodb_5_innodb_Buffer Pool2

一 Buffer Pool內(nèi)部組成

Buffer Pool中默認(rèn)的緩存頁大小和在磁盤上默認(rèn)的頁大小是一樣的，都是16KB。為了更好的管理這些在Buffer Pool中的緩存頁，InnoDB為每一個(gè)緩存頁都創(chuàng)建了一些所謂的控制信息，

控制信息包括該頁所屬的表空間編號(hào)、頁號(hào)、緩存頁在Buffer Pool中的地址、鏈表節(jié)點(diǎn)信息、一些鎖信息以及LSN信息

控制信息占用的內(nèi)存大小是相同的，控制信息占用的一塊內(nèi)存稱為一個(gè)控制塊，

控制塊和緩存頁是一一對(duì)應(yīng)的，它們都被存放到 Buffer Pool 中，其中控制塊被存放到Buffer Pool的前邊，緩存頁被存放到Buffer Pool后邊

備注：

1 碎片 分配時(shí)候剩余空間不夠一個(gè)控制塊和緩存頁的大小

2 申請(qǐng)的內(nèi)存比innodb_buffer_pool_size的值大5%左右

控制塊大約占用緩存頁大小的5%，在Mysql5.7.21這個(gè)版本中，每個(gè)控制塊占用的大小是808字節(jié)。

innodb_buffer_pool_size并不包含這部分控制塊占用的內(nèi)存空間大小，也就是說InnoDB在為Buffer Pool向操作系統(tǒng)申請(qǐng)連續(xù)的內(nèi)存空間時(shí)

二 free鏈表的管理

Pool中哪些緩存頁是可用的，我們可以把所有空閑的緩存頁對(duì)應(yīng)的控制塊作為一個(gè)節(jié)點(diǎn)放到一個(gè)鏈表中，這個(gè)鏈表也可以被稱作free鏈表（或者說空閑鏈表）。

初始化的Buffer Pool中所有的緩存頁都是空閑的每一個(gè)緩存頁對(duì)應(yīng)的控制塊都會(huì)被加入到free鏈表中

為了管理好這個(gè)free鏈表，特意為這個(gè)鏈表定義了一個(gè)基節(jié)點(diǎn)，包含著鏈表的頭節(jié)點(diǎn)地址，尾節(jié)點(diǎn)地址，以及當(dāng)前鏈表中節(jié)點(diǎn)的數(shù)量等信息。

鏈表的基節(jié)點(diǎn)占用的內(nèi)存空間并不包含在為Buffer Pool申請(qǐng)的一大片連續(xù)內(nèi)存空間之內(nèi)，而是單獨(dú)申請(qǐng)的一塊內(nèi)存空間

三 緩存頁的哈希處理

當(dāng)我們需要訪問某個(gè)頁中的數(shù)據(jù)時(shí)，就會(huì)把該頁從磁盤加載到Buffer Pool中，

如果該頁已經(jīng)在Buffer Pool中的話直接使用就可以了。那么問題也就來了，我們?cè)趺粗涝擁撛诓辉贐uffer Pool中呢？我們其實(shí)是根據(jù)表空間號(hào) + 頁號(hào)來定位一個(gè)頁的，

key:表空間號(hào)+頁號(hào)

value: 控制塊的值

四 flush鏈表的管理

修改了Buffer Pool中某個(gè)緩存頁的數(shù)據(jù)，那它就和磁盤上的頁不一致了，這樣的緩存頁也被稱為臟頁（英文名：dirty page）。

如果不立即同步到磁盤的話，那之后再同步的時(shí)候我們?cè)趺粗繠uffer Pool中哪些頁是臟頁，哪些頁從來沒被修改過呢？

創(chuàng)建一個(gè)存儲(chǔ)臟頁的鏈表，凡是修改過的緩存頁對(duì)應(yīng)的控制塊都會(huì)作為一個(gè)節(jié)點(diǎn)加入到一個(gè)鏈表中，所以也叫flush鏈表。

假設(shè)某個(gè)時(shí)間點(diǎn)Buffer Pool中的臟頁數(shù)量為n，那么對(duì)應(yīng)的flush鏈表就長(zhǎng)這樣：

五 LRU鏈表

5.1 背景

Buffer Pool大小有限（free鏈表有限） 涉及初衷是減少IO，提高緩存命中率 ，當(dāng)Buffer Pool中不再有空閑的緩存頁時(shí)，就需要淘汰掉部分最近很少使用的緩存頁

這個(gè)鏈表是為了按照最近最少使用的原則去淘汰緩存頁的，所以這個(gè)鏈表可以被稱為L(zhǎng)RU鏈表（LRU的英文全稱：Least Recently Used）

如果該頁不在Buffer Pool中，在把該頁從磁盤加載到Buffer Pool中的緩存頁時(shí)，就把該緩存頁對(duì)應(yīng)的控制塊作為節(jié)點(diǎn)塞到鏈表的頭部。

如果該頁已經(jīng)緩存在Buffer Pool中，則直接把該頁對(duì)應(yīng)的控制塊移動(dòng)到LRU鏈表的頭部。

LRU鏈表尾部就是最近最少使用的緩存頁 當(dāng)Buffer Pool中的空閑緩存頁使用完時(shí)，淘汰LRU鏈表的尾部找些緩存頁

5.2 問題

情況一：Buffer Pool中的頁不一定被用到

InnoDB提供了預(yù)讀服務(wù)（read ahead）InnoDB認(rèn)為執(zhí)行當(dāng)前的請(qǐng)求可能之后會(huì)讀取某些頁面，就預(yù)先把它們加載到Buffer Pool中。

預(yù)讀又可以細(xì)分為下邊兩種： 1 線性預(yù)讀 系統(tǒng)變量innodb_read_ahead_threshold，如果順序訪問了某個(gè)區(qū)（extent）的頁面超過這個(gè)系統(tǒng)變量的值，就會(huì)觸發(fā)一次異步讀取下一個(gè)區(qū)中全部的頁面到Buffer Pool的請(qǐng)求， innodb_read_ahead_threshold系統(tǒng)變量的值默認(rèn)是56是一個(gè)全局變量（SET GLOBAL命令來修改） 2 隨機(jī)預(yù)讀 如果Buffer Pool中已經(jīng)緩存了某個(gè)區(qū)的13個(gè)連續(xù)的頁面，不論這些頁面是不是順序讀取的，都會(huì)觸發(fā)一次異步讀取本區(qū)中所有其的頁面到Buffer Pool的請(qǐng)求。 innodb_random_read_ahead系統(tǒng)變量，它的默認(rèn)值為OFF

情況一總結(jié)

預(yù)讀本來是個(gè)好事兒，如果預(yù)讀到Buffer Pool中的頁成功的被使用到，那就可以極大的提高語句執(zhí)行的效率。

用不到呢？這些預(yù)讀的頁都會(huì)放到LRU鏈表的頭部，會(huì)導(dǎo)致處在LRU鏈表尾部的一些緩存頁會(huì)很快的被淘汰掉，會(huì)大大降低緩存命中率

情況二：非常多的使用頻率偏低的頁被同時(shí)加載到Buffer Pool

一些需要掃描全表的查詢語句（select * from xxx ）

意味著將訪問到該表所在的所有頁都加載到Buffer Pool中而這種全表掃描的語句執(zhí)行的頻率也不高，每次執(zhí)行都要把Buffer Pool中的緩存頁換一次血，降低了緩存命中率

5.3 解決方案

InnoDB把這個(gè)LRU鏈表按照一定比例分成兩截

young區(qū)域 一部分存儲(chǔ)使用頻率非常高的緩存頁，所以這一部分鏈表也叫做熱數(shù)據(jù)

old區(qū)域 另一部分存儲(chǔ)使用頻率不是很高的緩存頁，所以這一部分鏈表也叫做冷數(shù)據(jù)

innodb按照某個(gè)比例將LRU鏈表分成兩半的，不是某些節(jié)點(diǎn)固定是young區(qū)域的，某些節(jié)點(diǎn)固定是old區(qū)域的，隨著程序的運(yùn)行，某個(gè)節(jié)點(diǎn)所屬的區(qū)域也可能發(fā)生變化。

通過查看系統(tǒng)變量innodb_old_blocks_pct的值來確定old區(qū)域在LRU鏈表中所占的比例

可以在啟動(dòng)時(shí)修改innodb_old_blocks_pct參數(shù)來控制old區(qū)域在LRU鏈表中所占的比例

old區(qū)域在LRU鏈表中所占的比例是37%，也就是說old區(qū)域大約占LRU鏈表的3/8。

show variables like "%innodb_old_blocks_pct"

優(yōu)化情況1 預(yù)讀的頁面可能不進(jìn)行后續(xù)訪情況的優(yōu)化

當(dāng)磁盤上的某個(gè)頁面在初次加載到Buffer Pool中的某個(gè)緩存頁時(shí)，該緩存頁對(duì)應(yīng)的控制塊會(huì)被放到old區(qū)域的頭部。

這樣針對(duì)預(yù)讀到Buffer Pool卻不進(jìn)行后續(xù)訪問的頁面就會(huì)被逐漸從old區(qū)域逐出，而不會(huì)影響young區(qū)域中被使用比較頻繁的緩存頁。

優(yōu)化情況2針對(duì)全表掃描時(shí)，短時(shí)間內(nèi)訪問大量使用頻率非常低的頁面情況的優(yōu)化

全表掃描有一個(gè)特點(diǎn)，那就是它的執(zhí)行頻率非常低,在對(duì)某個(gè)處在old區(qū)域的緩存頁進(jìn)行第一次訪問時(shí)就在它對(duì)應(yīng)的控制塊中記錄下來這個(gè)訪問時(shí)間，

如果后續(xù)的訪問時(shí)間與第一次訪問的時(shí)間在某個(gè)時(shí)間間隔內(nèi)，那么該頁面就不會(huì)被從old區(qū)域移動(dòng)到y(tǒng)oung區(qū)域的頭部，否則將它移動(dòng)到y(tǒng)oung區(qū)域的頭部。

間隔時(shí)間是由系統(tǒng)變量innodb_old_blocks_time控制 show variables like "%innodb_old_blocks_time" ??# 單位是ms

更進(jìn)一步優(yōu)化LRU鏈表

對(duì)于young區(qū)域的緩存頁來說，每次訪問一個(gè)緩存頁就要把它移動(dòng)到LRU鏈表的頭部(開銷是太大)，畢竟在young區(qū)域的緩存頁都是熱點(diǎn)數(shù)據(jù)，為了避免頻繁變革鏈表頭部信息

比如只有被訪問的緩存頁位于young區(qū)域的1/4的后邊，才會(huì)被移動(dòng)到LRU鏈表頭部，這樣可以降低調(diào)整LRU鏈表的頻率，從而提升性能（也就是說如果某個(gè)緩存頁對(duì)應(yīng)的節(jié)點(diǎn)在young區(qū)域的1/4中，再次訪問該緩存頁時(shí)也不會(huì)將其移動(dòng)到LRU鏈表頭部）

5.4 刷新臟頁到磁盤

后臺(tái)有專門的線程每隔一段時(shí)間負(fù)責(zé)把臟頁刷新到磁盤，這樣可以不影響用戶線程處理正常的請(qǐng)求。

主要有兩種刷新路徑：

5.4.1 BUF_FLUSH_LRU

從LRU鏈表的冷數(shù)據(jù)中刷新一部分頁面到磁盤

后臺(tái)線程會(huì)定時(shí)從LRU鏈表尾部開始掃描一些頁面，掃描的頁面數(shù)量可以通過系統(tǒng)變量innodb_lru_scan_depth來指定，如果從里邊兒發(fā)現(xiàn)臟頁，會(huì)把它們刷新到磁盤

show variables like "%innodb_lru_scan_depth

5.4.2 BUF_FLUSH_LIST

從flush鏈表中刷新一部分頁面到磁盤，后臺(tái)線程也會(huì)定時(shí)從flush鏈表中刷新一部分頁面到磁盤，刷新的速率取決于當(dāng)時(shí)系統(tǒng)是不是很繁忙

5.4.3 BUF_FLUSH_SINGLE_PAGE

后臺(tái)線程刷新臟頁的進(jìn)度比較慢，導(dǎo)致用戶線程在準(zhǔn)備加載一個(gè)磁盤頁到Buffer Pool時(shí)沒有可用的緩存頁，

這時(shí)就會(huì)嘗試看看LRU鏈表尾部有沒有可以直接釋放掉的未修改頁面，如果沒有的話會(huì)不得不將LRU鏈表尾部的一個(gè)臟頁同步刷新到磁盤

5.4.4 用戶用戶線程批量的從flush鏈表中刷新臟頁

有時(shí)候系統(tǒng)特別繁忙時(shí)，也可能出現(xiàn)用戶線程批量的從flush鏈表中刷新臟頁的情況，很顯然在處理用戶請(qǐng)求過程中去刷新臟頁是一種嚴(yán)重降低處理速度的行為

六 多個(gè)Buffer Pool實(shí)例

在多線程環(huán)境下，訪問Buffer Pool中的各種鏈表都需要加鎖處理 大并發(fā)下單一的Buffer Pool可能會(huì)影響請(qǐng)求的處理速度。

所以在Buffer Pool特別大的時(shí)候，可以把它們拆分成若干個(gè)小的Buffer Pool，每個(gè)Buffer Pool都稱為一個(gè)實(shí)例，獨(dú)立的去申請(qǐng)內(nèi)存空間，獨(dú)立的管理各種鏈表

我們可以在服務(wù)器啟動(dòng)的時(shí)候通過設(shè)置innodb_buffer_pool_instances的值來修改Buffer Pool實(shí)例的個(gè)數(shù)

[server] innodb_buffer_pool_instances =2 innodb_buffer_pool_size的值小于1G的時(shí)候設(shè)置多個(gè)實(shí)例是無效的 單個(gè)buffer pool size = innodb_buffer_pool_size / innodb_buffer_pool_instances

6.1 ?innodb_buffer_pool_chunk_size

在Mysql 5.7.5之前，Buffer Pool的大小只能在服務(wù)器啟動(dòng)時(shí)通過配置innodb_buffer_pool_size啟動(dòng)參數(shù)來調(diào)整大小，在服務(wù)器運(yùn)行過程中是不允許調(diào)整該值的。

設(shè)計(jì)MySQL的在5.7.5以及之后的版本中支持了在服務(wù)器運(yùn)行過程中調(diào)整Buffer Pool大小的功能，

每次當(dāng)我們要重新調(diào)整Buffer Pool大小時(shí)，都需要重新向操作系統(tǒng)申請(qǐng)一塊連續(xù)的內(nèi)存空間，然后將舊的Buffer Pool中的內(nèi)容復(fù)制到這一塊新空間，這是極其耗時(shí)的

所以MySQL決定不再一次性為某個(gè)Buffer Pool實(shí)例向操作系統(tǒng)申請(qǐng)一大片連續(xù)的內(nèi)存空間，而是以一個(gè)所謂的chunk為單位向操作系統(tǒng)申請(qǐng)空間。

也就是說一個(gè)Buffer Pool實(shí)例其實(shí)是由若干個(gè)chunk組成的，一個(gè)chunk就代表一片連續(xù)的內(nèi)存空間，里邊兒包含了若干緩存頁與其對(duì)應(yīng)的控制塊

上圖代表的Buffer Pool就是由2個(gè)實(shí)例組成的，每個(gè)實(shí)例中又包含2個(gè)chunk。

我們?cè)诜?wù)器運(yùn)行期間調(diào)整Buffer Pool的大小時(shí)就是以chunk為單位增加或者刪除內(nèi)存空間，而不需要重新向操作系統(tǒng)申請(qǐng)一片大的內(nèi)存，然后進(jìn)行緩存頁的復(fù)制。

chunk的大小是我們?cè)趩?dòng)操作MySQL服務(wù)器時(shí)通過innodb_buffer_pool_chunk_size啟動(dòng)參數(shù)指定的，它的默認(rèn)值是134217728，也就是128M。

innodb_buffer_pool_chunk_size的值只能在服務(wù)器啟動(dòng)時(shí)指定，在服務(wù)器運(yùn)行過程中是不可以修改的

innodb_buffer_pool_chunk_size的值并不包含緩存頁對(duì)應(yīng)的控制塊的內(nèi)存空間大小，每個(gè)chunk的大小要比innodb_buffer_pool_chunk_size的值大一些，約5%

show variables like "%innodb_buffer_pool_chunk_size"

七 配置Buffer Pool時(shí)的注意事項(xiàng)

innodb_buffer_pool_size必須是innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances的倍數(shù)（這主要是想保證每一個(gè)Buffer Pool實(shí)例中包含的chunk數(shù)量相同）

innodb_buffer_pool_chunk_size的值是128M，innodb_buffer_pool_instances的值是16，兩個(gè)值的乘積就是2G，innodb_buffer_pool_size的值必須是2G或者2G的整數(shù)倍

如果不是相關(guān)倍數(shù) 會(huì)被調(diào)整到相關(guān)倍數(shù)（會(huì)比設(shè)置的值稍微大一些）

如果在服務(wù)器啟動(dòng)時(shí)，innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances的值已經(jīng)大于innodb_buffer_pool_size的值，

那么innodb_buffer_pool_chunk_size的值會(huì)被服務(wù)器自動(dòng)設(shè)置為innodb_buffer_pool_size/innodb_buffer_pool_instances的值

Buffer Pool中存儲(chǔ)的其它信息

Buffer Pool的緩存頁除了用來緩存磁盤上的頁面以外，還可以存儲(chǔ)鎖信息、自適應(yīng)哈希索引等信息

查看Buffer Pool的狀態(tài)信息

SHOW ENGINE INNODB STATUS語句來查看關(guān)于InnoDB存儲(chǔ)引擎運(yùn)行過程中的一些狀態(tài)信息，其中就包括Buffer Pool的一些信息

Total memory allocated：代表Buffer Pool向操作系統(tǒng)申請(qǐng)的連續(xù)內(nèi)存空間大小，包括全部控制塊、緩存頁、以及碎片的大小 Dictionary memory allocated：為數(shù)據(jù)字典信息分配的內(nèi)存空間大小，注意這個(gè)內(nèi)存空間和Buffer Pool沒啥關(guān)系，不包括在Total memory allocated中 Buffer pool size：代表該Buffer Pool可以容納多少緩存頁，注意，單位是頁 Free buffers：代表當(dāng)前Buffer Pool還有多少空閑緩存頁，也就是free鏈表中還有多少個(gè)節(jié)點(diǎn) Database pages：代表LRU鏈表中的頁的數(shù)量，包含young和old兩個(gè)區(qū)域的節(jié)點(diǎn)數(shù)量 Old database pages：代表LRU鏈表old區(qū)域的節(jié)點(diǎn)數(shù)量 Modified db pages：代表臟頁數(shù)量，也就是flush鏈表中節(jié)點(diǎn)的數(shù)量 Pending reads：正在等待從磁盤上加載到Buffer Pool中的頁面數(shù)量當(dāng)準(zhǔn)備從磁盤中加載某個(gè)頁面時(shí)，會(huì)先為這個(gè)頁面在Buffer Pool中分配一個(gè)緩存頁以及它對(duì)應(yīng)的控制塊，然后把這個(gè)控制塊添加到LRU的old區(qū)域的頭部，但是這個(gè)時(shí)候真正的磁盤頁并沒有被加載進(jìn)來，Pending reads的值會(huì)跟著加1 Pending writes LRU：即將從LRU鏈表中刷新到磁盤中的頁面數(shù)量。 Pending writes flush list：即將從flush鏈表中刷新到磁盤中的頁面數(shù)量。 Pending writes single page：即將以單個(gè)頁面的形式刷新到磁盤中的頁面數(shù)量。 Pages made young：代表LRU鏈表中曾經(jīng)從old區(qū)域移動(dòng)到y(tǒng)oung區(qū)域頭部的節(jié)點(diǎn)數(shù)量。 一個(gè)節(jié)點(diǎn)每次只有從old區(qū)域移動(dòng)到y(tǒng)oung區(qū)域頭部時(shí)才會(huì)將Pages made young的值加1， 如果該節(jié)點(diǎn)本來就在young區(qū)域，由于它符合在young區(qū)域1/4后邊的要求，下一次訪問這個(gè)頁面時(shí)也會(huì)將它移動(dòng)到y(tǒng)oung區(qū)域頭部，并不會(huì)導(dǎo)致Pages made young的值加1 Page made not young： 在將innodb_old_blocks_time設(shè)置的值大于0時(shí)，首次訪問或者后續(xù)訪問某個(gè)處在old區(qū)域的節(jié)點(diǎn)時(shí)由于不符合時(shí)間間隔的限制而不能將其移動(dòng)到y(tǒng)oung區(qū)域頭部時(shí)，Page made not young的值會(huì)加1 對(duì)于處在young區(qū)域的節(jié)點(diǎn)，如果由于它在young區(qū)域的1/4處而導(dǎo)致它沒有被移動(dòng)到y(tǒng)oung區(qū)域頭部，這樣的訪問并不會(huì)將Page made not young的值加1。 youngs/s：代表每秒從old區(qū)域被移動(dòng)到y(tǒng)oung區(qū)域頭部的節(jié)點(diǎn)數(shù)量。 non-youngs/s：代表每秒由于不滿足時(shí)間限制而不能從old區(qū)域移動(dòng)到y(tǒng)oung區(qū)域頭部的節(jié)點(diǎn)數(shù)量。 Pages read、created、written：代表讀取，創(chuàng)建，寫入了多少頁。后邊跟著讀取、創(chuàng)建、寫入的速率。 Buffer pool hit rate：表示在過去某段時(shí)間，平均訪問1000次頁面，有多少次該頁面已經(jīng)被緩存到Buffer Pool了。 young-making rate：表示在過去某段時(shí)間，平均訪問1000次頁面，有多少次訪問使頁面移動(dòng)到y(tǒng)oung區(qū)域的頭部了。 這里統(tǒng)計(jì)的將頁面移動(dòng)到y(tǒng)oung區(qū)域的頭部次數(shù)不僅僅包含從old區(qū)域移動(dòng)到y(tǒng)oung區(qū)域頭部的次數(shù)，還包括從young區(qū)域移動(dòng)到y(tǒng)oung區(qū)域頭部的次數(shù)（訪問某個(gè)young區(qū)域的節(jié)點(diǎn)，只要該節(jié)點(diǎn)在young區(qū)域的1/4處往后，就會(huì)把它移動(dòng)到y(tǒng)oung區(qū)域的頭部）。 not (young-making rate)：表示在過去某段時(shí)間，平均訪問1000次頁面，有多少次訪問沒有使頁面移動(dòng)到y(tǒng)oung區(qū)域的頭部 這里統(tǒng)計(jì)的沒有將頁面移動(dòng)到y(tǒng)oung區(qū)域的頭部次數(shù)不僅僅包含因?yàn)樵O(shè)置了innodb_old_blocks_time系統(tǒng)變量而導(dǎo)致訪問了old區(qū)域中的節(jié)點(diǎn)但沒把它們移動(dòng)到y(tǒng)oung區(qū)域的次數(shù)，還包含因?yàn)樵摴?jié)點(diǎn)在young區(qū)域的前1/4處而沒有被移動(dòng)到y(tǒng)oung區(qū)域頭部的次數(shù)。 LRU len：代表LRU鏈表中節(jié)點(diǎn)的數(shù)量。 unzip_LRU：代表unzip_LRU鏈表中節(jié)點(diǎn)的數(shù)量（由于我們沒有具體嘮叨過這個(gè)鏈表，現(xiàn)在可以忽略它的值）。 I/O sum：最近50s讀取磁盤頁的總數(shù) I/O cur：現(xiàn)在正在讀取的磁盤頁數(shù)量 I/O unzip sum：最近50s解壓的頁面數(shù)量 I/O unzip cur：正在解壓的頁面數(shù)量

MySQL 數(shù)據(jù)結(jié)構(gòu)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。