优化接口性能从平均2.3秒降到0.278秒_selectbyexample 很慢-CSDN博客

本文链接：https://blog.csdn.net/fengzyf/article/details/123120096

背景
优化方案一：CompletableFuture 两个任务异步执行查询
优化方案二：手动写sql, * 变具体字段，字段加索引
总结

【背景】
无分页全量查询一张3000多条的单张表。以供前端使用下拉。
基于这样的需求，直接首先很简单粗暴的用的mybatis selectByExample查询。结果发现速度很慢，接口平均耗时，2秒多。明显感觉迟钝。以下是自己优化的的整个过程

【优化方案一】单线程变多线程查询，使用CompletableFuture 两个任务异步执行查询

	public static AtomicInteger pageNum = new AtomicInteger(0);
	private static final int PAGESIZE = 2000;

public List<PetHospitalCodeDicRes> queryList(String keyword) {
		pageNum = new AtomicInteger(0);
		PetHospitalCodeDicExample example = new PetHospitalCodeDicExample();
		if (StringUtils.isNotEmpty(keyword)) {
			keyword = new StringBuilder().append("%").append(keyword).append("%").toString();
			example.or().andPetHospitalNameEqualTo(keyword);
		}
		List<PetHospitalCodeDic> list = new CopyOnWriteArrayList<>();
		List<CompletableFuture<List<PetHospitalCodeDic>>> taskList = new ArrayList<>();
		for (int i = 0; i <2 ; i++) {
			CompletableFuture<List<PetHospitalCodeDic>> taskFuture = CompletableFuture.supplyAsync( () -> selectDB(example) , POOL);
			taskList.add(taskFuture);
		}
		//让所有的job执行执行完成
		CompletableFuture.allOf(taskList.toArray(new CompletableFuture[taskList.size()])).join();
		//收集所有task
		taskList.forEach(x ->  x.thenAccept(list::addAll));
		System.out.println("【查询总数：  】" + list.size());

//    if (CollectionUtils.isNotEmpty(list)){
//       res = mapperFactory.getMapperFacade().mapAsList(list, PetHospitalCodeDicRes.class);
//    }
		return null;
	}

private List<PetHospitalCodeDic> selectDB(PetHospitalCodeDicExample example) {
		System.out.println("当前现成是否是守护现成：   " + Thread.currentThread().isDaemon());
		PageHelper.startPage(pageNum.incrementAndGet(), PAGESIZE);
		List<PetHospitalCodeDic> tempReList = petHospitalCodeDicMapper.selectByExample(example);
		PageInfo<PetHospitalCodeDic> petHospitalCodeDicPageInfo = new PageInfo<>(tempReList);
		return tempReList;
	}

结果一样的耗时，甚至花费时间更久
在这里插入图片描述

单线程变双线程，仍然一样耗时，相当于耗时的地方不在这里，应该就是单次查询时间就慢造成的。然后实施方案2

【优化方案二】手动写sql,select * 改成具体字段，具体字段加索引
很明显，速度一下就上来了，如果再遇到条件查询（条件上已加索引）查询，那就更快了，那么到这里，问题也就解决了。
在这里插入图片描述
【总结】
引发的思考一：多线程的应用场景是什么？
引发思考二：接口优化思路的套路是什么？
引发思考三：为什么在数据量小的情况下，多线程反而可能更耗时？

首先多线程应用在，获取资源比较耗时的，且cpu切换上下文的开销，要远远小于资环的耗时，那么用多线程并发处理会提升性能。 3000多条数据的查询，两个线程执行的速度和一个线程执行的速度相当甚至更多，这时候，就要赶紧要知道，耗时不在这里，赶快去找数据库的原因了

接口优化思路，通过打印耗时日志来看，具体是java业务或者算法处理慢，还是数据库操作慢，一分为二，先判断，是sql 就优化sql, 是业务处理，就优化业务逻辑。sql慢，也可以通过业务处理，比如多线程，并发查询。就像今天的问题，自己应该先优化sql, sql 优化不了，再进行多线程优化，这才是一个正确的逻辑。

最后这个问题，我觉的他不是数据量的问题，因为通过select * 查全表， sql 里执行，的确就是慢，每次的查询时， 1秒到3秒的耗时都有发生。那查询速度慢的这个问题，通过多线程查询，为什么没有降低时间呢？自己又想，通过limit sql查询，缩小范围的确是速度快了，那通过两个线程，同时分段查询，那耗时应该接近一次limit的时间才对，结果却相反，到底是什么因素影响了？

在这里插入图片描述