點(diǎn)擊上方藍(lán)字“設(shè)為星標(biāo)”
大家好，我是架構(gòu)擺渡人。這是實(shí)踐經(jīng)驗(yàn)系列的第七篇文章，這個(gè)系列會(huì)給大家分享很多在實(shí)際工作中有用的經(jīng)驗(yàn)，如果有收獲，還請(qǐng)分享給更多的朋友。今天給大家分享一個(gè)容易忽略的問題，正是因?yàn)槿菀缀雎?，所以才要重視?/span>我們的業(yè)務(wù)表中有兩個(gè)字段是必不可少的，分別是創(chuàng)建時(shí)間和修改時(shí)間，這樣就知道數(shù)據(jù)是什么時(shí)候創(chuàng)建的，最后一次的修改時(shí)間是什么時(shí)候。就是經(jīng)常會(huì)在修改時(shí)間上看到這個(gè)語句ON UPDATE CURRENT_TIMESTAMP，SQL語句如下：?
`update_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;
?
也就是說update_time這個(gè)字段不需要我們手動(dòng)去維護(hù)，只要這行數(shù)據(jù)有修改，就會(huì)自動(dòng)更新update_time，非常方便的一個(gè)功能。但這個(gè)功能如果沒用好，是很有可能帶來嚴(yán)重的問題，下面給大家介紹下會(huì)帶來什么問題？在某個(gè)業(yè)務(wù)場(chǎng)景下，會(huì)使用update_time來進(jìn)行范圍查詢，也就是查詢?cè)隽扛碌臄?shù)據(jù)。正常情況下是沒有問題的，功能也跑了很久。突然有一天，這個(gè)查詢大量報(bào)錯(cuò)，SQL都是超時(shí)的情況，并且影響了其他的業(yè)務(wù)，因?yàn)槎际锹齋QL。通過SQL執(zhí)行計(jì)劃，發(fā)現(xiàn)update_time范圍查詢最近一天的數(shù)據(jù)，掃描行數(shù)達(dá)到了上千萬，你說能不超時(shí)么？問題是之前都沒問題，突然就出了這個(gè)問題，是不是SQL寫錯(cuò)了？其實(shí)沒有，只是因?yàn)閡pdate_time范圍內(nèi)確實(shí)有這么多數(shù)據(jù)。另一個(gè)問題來了，為什么一天內(nèi)有這么多數(shù)據(jù)變更呢?經(jīng)排查，剛好有一個(gè)需求需要對(duì)老數(shù)據(jù)進(jìn)行清洗，剛好update_time又是ON UPDATE CURRENT_TIMESTAMP，所以變更了的數(shù)據(jù)都會(huì)更新update_time，從而導(dǎo)致業(yè)務(wù)查詢異常。?
以后凡是對(duì)于老數(shù)據(jù)清洗，除了更新要清洗的字段之外，還需要更新update_time為原先的值，這樣就不會(huì)影響業(yè)務(wù)。?
update table set name=xxx,update_time=update_time where xxx=xxx
?
update_time如果加了ON UPDATE CURRENT_TIMESTAMP如果有業(yè)務(wù)查詢需求，就要慎重考慮是否可以使用，最好還是單純的作為數(shù)據(jù)的系統(tǒng)變更時(shí)間。業(yè)務(wù)變更時(shí)間還是由程序去控制，單獨(dú)加一個(gè)業(yè)務(wù)變更時(shí)間字段，這樣即使清洗數(shù)據(jù)時(shí)update_time變了也不影響業(yè)務(wù)。?
大家好，我是從古代穿越過來的美男子：架構(gòu)擺渡人。我將把我的武功秘籍全部傳授與你們，覺得有用請(qǐng)分享給身邊的朋友。來個(gè)三連吧，感謝各位！另外我還在B站錄制了《真實(shí)訂單業(yè)務(wù)，億級(jí)數(shù)據(jù)帶你實(shí)戰(zhàn)分庫分表》的實(shí)戰(zhàn)課程，記得去學(xué)習(xí)哦！
