列表查询SQL语句改造

一个经常遇到到的场景，就是查询列表数据，列表数据由多张表构成

最简单的查询方法是先写一个查询单条数据的方法，比如这个方法中要查询十张表；

然后一个循环调用查单条的方法，这种逻辑上理解是比较简单的（因为这样不会有比较复杂SQL语句，也不用连表查询，很少会产生慢查询）

但是这里面会产生较多的SQL语句查询，如果一个列表有10条数据，那么产生的SQL查询语句就是 10*10条

 

改造前

 

 

改造后

 

** 两个查询案例非一模一样的场景下产生，只为形象的对比产生的SQL语句数量

 

 通过in查询改造后， 尽量不连表查询，都是通过in查询来解决，即使改造了，一次请求还是有过多的数据表查询，一个请求需要查询10几张表，这个时候就该缓存出场了，缓存能够很好的解决重复查询的困扰，但是又将系统的复杂度提升了一个档次

存入缓存容易，

销毁缓存就变得麻烦了，

个人觉得比较好的使用机制是：

接口层面直接从缓存中拿结构化好的数据，如果拿不到就直接去数据库查询，查回来的数据结构化好返回给用户，顺便把数据通过MQ消息给缓存管理服务，当出现数据变动时，MQ消息通知缓存管理服务直接删掉（或者发送格式化好的数据给MQ直接替换或者更新），但是实现起来需要对接的系统也就多了，缓存想做好还需要下细功夫