基于mysql实现分页查询并返回符合条件数据数量的方式性能比较
前情提要
-
作为一名前端,我们不光要会写页面,调接口,有的时候我们还需要使用node的相关框架来给项目写一些接口。作为最常见的列表接口,相信大家都不陌生,毕竟这是最常用到了。
-
普通的列表接口一般具有条件搜索,分页等。而作为分页,作为像java这样的老大哥,生态很全,一般框架都会帮你做好分页查询,不需要自己多做什么。
-
而作为新生儿Nodejs,虽然也有些框架可用,但是我还是更倾向于自己写sql语句,而这是个时候遇到了一个问题:就是在进行列表查询的时候,通常我们需要把符合条件的数据的条数一起返给前端。
-
经过不懈的努力找到了两种方案
- 一种是查询分页数据之后,再执行一条查询所有满足条件的语句,然后获得总数。一共需要执行两次sql语句。
- 一种是通过SQL_CALC_FOUND_ROWS复杂查询,同时获取分页数据和总数。有两条语句,但是实际只有一条执行。
解决方案的比较
我在Navicat Premium工具上分别使用两种语句对1k、10k、100k、1000k、10000k的数据量进行测试。
-
第一种语句模板是:select * from xxx limit 1,1000;select COUNT(*) from xxx;
-
第二种语句模板是:select SQL_CALC_FOUND_ROWS * from xxx;select FOUND_ROWS() total;
-
注:上面的举例只是普通的查询语句,如果用到了连表,多表查询等,可自行更改。
-
单纯的使用工具进行查询,查询的sql语句为连表查询:结果如下
- 1k数据:
-
第一种方案的结果:
-
第二种方案的结果:
-
- 10k数据:
-
第一种方案:
-
第二种方案:
-
- 100k数据
- 第一种方案:
- 第二种方案:
- 第一种方案:
- 1000k数据
- 第一种解决方案:
- 第二种解决方案:
- 第一种解决方案:
- 10000k数据
- 第一种解决方案
- 第二种解决方案:
- 第一种解决方案
- 1k数据:
-
总结:根据以上的结果可以看出来,在不考虑实际后端对数据库的具体连接方式下,复杂查询也就是第一条查询的方法在用时上是非复杂查询耗时的好几倍。
总结
- 机型:MacBook pro m1pro芯片,10核中央处理器,16G内存。
- 以上实验在生成数据的时候使用的npm-mysql的包来连接的数据库,并插入数据。连接方法采用的是连接池。
- 之后会结合mysql包,和mysql2包以及真实node连接数据查询的两种方式做对比。
- 以上实验数据不足以以偏概全,但也具有参考价值。其他同学如果有什么建议欢迎踊跃发言。
- 希望评论区是平和的技术交流,如果带有浓厚个人负面情绪的言论将会被删除。
转载自:https://juejin.cn/post/7089451049202745374