你好呀，我是歪歪。
这期给大家分享一个读者给我分享的一个关于 MyBatis 的“编程小技巧”，说真的，这骚操作，直接把我看得一愣一愣的。
我更情愿叫它：坑你没商量之埋雷大法。
Demo
为了让你丝滑入戏，我还是先给你搞个 Demo。
因为要使用到 MyBatis 嘛，所以我们先搞两个表。
一个表叫做 product 表，表结构非常简单：
另一个表叫做 order_info 表，表结构也非常简单：
看到这两个表出现的时候，你就知道我的场景是啥了，肯定是卖货嘛。
库存减一，订单加一。
大家再熟悉不过的场景了。
分分钟能写出这样的伪代码：
public void saleProduct(){
//更新库存，库存减一
productMapper.updateProductCount();
//保存订单信息
orderInfoMapper.saveOrderInfo();
}
当然了，这个伪代码你一眼就能看出问题：减库存和保存订单应该是一个事务操作，所以应该把这两个动作包裹在事务里面。
于是我们的伪代码变成了这样：
public void saleProduct() {
//开启事务
begin;
//更新库存，库存减一
Boolean updateSuccess = productMapper.updateProductCount();
//保存订单信息
orderInfoMapper.saveOrderInfo();
if (updateSuccess) {
//提交事务
commit;
} else {
//回滚事务
rollback
}
}
当时读者给我举例的时候，完全是另外一个场景，和卖货完全没有任何关系。
读者举的例子大概是几个表之间有关联关系，如果一个表的某条数据被删除了，另外几个表里面对应的数据也要删除，还有一个表需要更新状态。
为了更好的展示这个“编程小技巧”，我才把场景简化到了前面提到的卖货的样子。
前面说的是伪代码。
现在我给你展示一下用“编程小技巧”写出来的真实的代码。
首先是 controller 接口：
@GetMapping("/sale")
public void sale() {
productMapper.selaProduct();
}
然后是这个 productMapper 的 selaProduct 接口：
是的，你没有看错，这就是一个 MyBatis 的 mapper 接口，接下来就直接到了 mapper.xml 文件里面：
这写法，这小技巧，我都不打算问你骚不骚，我就问你见没见过？
能用吗？
歪师傅还是太年轻，见识不够，在这之前从来没见过在 mapper.xml 里面能这样去写 sql 的。
不说见过，在我的小脑袋里面，我是压根就没想过这样去写。所以看到这个写法的第一反应是：这能行吗？这不行吧？
于是，秉承着大胆假设小心求证的态度，写了上面的 Demo。
项目启动之后发起调用，控制台直接报了错：
看到这个报错的时候，我下意识的觉得就是 MyBatis 不支持这样的写法，直接报错了，这也符合我之前的认知。
但是，在读者的指导下，他提醒我在数据库连接的配置上加上这样的配置：
allowMultiQueries=true
我的 Demo 启动的时候，确实没有加这个配置。但是看到这个配置的一瞬间，我开始觉得有点意思了。
因为我知道这个配置是干嘛的。
见名知意嘛：allow Multi Queries，允许进行多个查询。
最常用的场景就是用 foreach 标签来进行批量插入或者更新的时候会用到这个配置。
在这个参数的加持下，前面 mapper.xml 里面的写的那个 sql，很有可能就能正常执行了。
因为加入这个配置之后，可以在一个数据库连接中执行多个 sql 语句，而对于 MyBatis 或者 MySQL 的驱动来说，它并不区这“多个 sql”都是 insert 语句还是 update 语句，或者是混合着都有的语句。
我也去 MySQL 官网上查询了这个配置的含义：
dev.mysql.com/doc/connect…
对于这个参数，官网上就一句话：
Allow the use of ";" to delimit multiple queries during one statement. This option does not affect the 'addBatch()' and 'executeBatch()' methods, which rely on 'rewriteBatchStatements' instead.允许在一条语句中使用"; "分隔多个查询。该选项不会影响 "addBatch() "和 "executeBatch() "方法，因为它们依赖于 "rewriteBatchStatements"。
在介绍 allowMultiQueries 的时候，还提到了一个 rewriteBatchStatements 参数。
关于这个参数是干啥的，我这里就不展开描述了，我只能说这两个玩意是一套组合拳，里面也大有文章，如果你不知道，建议你去了解一下。
就当是课后习题了。
我们还是先跟着主干走。
当我在数据库连接上追加配置 allowMultiQueries=true 之后，重启了服务。
再次发起调用。
为了表示我的震惊，我给你搞个动图：
库存减一，订单加一，方法执行成功了。
还真 TM 能用，你说这事搞的，实属是开了眼了。
这波涨知识了，属于未曾设想过的道路。
埋雷
千万别这样写！
听歪师傅一句劝，千万别这样写！
首先这样的写法就不符合绝大部分程序员的认知。
试问谁能想到最后的 mapper.xml 里面，并不只是简简单单的 sql，里面居然还埋在一坨业务逻辑呢？
关键是这样写也埋雷啊。
举个简单的例子，这样的写法，完全没有考虑库存是否足够的情况：
比如，当前库存没有了，按照这样的写法，还是会在 order_info 表里面插入一条数据。
超卖了，朋友。
只有 commit，没有考虑回滚的情况。
而且这样写根本就完全不可能考虑超卖的情况，因为你拿不到扣减库存的操作是否执行成功，从而无法判断是需要 commit 还是 rollback。
什么，你问我能不能写存储过程来判断？
能，MyBatis 确实可以调用存储过程。
首先，存储过程还是得在 MySQL 里面写好，MyBatis 只是发起调用。
其次，赶紧打消你这个越走越远的骚想法，老老实实的写 Java 代码来解决这个问题，它不香吗？
什么，你又问我如果是不需要判断前一条 sql 是否执行成功的场景呢？
比如我前面提到的读者举的例子，几个表之间有关联关系，如果一个表的某条数据被删除了，另外几个表里面对应的数据也要删除，还有一个表需要更新状态。
大概是这样的：
begin;
delete from table1 where user_id=xxx;
delete from table2 where user_id=xxx;
delete from table3 where user_id=xxx;
update table4 set user_status=1 where user_id=xxx;
commit;
和卖货的场景不一样的是，在这个场景下如果每个 sql 执行成功，则代表业务执行成功。
看起来，似乎没什么问题。
但是我问你一个问题：这一组 SQL 一定会走都 commit 吗？
你好好想想？
肯定不一定嘛，保不齐执行的过程中出什么幺蛾子。
举个最简单的例子，表写错了：
在这个场景下，再次发起调用：
程序报错说找不到这个表。
那么请问：此时，订单表是否应该有数据被插入？
出异常了，肯定不应该有数据插入。我看了数据库，确实也没有新数据插入。
看起来确实没问题。
那么再请问：在这种写法的情况下，当前这个事务是被回滚了还是被提交了？
。。。
。。。
。。。
正确答案是被挂起了。
通过执行下面这个 SQL，我们可以获取到当前事务列表：
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;
通过查询结果可以发现，在我们程序抛出异常之后，当前事务还在 RUNNING 状态：
而且，这个事务在服务重启之前，将一直在 RUNNING 状态，即被挂起了。
但仅从程序的角度看，抛出异常，没有数据，符合预期，没有任何毛病。
埋雷了。
所以，听歪师傅一句劝，千万别这样写！
老老实实的写大家都看得懂的 Java 代码，不要在 mapper.xml 里面搞事情。
扩展
其实我觉得吧，前面都属于卵用不大的知识点，因为大家一般都不会这样去写。
但是既然都写到这里了，场景也有了，我也给大家扩展一个稍微有点用的知识。
还是在卖货的场景下。
订单加一，库存减一是这样的。
begin;
INSERT INTO order_info(`buy_name`, `buy_goods`) VALUES ('歪师傅', 'ipad pro顶配版');
update product set product_count=product_count-1 where id=1 and product_count>0;
commit;
而库存减一，订单加一是这样的：
begin;
update product set product_count=product_count-1 where id=1 and product_count>0;
INSERT INTO order_info(`buy_name`, `buy_goods`) VALUES ('歪师傅', 'ipad pro顶配版');
commit;
都是包裹在事务里面，为了简化代码，我们假设库存非常够用，先不考虑 rollback 的场景。
请问是“订单加一，库存减一”的性能好，还是“库存减一，订单加一”的性能好，还是说这二者没有什么区别？
首先，从执行结果上看，这二者确实是没有什么区别的，都能保证业务场景的正确性。
但是当你考虑性能的时候，肯定是“订单加一，库存减一”的性能更好。
如果你没想明白的话，我给你一个简单的提示：在业务正确的前提下，加锁的代码越靠近解锁的代码，是不是性能越好？
如果你还没想明白的话，我再给你一个提示：库存减一，它会加锁吗？你不管它是加表锁、间隙锁还是记录锁，我就问你它加不加锁？
如果你还没反应过来的话，说明你对于 MySQL 的加锁机制掌握的有点薄弱，可以去加固一下。
我直接公布答案了：
update product set product_count=product_count-1 where id=1 and product_count>0;
因为 where 条件中是 id=1，所以锁是加在唯一索引上的，而且表中存在该记录，所以只会对 id=1 这行记录加锁。
针对 id=1 这一个产品来说，如果它是一个热点商品，我们采取“订单加一，库存减一”的写法，性能会更高一点。
因为在加锁频率相同的情况下，解锁越快的，性能越高。
上个图你就明白了：
调换一个 SQL 的事儿，性能就上去了，我就问你舒不舒服？
最后，再说个不相关的：
我在文章最开始的地方给了这样的一个图片：
你不觉得别扭吗？
sela 是什么鬼？
很明显，这个地方是一个单纯的拼写错误，想要打出的单词是 sale：
请问，当你在程序里面看到这样的拼写的时候，你会怎么办？
如果是我，我会主动把 selaProduct 修改为 saleProduct，其他什么都不会动。
这就是我在之前的文章中提到的一个编码规则，童子军军规：
修改一个拼写错误的方法名、变量名，在代码里面也是一件很重要的小事。
这不是代码洁癖，这是基本的职业道德。
因为你也不想下一个接手你代码的人，因为看到一堆叫做“succeess、createTiem、lastUpdataBy、bussinessDate、proudectName”等等这些变量名而血压上升，气大伤身。
