为了解决count查询慢而写的分页查询总量缓存器

最新推荐文章于 2025-06-27 16:32:43 发布

原创

最新推荐文章于 2025-06-27 16:32:43 发布 · 1.2k 阅读

CC 4.0 BY-SA版权

文章标签：

项目上出现了分页查询接口慢的问题，慢的原因是表数据量大，count查询很慢。

分页查询接口有两次查询：

一次查分页数据，比如15条：

sql
复制代码

SELECT * FROM sys_user LIMIT 1,15;

另一次查数据总量：


sql
复制代码

SELECT COUNT(*) FROM sys_user;

count查询需要一行行读数据，累加起来得到总量，效率很低。

要解决count查询慢问题，一般有以下几种方案：

优化count查询语句，走索引、减少JOIN表

一行语句，没有可优化空间，pass。
分页接口的两次查询用多线程同时进行，节省一点时间

查询LIMIT分页数据，靠前的数据一般都不慢，多线程增加代码复杂性，而且目前的问题是count耗时长，所以该方案也pass。
第一次查询后缓存起来，设置一个合适的过期时间，缓存期间可以快速响应

简单可行，缺点是数据实时性不高，新增、删除的数量短期内不会更新，不适合用在高实时性的场景下。
使用EXPLAIN获取的预估行数

响应快，其原理是根据数据总大小和采样的行数据大小做计算得出的预估行数，这是一个近似值，不适合要求高精确度的场景。
转移数据到其他查询快的数据库，如Elasticsearch、ClickHouse

既然MySQL不中用，那就换其他的存储引擎，虽然解决了查询慢的问题，但是工作量激增。