【java】想要限制每次查询的结果集不能超过10000行，该如何实现？

小灰灰 2024-02-17 09:09 4阅读 0赞

#### 文章目录 ####

*  前言

## 前言 ##

对于一些Saas化软件，当某个租户在执行查询SQL时，如果查询条件出现了BUG，导致去查了所有租户的数据，这种情况是非常严重的，此时就需要在架构层面做限制，禁止一些特殊SQL的执行，另外，为了保护数据库，也可能会限制某些查询语句不要查询太多的数据，那么怎样在平台架构层面对业务层的SQL做拦截和校验呢？  
本文分享一下我司的做法。

我们集团里有的项目用的Mybatis，有的项目用的Spring Data JPA，共同点在于都用的Druid连接池，所以可以在Druid层面做SQL的拦截和校验。

Druid提供了FilterEventAdapter机制，可以用来拦截数据库连接的创建、Statement或PreparedStatement的创建、SQL语句的执行等等，我们可以自定义一个FilterEventAdapter：  
![在这里插入图片描述][56f7071a4fa546da94d23584cc28bdf1.png]

其中statementExecuteQueryBefore()方法表示在执行某个查询语句前的拦截点，preparedStatement\_executeQuery()方法表示执行查询语句的地方，比如正常情况下preparedStatement\_executeQuery()方法顺利执行的话就会得到ResultSetProxy，可以理解为就是ResultSet，也就代表查询结果集。  
所以如果我们想做查询语句的拦截，这两个方法都可以做到，回到文章题目：想要限制每次查询的结果集不能超过10000行，该如何实现？我这里给两种不同的实现方式。  
对于某一个查询SQL，我们首先得知道这个SQL将会查出多少条数据，那就得把该查询SQL，比如select a,b,c from t where a=1，改造成为select count(1) from t where a=1，执行改造后的count语句就能知道原始SQL会查出多少条记录了。  
我这里提供一个方法，能够把简单的select语句改造为count语句（原谅我不能把公司内部的代码贴出来~~~）  
![在这里插入图片描述][b4b52bfccd2f41b28afe949204540ce8.png]

然后，我们就能在statementExecuteQueryBefore()方法中做拦截判断了：  
![在这里插入图片描述][4c6e7cfe13704e6ba7a74e284622da25.png]

这种方式的好处是：如果某个查询SQL确实超过限制了，那么就它被拦截了，但是缺点是：如果很多SQL并没有超过限制，那么就多余执行了count语句，降低了性能。  
那么我们来看看第二种方案，这种方法重写的是preparedStatement\_executeQuery方法，思路是：先执行原始SQL，得到ResultSet，然后通过ResultSet来判断结果集是否超过了限制，如果超过了限制则告警，比如代码为：  
![在这里插入图片描述][d30b4c7bdf674e48ae25fa58f895dbad.png]

这种方案和第一种方案的优缺点正好相反，优点是：没有额外执行count语句，缺点是：如果查询语句确实超过了限制只能事后告警了。  
这两种方案似乎鱼和熊掌不可兼得，大家觉得哪个方案更好呢？

[56f7071a4fa546da94d23584cc28bdf1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/7f76e97c91314ebf98f98836c3118502.png
[b4b52bfccd2f41b28afe949204540ce8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/febf05c860a0437fa3a0bc21a8669c1e.png
[4c6e7cfe13704e6ba7a74e284622da25.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/bf86fd1998af4508a754acf737a3261a.png
[d30b4c7bdf674e48ae25fa58f895dbad.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/24ddeb4a4da742eca8c1d71d2f38a138.png