发现问题在最近进行的项目中，一个功能模块涉及比较大数据量的检索和导出，分别是IMSI数据和MAC数据。 最初使用级联搜索，在搜索字段、搜索条件中使用函数。 例如，如果搜索条件为时间戳，则格式为年和日。 等操作，但随着数据量的增加，搜索效率大幅下降。 因此，我们随后优化了该部分的功能，包括断开查询连接、取消使用函数以及在业务逻辑中设置和设置关系表中的字段和时间格式。
而且导出也是使用EasyExcel进行导出的，所以效率已经很高了。
但是，上周前端要求导出功能的响应时间不超过1分钟，因此经过协商，决定对导出的数据进行最大记录限制。 试验了几次后，最后决定将最大记录数控制在60W。
但是昨天前端再次找到我，说IMSI没有问题，但是MAC的导出超过了响应时间。
在故障排除过程中，我在当地对两个接口进行了响应时间测试，发现在相同的数据量下，MAC的导出速度比IMSI快一点以上。 但其实MAC的查询逻辑比IMSI更简单，真的不知道。 于是，我开始逐行进行响应时间测试。
一开始我以为这是查询效率的问题，但通常是直接运行SQL，或者在工作中中断点来测试SQL查询时间。
然后，如上所述，我们开始在业务中测试相关字段和时间设置的逻辑。 果然，IMSI处理部分即使在60W、进而100W条件下，也能够在几秒以内进行处理； 另一方面，MAC部分即使只有10W，半天也处理不完。
于是我开始在循环中打印对象，并打印了每行处理后的时间。 很明显，你会发现MAC的打印过程非常慢。 每个循环有两个操作。 一个将毫秒值转换为Date，另一个通过设备ID查询数据库以获取设备名称。 在每行后面打印当前时间。 老实说，死马是活马医生，万一发现问题呢？
就像这样
//查询处理逻辑略.//查询listmacvolist=macdatamapper.querymacinfo (MAC search )； //属性(开始遍历)； list.foreach (macvo-{ macvo.setacquisitiontime (new date ) macvo.getreporttime ) ) System.out.println (“采集时间的macvo.set device name (imsisourcedatamapper.getequipmentnamebyid (macvo.getdeviceno () )； System.out.println (设备名称设置成功(System.currentTimeMillis ) )； system.out.println(macvo )； )； 同时IMSI也进行同样的处理，先查他100瓶，看看打印的时间，道理在哪里有问题
果然，没想到我发现了问题！ 两边打印的日志是这样的，左边是IMSI，右边是MAC
正如您所见，每次查询数据库获取设备名称时，IMSI大约需要50毫秒左右的时间，但每次开始查询时，IMSI确实都会每次查询，但稍后遇到重复设备时，它不会查询，而是直接快速获取结果。 MAC端每次都执行查询！
所以，其实是MyBatis的缓存机制的问题！ 一边使用缓存机制，一边没有另一方！
知识补充以下内容来源于网络资料。 (此博客： MyBatis一级缓存、二级缓存详细信息(1) ) )
MyBatis缓存是指，当MyBatis执行一次SQL查询或SQL更新后，该SQL语句缓存在MyBatis中，然后再次执行同一SQL语句，而不是再次执行SQL命令
MyBatis缓存分为一级缓存和二级缓存。 一级缓存也称为SqlSession级缓存，二级缓存也称为表级缓存。
一级缓存是SqlSession级别的缓存。 在处理数据库时，必须生成sqlSession对象。 对象具有存储缓存数据的“内存区域”数据结构“HashMap”。 不同sqlSession之间的缓存数据区域(HashMap )互不影响。 图中显示了每个SqlSession中包含一级缓存对象的一级缓存。
MyBatis二级高速缓存是一种APP应用程序级高速缓存，可提高数据库查询效率并提高APP应用程序的性能。
在解决方案中，为什么在同一个项目中，两边有一个启用了缓存，而一个没有启用呢！
因为缓存基于事务。
所以，解决方法是向MAC查询方追加事务就好了。
@ transactional (roll back for=exception.class ) )
这样，问题就解决了，就像两边的咨询一样迅速了！
这真是个大漏洞，用一个评论解决的问题我排除了很久才找到……但是，顺便详细了解了MyBatis的事务和缓存机制，是一个很好的经验！ 而且，必须合理利用事务！ MAC那边是我以前的同事做的，我接手了。 妹妹也觉得他没有用办公室！ 挖洞！