資訊專欄INFORMATION COLUMN
生產背景
生產環(huán)境為主從架構，每月業(yè)務都會load幾千萬的數(shù)據(jù)到同一張表，該表的數(shù)據(jù)是按月做了分區(qū)。
現(xiàn)象
Mysql數(shù)據(jù)庫中通過load向一張空表中導入5000萬數(shù)據(jù)，總大小25G左右，分成87個文件依次導入，從第一個文件開始保持30秒左右，后續(xù)load時間持續(xù)增長一直到75個文件后每個load的市場基本都在1000s以上，一直到83個文件的幾個小時都無法成功load數(shù)據(jù)到mysql數(shù)據(jù)庫。
Mysql主機資源情況如下所示：
CPU：8
內存：32G
Innodb_buffer_pool_size：24G
慢查詢日志中load時長情況如下所示：
Showprocesslist狀態(tài)如下所示：
60多萬數(shù)據(jù)load了一個多小時后直接kill回退了，如下所示：
分析過程
通過表結構查看該表：
通過showcreate table table_nmae核實到該表有個聯(lián)合主鍵和聯(lián)合索引；
然后由于load的原理是跳過SQL解析，直接生成數(shù)據(jù)庫的數(shù)據(jù)文件，導入前關閉索引，導入完成后更新索引；可以得出該表的索引是影響性能的主要原因。然后通過與前臺業(yè)務溝通知道業(yè)務對該表的查詢條件只有兩個字段，然后與業(yè)務溝通后決定去掉索引重建一個聯(lián)合主鍵保證業(yè)務的查詢速度。
如下圖所示：
驗證結果：
表結構優(yōu)化load5000萬數(shù)據(jù)分成68個文件后load時長都在40s以內，如下圖日志記錄所示：
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/129952.html
摘要：比較的是兩個對象的內容是并發(fā)編程之協(xié)程異步后端掘金引言隨著的盛行，相信大家今年多多少少都聽到了異步編程這個概念。使用進行并發(fā)編程篇二掘金我們今天繼續(xù)深入學習。 python 之機器學習庫 scikit-learn - 后端 - 掘金一、 加載sklearn中的數(shù)據(jù)集datasets from sklearn import datasets iris = datasets.load_i...
閱讀 1353·2023-01-11 13:20
閱讀 1699·2023-01-11 13:20
閱讀 1211·2023-01-11 13:20
閱讀 1902·2023-01-11 13:20
閱讀 4161·2023-01-11 13:20
閱讀 2751·2023-01-11 13:20
閱讀 1397·2023-01-11 13:20
閱讀 3664·2023-01-11 13:20
