這是學(xué)習(xí)筆記的第 1852篇文章

今天接到一位開(kāi)發(fā)同學(xué)的數(shù)據(jù)操作需求，需求看似很簡(jiǎn)單，需要執(zhí)行下面的SQL語(yǔ)句：delete from test_track_log where log_time < '2019-1-7 00:00:00';

看需求描述是因?yàn)椴樵?xún)統(tǒng)計(jì)較差，希望刪除一些歷史數(shù)據(jù)。

帶著疑問(wèn)我看下了表結(jié)構(gòu)：

CREATE TABLE `test_track_log` (

`id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',

`uid` int(11) unsigned NOT NULL DEFAULT '0' COMMENT '用戶(hù)ID',

...

`log_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '記錄時(shí)間',

PRIMARY KEY (`id`),

KEY `idx_uid_fsm_log` (`uid`,`fsm_id`,`log_time`)

) ENGINE=InnoDB AUTO_INCREMENT=125082604DEFAULT CHARSET=utf8 COMMENT='記錄測(cè)試賬號(hào)的任務(wù)軌跡'

看自增列的情況，這個(gè)表的數(shù)據(jù)量有近1億條記錄了，暫且不說(shuō)數(shù)據(jù)量帶來(lái)的額外影響，單說(shuō)這個(gè)需求，你會(huì)發(fā)現(xiàn)這是一個(gè)隕石坑。

簡(jiǎn)單驗(yàn)證了下，數(shù)據(jù)量確實(shí)在億級(jí)別。

select count(id) from tgp_db.tgp_track_log

+-----------+

| 125082603 |

+-----------+

1 row in set (1 min 26.63 sec)

如果老老實(shí)實(shí)執(zhí)行了，估計(jì)我下午就不用干別的了。

顯然這個(gè)需求是一個(gè)模糊需求，業(yè)務(wù)方希望清理數(shù)據(jù)，但是實(shí)現(xiàn)方式缺不合理。

如果我們使用truncate的操作，這樣看來(lái)目前是比較合適的。

同時(shí)在做數(shù)據(jù)清理的時(shí)候，勢(shì)必要考慮備份數(shù)據(jù)，而和業(yè)務(wù)方確認(rèn)，數(shù)據(jù)可以不用備份，但是從數(shù)據(jù)庫(kù)層面來(lái)說(shuō)，是需要的。

在操作前進(jìn)行細(xì)致的溝通，發(fā)現(xiàn)業(yè)務(wù)方還是會(huì)希望參考近些天來(lái)的數(shù)據(jù)，尤其是當(dāng)天的數(shù)據(jù)，所以這個(gè)操作還是需要謹(jǐn)慎。

這里有兩個(gè)坑：

第一是業(yè)務(wù)方再三確認(rèn)不需要備份，但是如果刪除了數(shù)據(jù)之后，發(fā)生了意料之外的故障，需要恢復(fù)數(shù)據(jù)，而DBA沒(méi)法恢復(fù)，那么這個(gè)鍋我們背不住。

第二是業(yè)務(wù)方再三確認(rèn)刪除的邏輯是正確的，但是他們不負(fù)責(zé)數(shù)據(jù)操作的性能問(wèn)題，我們?nèi)绻蝗徍硕鵀榱藞?zhí)行而執(zhí)行，那么造成性能故障之后，很容易造成需求的分歧。

所以這件事情的本質(zhì)很簡(jiǎn)單，清理數(shù)據(jù)，對(duì)業(yè)務(wù)影響最小，保留指定范圍的數(shù)據(jù)。

這種情況下單純的DML語(yǔ)句是搞不定了，我們需要想一些辦法，這里有一個(gè)技巧，也是我非常喜歡MySQL的一個(gè)亮點(diǎn)特性，即MySQL可以很輕松的把一個(gè)庫(kù)的表遷移到另外一個(gè)數(shù)據(jù)庫(kù)，這種操作的代價(jià)就好像把一個(gè)文件從文件夾1拷貝到文件夾2。

一個(gè)初版的實(shí)現(xiàn)如下：

create table test_db.test_track_log_tmp like test_db.test_track_log;

alter table test_db.test_track_log rename to test_db_arch.test_track_log;

alter table test_db.test_track_log_tmp rename to test_db.test_track_log;

這種操作看起來(lái)很簡(jiǎn)單，但是也存在一些問(wèn)題，一個(gè)是在切換的過(guò)程中，如果寫(xiě)入數(shù)據(jù)是會(huì)丟失數(shù)據(jù)的，即數(shù)據(jù)已經(jīng)入庫(kù)，這里通過(guò)rename丟失數(shù)據(jù)。

第二個(gè)是這個(gè)操作不夠簡(jiǎn)潔。怎么改進(jìn)呢，我們可以把rename的操作玩得更溜。

mysql> create table test_db_arch.test_track_log like test.test_track_log;

mysql> RENAME TABLE test.test_track_log TO test_db_arch.test_track_log_bak,

test_db_arch.test_track_log TO test.test_track_log,

test_db_arch.test_track_log_bak TO test_db_arch.test_track_log;

Query OK, 0 rows affected (0.02 sec)

整個(gè)過(guò)程持續(xù)0.02秒，億級(jí)數(shù)據(jù)的切換，整體來(lái)說(shuō)效果還是很明顯的，也推薦大家在工作中根據(jù)適合的場(chǎng)景來(lái)應(yīng)用。

本文僅代表作者個(gè)人觀點(diǎn)，不代表SEO研究協(xié)會(huì)網(wǎng)官方發(fā)聲，對(duì)觀點(diǎn)有疑義請(qǐng)先聯(lián)系作者本人進(jìn)行修改，若內(nèi)容非法請(qǐng)聯(lián)系平臺(tái)管理員，郵箱cxb5918@163.com。更多相關(guān)資訊，請(qǐng)到SEO研究協(xié)會(huì)網(wǎng)www.seoxiehui.cn學(xué)習(xí)互聯(lián)網(wǎng)營(yíng)銷(xiāo)技術(shù)請(qǐng)到巨推學(xué)院www.jutuiedu.com。

總結(jié)

以上是生活随笔為你收集整理的mysql平滑关闭_MySQL平滑删除数据的小技巧的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。