记录一次IntelliJ IDEA Debug调试查看MyBatis-plus更新接口返回的更新结果时导致的全表更新。

前言&描述

为了找到bug的位置，有些时候会选择调试进行排查。然后为了看某个属性的值，习惯使用alt+鼠标左键点击查看某个值。但是最后出现了全表更新的问题。

复现&流程

假设有这样一张表。

你想更新Id为5的数据。

但是你想提前一步知道运行结果，然后习惯的使用了ALT+鼠标左键查看代码

鼠标左键点击之后你知道了代码的运行结果

但是你可能不会注意到你引发了一次完美的全表更新。

跟踪&解析

使用mybatis-plus的SQL打印日志

 执行SQL分析打印 | MyBatis-Plus

一系列配置之后我们再重新看一下刚刚的ALT+鼠标左键点击后它执行了些什么。

没错，它执行了:

UPDATE test_model  SET `describe`='茶壶拒绝冲煮咖啡，因为它只是一个一个茶壶!'

那我们的where条件呢？

没了。因为此时的代码还没执行到

updateWrapper.eq(TestModel::getId,"5");

另外，如果这个时候使用Add to Watches也会和使用ALT+鼠标左键一样会导致出现这种情况。

因为这两者都会去执行一遍目标方法以展示方法运行的结果。尤其是Add to Watches，每次F8（执行下一行代码时）都会去执行一次目标方法，无论目标方法是否已被执行过。 

Add to Watches后，这一路F8下来执行了这么多次SQL

预防

毕竟人总会偶尔疏忽一下下，但这种疏忽往往可能会引发一些较大的问题。而我们目前能做的是尽最大限度降低这种疏忽和因疏忽导致引发大问题的概率。

第一 条件构造器的规范

上述代码中，set在前(用于更新字段)，eq在后(用于设定条件)。明显这样的写法不太合适。

 因为在实际的应用当中在做更新某个数据的时候我们会注重SQL的条件（如果不注重的话弄不好又是全表更新或者大规模更新啊啊啊啊啊啊啊....）所以在写这个条件构造器的时候，我们应当把eq写在set的前面。这样即使误操作了，也将至少在更新时拥有一个条件来限制更新的范围，至少能最大限度避免全表更新。

把条件给放到最开始

  当然了，还可以这么写。这种写法无论ALT+鼠标左键还是用Add to Watches来即使是set在前eq在后也都是没有办法执行这个更新方法的。

第二 使用变量接收

在使用mybatis-plus的更新接口时不应该直接使用ALT+鼠标左键和Add to Watches来观察更新接口返回的值（如果是查询接口的话随意）。应当用一个变量来接收它的结果，待更新接口执行完毕后再用ALT+鼠标左键点击变量或者选择调试面板上的Debugger来查看返回的结果。

ALT+鼠标左键 使用变量接收的好处就是这样，它会自动出现在这里，无需Add to Watches

 结语

error418：我是一个一个一个茶壶哼哼啊啊 :-D