Mysql大表修改字段兩種解決方式
背景
由于平臺幣需要從之前的整形類型變?yōu)橹С中?shù)的decimal類型,所以需要對訂單表的字段類型進(jìn)行修改.
訂單表: 目前數(shù)據(jù)已經(jīng)有 2000多萬數(shù)據(jù)了,數(shù)據(jù)量還是比較大的, 需要修改的字段有3個(gè),訂單表名為 order_info
解決方案一
直接用sql原生語句
alter table order_info MODIFY column coin_count decimal(6, 1);
耗時(shí) 500多秒都沒執(zhí)行完, 撤回了,因?yàn)殒i表用戶下不了單影響可能還是比較大的,所以該方案廢棄了
解決方案二
用新舊表邏輯進(jìn)行處理,主要步驟有以下幾步
1: 創(chuàng)建新的表,名字為 order_info_new, 結(jié)構(gòu)從 order_info 復(fù)制, 但是那三個(gè)字段已經(jīng)從int改為decimal了, 這個(gè)步驟是不會鎖表的
2: 把原有的order_info表名改為 order_info_old, 同時(shí)把order_info_new改為 order_info即可,這個(gè)步驟也很快,同時(shí)也不會鎖表
3: 使用mysql自帶的命令行語句把之前的數(shù)據(jù)遷移到新表中,語句如下,只需要等待完成即可:
INSERT INTO order_info SELECT * FROM order_info_old
注: 第1步建立表時(shí)需要注解id的問題,如果是自增的話那么新表的自增id要大一些,防止切換過程中id發(fā)生沖突問題
第三步執(zhí)行時(shí)mysql默認(rèn)是開啟事務(wù)的,所以執(zhí)行過程數(shù)據(jù)會查詢不到,需要等到執(zhí)行完成,看有沒有這方面需要考慮的問題
選擇
最終自然是使用了第二種方案咯,整個(gè)過程也不算太慢,2000多萬數(shù)據(jù)遷移也就用了半個(gè)多小時(shí),阿里的RDS感覺還是有點(diǎn)東西的應(yīng)該
其他優(yōu)化
在處理這個(gè)問題時(shí),同時(shí)一并處理了訂單表設(shè)計(jì)不合理的地方,主要處理了兩個(gè)問題
1: 數(shù)據(jù)字段類型不合理設(shè)計(jì)
2: 歷史數(shù)據(jù)進(jìn)行部分遷移
類型優(yōu)化
`delivery_status` int DEFAULT '1' COMMENT '發(fā)貨狀態(tài) 1:未發(fā)貨 2:已發(fā)貨' 訂單表存在很多這種不合適的字段類型,不合理是因?yàn)檫@個(gè)字段只會有2個(gè)值,所以應(yīng)該改為
`delivery_status` tinyint DEFAULT '1' COMMENT '發(fā)貨狀態(tài) 1:未發(fā)貨 2:已發(fā)貨',這樣比較合理
改完效果還是比較明顯的,一條數(shù)據(jù)就可以節(jié)省3個(gè)字節(jié),2000多萬條大概節(jié)省了12G空間出來,這是一件很有意義的事來的
歷史數(shù)據(jù)遷移
order_info的數(shù)據(jù)從 2020年一直到2024年的數(shù)據(jù)都是在同一張表,但其實(shí)很多歷史數(shù)據(jù)也不會查了,所以把2020-2021年的數(shù)據(jù)遷移到新的表中去了,做法也很簡單
1: 原來的 order_info 只保留了 2022年以后至今的數(shù)據(jù)
2: 再創(chuàng)建一張 order_info_history 數(shù)據(jù)表,結(jié)構(gòu)一摸一樣的
3: 把 order_info 2022年前的數(shù)據(jù)全部轉(zhuǎn)到 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;
總結(jié)
到此這篇關(guān)于Mysql大表修改字段兩種解決方式的文章就介紹到這了,更多相關(guān)Mysql大表修改字段內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
MySQL slow_log表無法修改成innodb引擎詳解
這篇文章主要給大家介紹了關(guān)于MySQL slow_log表無法修改成innodb引擎的相關(guān)資料,文中通過示例代碼介紹的非常詳細(xì),對大家學(xué)習(xí)或者使用MySQL具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面來一起學(xué)習(xí)學(xué)習(xí)吧2019-04-04
MySQL提升大量數(shù)據(jù)查詢效率的優(yōu)化神器
這篇文章主要介紹了MySQL提升大量數(shù)據(jù)查詢效率的優(yōu)化神器,文章圍繞主題展開詳細(xì)的內(nèi)容介紹,具有一定的參考價(jià)值,需要的小伙伴可以參考一下2022-07-07
解決Idea鏈接mysql數(shù)據(jù)庫失敗Schemas中為空的問題
文章講述了在使用Sechemas攔截MySQL數(shù)據(jù)庫時(shí)遇到?jīng)]有數(shù)據(jù)的情況,并分析了可能是由于數(shù)據(jù)庫版本問題導(dǎo)致的,作者建議根據(jù)自己的數(shù)據(jù)庫版本進(jìn)行選擇,如果不確定版本,可以嘗試所有版本,以解決問題2026-01-01
MySQL主從架構(gòu)原理、優(yōu)化與實(shí)踐指南全解析
這是一份關(guān)于MySQL主從架構(gòu)的深度解析指南,本文將從核心原理出發(fā),延伸至架構(gòu)優(yōu)化、延遲排查及高可用切換等實(shí)踐層面,幫助您構(gòu)建一個(gè)穩(wěn)定、高效的 MySQL 數(shù)據(jù)同步體系2026-04-04
前端傳參數(shù)進(jìn)行Mybatis調(diào)用mysql存儲過程執(zhí)行返回值詳解
這篇文章主要介紹了前端傳參數(shù)進(jìn)行Mybatis調(diào)用mysql存儲過程執(zhí)行返回值詳解,文章圍繞主題展開詳細(xì)的內(nèi)容介紹,具有一定的參考價(jià)值,需要的小伙伴可以參考一下2022-08-08

