背景

项目中有这么一个需求,数据库是MySQL:

  1. 提供一个接口,能够批量插入或更新业务数据,对新数据进行插入操作,已存在的记录进行更新操作。
  2. 更新时,需要判断业务中的某些状态,对符合一定条件的状态进行更新。
  3. 接口的响应速度要快。


思考

这种需要在业务系统中属于比较常见的类型,首先我们能想到的是编写一个插入和一个更新的操作方法,在接收到请求的数据列表后,循环该数据列表,在入库前,先根据主键查询一下,若不存在,则执行插入动作;若存在,则执行更新操作。

那么问题来了,如果按以上逻辑实现的话,可以想象一下,若该接口传输的数据量比较大,我们的性能可想而知,由于每条数据在插入或更新前,都需要先查询一下,数据量大的话,频繁的建立数据库连接和查询,对性能一定是有很大影响的。那么,我们有没有什么方法能够提高一下效率呢?答案是肯定有的。

数据准备

为了方便演示,我们先创建一个数据库test,再创建一张表students,表结构如下:

mybatis批量更新数据(MyBatis实现批量插入或更新功能方案)(1)

建表语句如下:

CREATE TABLE `students` (
  `id_card` varchar(18) NOT NULL COMMENT '身份证号',
  `name` varchar(20) DEFAULT NULL COMMENT '姓名',
  `sex` char(1) DEFAULT NULL COMMENT '姓别',
  `class` varchar(32) DEFAULT NULL COMMENT '班级',
  PRIMARY KEY (`id_card`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

解决方案

由于我们需要执行插入或删除操作,因此,这两个操作能不能合并成一条SQL语句,我们只需要编写一个插入或更新的方法呢?

答案是肯定的,MySQL中的”ON DUPLICATE KEY UPDATE“语法能满足我们的需求,如果在INSERT语句末尾指定了ON DUPLICATE KEY UPDATE,并且插入行后会导致在一个UNIQUE索引或PRIMARY KEY中出现重复值,则在出现重复值的行执行UPDATE;如果不会导致唯一值列重复的问题,则插入新行。

注意:ON DUPLICATE KEY UPDATE只是MySQL的特有语法,并不是SQL标准语法!

因此,编写一个批量插入或更新方法insertOrUpdate(),我们只需要在接收到请求的数据列表后,组装成一个List对象,再循环该对象做相应的查询判断逻辑操作,组装成一个新的List,调用批量执行插入或更新的方法即可满足我们的业务需求。

insertOrUpdate()方法MyBatis动态语句参考

<update id="insertOrUpdate" parameterType="java.util.List">
	insert into students(id_card,name,sex,class)
	values
	<foreach close="" collection="list" index="index" item="item"
		open="" separator=",">
		(
		  #{item.idCard},
		  #{item.name},
		  #{item.sex},
		  #{item.class}
		  )
	</foreach>
	ON DUPLICATE KEY UPDATE			
	id_card = values(idCard),
	name = values(name),
	sex = values(sex), 
	class = values(class)		    
</update>

方案一虽然解决了批量执行插入或更新的问题,但是仍然没有解决性能问题,如果数据量大的话,批量插入或更新方法insertOrUpdate()动态SQL语句会十分长;另外依然需要循环查询数据记录做逻辑判断。那么我们该如何解决动态SQL语句长的问题呢?

根据实际经验,如果请求接口数据量大于1000条的话,执行速度会相当慢,估计需要耗时10多秒,这样的速度客户是无法忍受的。那么该如何优化呢?我们可不可以将数据进行分页,每页数据指定大小,比如100条数据执行一下insertOrUpdate()呢?答案是肯定的,如果按分页思想进行批量插入或更新的话,性能可以提高到50%左右。

虽然方案二已经使性能有了很大的提高,但是还是不能满足现有业务的要求,我们还能不能再缩短一些呢?答案是肯定的,我们只需要在方案二的基础上,把循环查询数据记录做逻辑判断这一部分进行优化即可,只要我们可以让数据一次性查询出来存放在内存中,而不需要每次都连数据库查询,基于这个思想,我们是不是又能更进一步呢?

结尾

经过我们层层思考,我们的方案三是最优的,性能也是最佳的,好了,我就讲解到这里了。