踩坑经验 | DBeaver 多行SQL执行了一半

10

2023-09

踩坑经验 | DBeaver 多行SQL执行了一半

虽然需求解决了，但是这个问题是为啥我还真的不知道，崩溃~

LEARN MORE

图片由海艺AI绘制

做了一份主要处理bug的工作，那就总是要见鬼的，不知道是运气原因还是啥的，我觉得我见鬼的次数还真的是多。

需求背景是这样的，我需要更新一个数据，简单来说是把数据库里对应表的数据更新成新的。这个工作是同事交接给我的，第一次搞，虽然对于这个事情我有十万句吐槽要说，但是我还是乖乖去执行了。

首先我check了一下数据，原本的数据有1.1W行左右，新的数据大概是1.2W行左右，表格没有主键。比对需求方给我的excel表，数据库的表只是单纯多了create time\create by这种其实没有啥卵用的信息（我都写SQL改库了，这些信息完全都是失真的好不好）。

毕竟是直接出手改库，还是担心改错的。出于害怕搞错了的想法，我一开始的方案是这样的：先把当前表导出一份作为备份，然后把需求方的数据搞成insert sql，把新的数据插入，最后再把表里已有的数据删除，删除的依据就用create by，把前人导入的数据删掉。

看起来计划通，没有毛病，非常稳妥。

导出数据备份和把excel表中的数据拼接SQL语句也没遇到什么问题（除了垃圾电脑一动一死机以外）。好戏从开始执行SQL的开场。

虽然批量插入的效率高于逐条插入，但是数据只有1w行左右的时候，理论上来说应该没啥特别明显感知。而且对于这种来源不明的线下手工文件，保不齐会有什么离谱的非法数据，批量插入万一报错了我都不好排查问题出在了哪一条数据哪里。何况，批量插入万一锁表了怎么办。于是我“机智”地选择了 逐条 插入数据。

然而，SQL执行完，告诉我插入了600行左右。

什么玩意？我一万多条SQL语句，执行了600条就没了？在经历过突然不能执行多条语句之后，看到这个问题瞬间皱起了眉头，不要玩我啊。

于是我选择把刚插入的数据删掉再插入一次。

好家伙，这次插入了1300行左右。

神奇，这都什么离谱的情况噢，我还真就不信这个邪了，删掉再来一次。

再来就是800行。

看了一眼时间，算了，不纠结了，下班要紧，直接把CSV文件导入完事。

本着对神奇问题的好奇心，回家之后我去查了各种资料。

首先，确认逐条插入确实性能不如批量插入，但是对于一万多行数据来说，性能差异完全在我可以等待的范围内。相比跑得慢，我更害怕锁表了，因为这个时间段有非常多的ETL调度任务在跑，鬼知道会不会引起什么离谱的冲突）。其次，DBeaver似乎并不会截断我的SQL语句，否则不应该出现几次执行的行数不一致的问题，如果是SQL语句太长复制粘贴过来的时候被截断了，那应该几次执行插入的行数是一致的。最后，没有搜到任何和这个问题类似的帖子。

虽然需求处理完了，一条路子不行就换一个。然而这个问题到底是为什么完全没有一点头绪，唯一能作为解释的理由大概是……我断网了。毕竟日常查case经常遇到上一秒还没问题，下一秒SQL就跑不出来了需要重新连接的问题。