因为一条sql语句产生了自我怀疑

故事是这样开始的

在一个月黑风高的夜晚

现场报过来，本该打到新服务的流量，又走到了老服务，老服务的功能不健全，很可能会让现场的用户不能支付。 需要说明一点的是，任何一个从老服务改造到新服务的时候，都不是完全把流量切过去，都需要经过一点时间去验证。

比如我们按照地理位置去切，将北京的部分车场（是的，我们是做停车服务的），切到新服务，其他城市的车场在老服务

我们采用最简单的办法，就是靠一个字段type去控制（0和1）

翻遍所有的服务，关乎这个表的都是update操作，update操作因为没有这个字段时打死也不会改这个type的

冷静下来想想，数据库默认字段为1，然后0都会变成1。没有1变成0的，可以肯定的是，先删除，又新增了，否则没有别的解释

经过一番查验，找到这样一堆代码(伪代码)

replace INTO `A` (
      park_id,
      xxxx,
      xxxx
    )
    SELECT
       park_id,
       xxxx,
       xxxx 
    FROM
    B 
    where b.park_id = #{parkId}复制代码

看到这里，心里嘿嘿一笑，破案了。。。。。

replace INTO

是的，就是replace INTO搞得鬼，大家都知道，replace INTO和insert into的区别

这就正好验证了上面的猜想，只有删除再添加，才会让type跟随数据库的默认值走

讲到这里不妨我们多了解一点这个，有人可能会问，replace是不是取代了insert和delete，毕竟是干了两件事

MySql手册关于replace into的算法:Mysql手册

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对REPLACE（和LOAD DATA…REPLACE）使用以下算法：

尝试将新行插入表中

当由于主键或唯一索引出现重复键错误而导致插入失败时：

从表中删除具有重复键值的冲突行

再次尝试将新行插入表中复制代码

先插入, 出错了再执行delete加insert. 如果自己用程序来做, 个人认为效率会低很多，另外这样写真的很搞人

这里推荐使用INSERT...ON DUPLICATE KEY UPDATE, 感觉很靠谱. replace的副作用:

• replace每次要重新分配自增id;

• replace中执行delete时, 在有外键的情况下会很麻烦;

• 如果delete时定义的有触发器, 则会被执行;

• 副作用也会被传播到replica slave

总结

最后祝大家2023，少写bug，少加班，多涨薪