一次显著的MySQL大表分页查询优化，从2.35到18ms！

主要观点总结

文章主要介绍了在实际软件系统开发过程中，随着订单表等数据表的数据量增大，查询效率下降的问题。文章以电商系统的客户表为例，详细描述了分页查询下不同阶段的查询效率情况，并提供了三种解决方案来提升查询效率。同时，文章也讨论了主键ID类型选择对查询效率的影响，并推荐了一个开源电商系统项目mall及其视频教程。

关键观点总结

关键观点1: 问题复现

文章首先描述了随着数据表数据量的增长，查询效率下降的问题，以订单表和客户表为例，展示了不同数据量下的查询耗时情况。

关键观点2: 解决方案一：简化返回的字段

通过只返回主键ID而不是所有字段，可以显著成倍提升查询效率。具体操作是先通过分页查询满足条件的主键ID，然后通过主键ID查询部分数据。

关键观点3: 解决方案二：通过主键ID过滤

通过带上主键ID作为过滤条件进行查询，可以显著提升查询性能。这种方案要求主键ID必须是数字类型，且实践思路是取上一次查询结果的ID最大值作为过滤条件。

关键观点4: 解决方案三：采用elasticSearch作为搜索引擎

当数据量继续增大，尤其是出现分库分表的数据库时，可以采用elasticSearch实现快速分页和搜索。文章还提到了不推荐使用uuid作为主键ID，建议使用数值类型的主键ID。

关键观点5: 推荐项目和学习资源

文章最后推荐了一个开源电商系统项目mall及其视频教程，内容涵盖Spring Cloud核心组件、微服务项目实战、Kubernetes容器化部署等。

文章预览

Boot+Cloud项目学习： macrozheng.com 一、问题复现 在实际的软件系统开发过程中，随着使用的用户群体越来越多，表数据也会随着时间的推移，单表的数据量会越来越大。 以订单表为例，假如每天的订单量在 4 万左右，那么一个月的订单量就是 120 多万，一年就是 1400 多万，随着年数的增加和单日下单量的增加，订单表的数据量会越来越庞大， 订单数据的查询不会像最初那样简单快速，如果查询关键字段没有走索引，会直接影响到用户体验，甚至会影响到服务是否能正常运行 ！ 下面我以某个电商系统的 客户表 为例， 数据库是 Mysql，数据体量在 100 万以上，详细介绍分页查询下，不同阶段的查询效率情况 （订单表的情况也是类似的，只不过它的数据体量比客户表更大）。 下面我们一起来测试一下，每次查询客户表时最多返回 100 条数据，不同的起始 ………………………………