生產(chǎn)環(huán)境為主從架構(gòu)，每月業(yè)務(wù)都會(huì)load幾千萬(wàn)的數(shù)據(jù)到同一張表，該表的數(shù)據(jù)是按月做了分區(qū)。

Mysql數(shù)據(jù)庫(kù)中通過(guò)load向一張空表中導(dǎo)入5000萬(wàn)數(shù)據(jù)，總大小25G左右，分成87個(gè)文件依次導(dǎo)入，從第一個(gè)文件開(kāi)始保持30秒左右，后續(xù)load時(shí)間持續(xù)增長(zhǎng)一直到75個(gè)文件后每個(gè)load的市場(chǎng)基本都在1000s以上，一直到83個(gè)文件的幾個(gè)小時(shí)都無(wú)法成功load數(shù)據(jù)到mysql數(shù)據(jù)庫(kù)。

Mysql主機(jī)資源情況如下所示：

CPU：8

內(nèi)存：32G

Innodb_buffer_pool_size：24G

慢查詢?nèi)罩局?/span>load時(shí)長(zhǎng)情況如下所示：

Showprocesslist狀態(tài)如下所示：

60多萬(wàn)數(shù)據(jù)load了一個(gè)多小時(shí)后直接kill回退了，如下所示：

通過(guò)表結(jié)構(gòu)查看該表：

通過(guò)showcreate table table_nmae核實(shí)到該表有個(gè)聯(lián)合主鍵和聯(lián)合索引；

然后由于load的原理是跳過(guò)SQL解析，直接生成數(shù)據(jù)庫(kù)的數(shù)據(jù)文件，導(dǎo)入前關(guān)閉索引，導(dǎo)入完成后更新索引；可以得出該表的索引是影響性能的主要原因。然后通過(guò)與前臺(tái)業(yè)務(wù)溝通知道業(yè)務(wù)對(duì)該表的查詢條件只有兩個(gè)字段，然后與業(yè)務(wù)溝通后決定去掉索引重建一個(gè)聯(lián)合主鍵保證業(yè)務(wù)的查詢速度。

如下圖所示：

驗(yàn)證結(jié)果：

表結(jié)構(gòu)優(yōu)化load5000萬(wàn)數(shù)據(jù)分成68個(gè)文件后load時(shí)長(zhǎng)都在40s以內(nèi)，如下圖日志記錄所示：

END