背景

由于平臺幣需要從之前的整形類型變?yōu)橹С中?shù)的decimal類型,所以需要對訂單表的字段類型進行修改.

訂單表: 目前數(shù)據(jù)已經有 2000多萬數(shù)據(jù)了,數(shù)據(jù)量還是比較大的, 需要修改的字段有3個,訂單表名為 order_info

解決方案一

直接用sql原生語句

alter table order_info MODIFY column coin_count decimal(6, 1);

耗時 500多秒都沒執(zhí)行完, 撤回了,因為鎖表用戶下不了單影響可能還是比較大的,所以該方案廢棄了

解決方案二

用新舊表邏輯進行處理,主要步驟有以下幾步

1: 創(chuàng)建新的表,名字為 order_info_new, 結構從 order_info 復制, 但是那三個字段已經從int改為decimal了, 這個步驟是不會鎖表的

2: 把原有的order_info表名改為 order_info_old, 同時把order_info_new改為 order_info即可,這個步驟也很快,同時也不會鎖表

3: 使用mysql自帶的命令行語句把之前的數(shù)據(jù)遷移到新表中,語句如下,只需要等待完成即可:

INSERT INTO order_info SELECT * FROM order_info_old

注: 第1步建立表時需要注解id的問題,如果是自增的話那么新表的自增id要大一些,防止切換過程中id發(fā)生沖突問題

第三步執(zhí)行時mysql默認是開啟事務的,所以執(zhí)行過程數(shù)據(jù)會查詢不到,需要等到執(zhí)行完成,看有沒有這方面需要考慮的問題

選擇

最終自然是使用了第二種方案咯,整個過程也不算太慢,2000多萬數(shù)據(jù)遷移也就用了半個多小時,阿里的RDS感覺還是有點東西的應該

其他優(yōu)化

在處理這個問題時,同時一并處理了訂單表設計不合理的地方,主要處理了兩個問題

1: 數(shù)據(jù)字段類型不合理設計

2: 歷史數(shù)據(jù)進行部分遷移

類型優(yōu)化

 `delivery_status` int DEFAULT '1' COMMENT '發(fā)貨狀態(tài) 1:未發(fā)貨 2:已發(fā)貨' 訂單表存在很多這種不合適的字段類型,不合理是因為這個字段只會有2個值,所以應該改為

 `delivery_status` tinyint DEFAULT '1' COMMENT '發(fā)貨狀態(tài) 1:未發(fā)貨 2:已發(fā)貨',這樣比較合理

改完效果還是比較明顯的,一條數(shù)據(jù)就可以節(jié)省3個字節(jié),2000多萬條大概節(jié)省了12G空間出來,這是一件很有意義的事來的

歷史數(shù)據(jù)遷移

order_info的數(shù)據(jù)從 2020年一直到2024年的數(shù)據(jù)都是在同一張表,但其實很多歷史數(shù)據(jù)也不會查了,所以把2020-2021年的數(shù)據(jù)遷移到新的表中去了,做法也很簡單

1: 原來的 order_info 只保留了 2022年以后至今的數(shù)據(jù)

2: 再創(chuàng)建一張 order_info_history 數(shù)據(jù)表,結構一摸一樣的

3: 把 order_info 2022年前的數(shù)據(jù)全部轉到 order_info_history 中

具體的操作命令如下:

INSERT INTO order_info SELECT * FROM order_info_old where create_time >= 1640966400000;
INSERT INTO order_info_history SELECT * FROM order_info_old where create_time < 1640966400000;

總結

到此這篇關于Mysql大表修改字段兩種解決方式的文章就介紹到這了,更多相關Mysql大表修改字段內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論