站長(zhǎng)資訊網(wǎng)
故事是這樣開(kāi)始的
在一個(gè)月黑風(fēng)高的夜晚
現(xiàn)場(chǎng)報(bào)過(guò)來(lái)，本該打到新服務(wù)的流量，又走到了老服務(wù)，老服務(wù)的功能不健全，很可能會(huì)讓現(xiàn)場(chǎng)的用戶不能支付。 需要說(shuō)明一點(diǎn)的是，任何一個(gè)從老服務(wù)改造到新服務(wù)的時(shí)候，都不是完全把流量切過(guò)去，都需要經(jīng)過(guò)一點(diǎn)時(shí)間去驗(yàn)證。
比如我們按照地理位置去切，將北京的部分車(chē)場(chǎng)（是的，我們是做停車(chē)服務(wù)的），切到新服務(wù)，其他城市的車(chē)場(chǎng)在老服務(wù)
我們采用最簡(jiǎn)單的辦法，就是靠一個(gè)字段type去控制（0和1）
看似簡(jiǎn)單，但是事怪就怪在這個(gè)字段上，這個(gè)控制字段是屬于后來(lái)加到數(shù)據(jù)庫(kù)字段的，而且沒(méi)有對(duì)外去配置，都是通過(guò)運(yùn)維手動(dòng)去數(shù)據(jù)庫(kù)配置的，且數(shù)據(jù)庫(kù)字段默認(rèn)值設(shè)置為1。
可總有幾個(gè)車(chē)場(chǎng)時(shí)不時(shí)的從0就變成了1。。眾所周知,一個(gè)新的字段不在mybatis xml和pojo出現(xiàn)，那么就不會(huì)有操作改掉
翻遍所有的服務(wù)，關(guān)乎這個(gè)表的都是update操作，update操作因?yàn)闆](méi)有這個(gè)字段時(shí)打死也不會(huì)改這個(gè)type的
冷靜下來(lái)想想，數(shù)據(jù)庫(kù)默認(rèn)字段為1，然后0都會(huì)變成1。沒(méi)有1變成0的，可以肯定的是，先刪除，又新增了，否則沒(méi)有別的解釋
經(jīng)過(guò)一番查驗(yàn)，找到這樣一堆代碼(偽代碼)
replace INTO `A` ( park_id, xxxx, xxxx ) SELECT park_id, xxxx, xxxx FROM B where b.park_id = #{parkId}復(fù)制代碼
看到這里，心里嘿嘿一笑，破案了。。。。。
replace INTO
是的，就是replace INTO搞得鬼，大家都知道，replace INTO和insert into的區(qū)別
1、replace into 首先嘗試插入數(shù)據(jù)到表中， 如果發(fā)現(xiàn)表中已經(jīng)有此行數(shù)據(jù)（根據(jù)主鍵或者唯一索引判斷）則先刪除此行數(shù)據(jù)，然后插入新的數(shù)據(jù)。
2、如果表中無(wú)此數(shù)據(jù)，則插入新數(shù)據(jù)。
這就正好驗(yàn)證了上面的猜想，只有刪除再添加，才會(huì)讓type跟隨數(shù)據(jù)庫(kù)的默認(rèn)值走
講到這里不妨我們多了解一點(diǎn)這個(gè)，有人可能會(huì)問(wèn)，replace是不是取代了insert和delete，畢竟是干了兩件事
MySql手冊(cè)關(guān)于replace into的算法:Mysql手冊(cè)
MySQL uses the following algorithm for REPLACE (and LOAD DATA ... REPLACE):Try to insert the new row into the tableWhile the insertion fails because a duplicate-key error occurs for a primary key or unique index:Delete from the table the conflicting row that has the duplicate key valueTry again to insert the new row into the tableMySQL對(duì)REPLACE（和LOAD DATA…REPLACE）使用以下算法： 嘗試將新行插入表中 當(dāng)由于主鍵或唯一索引出現(xiàn)重復(fù)鍵錯(cuò)誤而導(dǎo)致插入失敗時(shí)： 從表中刪除具有重復(fù)鍵值的沖突行 再次嘗試將新行插入表中復(fù)制代碼
先插入, 出錯(cuò)了再執(zhí)行delete加insert. 如果自己用程序來(lái)做, 個(gè)人認(rèn)為效率會(huì)低很多，另外這樣寫(xiě)真的很搞人
這里推薦使用INSERT…ON DUPLICATE KEY UPDATE, 感覺(jué)很靠譜. replace的副作用:
-
replace每次要重新分配自增id;
-
replace中執(zhí)行delete時(shí), 在有外鍵的情況下會(huì)很麻煩;
-
如果delete時(shí)定義的有觸發(fā)器, 則會(huì)被執(zhí)行;
-
副作用也會(huì)被傳播到replica slave
總結(jié)
開(kāi)發(fā)當(dāng)中難免遇到奇奇怪怪的各種問(wèn)題，有問(wèn)題莫慌，冷靜分析，你認(rèn)為的不可能事件、你認(rèn)為的計(jì)算機(jī)會(huì)發(fā)生錯(cuò)誤，其實(shí)都是自己沒(méi)有去完全理解到位，跟蹤到位！！！【推薦學(xué)習(xí)：MySQL視頻教程、SQL視頻教程】
最后祝大家2023，少寫(xiě)bug，少加班，多漲薪
