一、疑问复现
在实践的软件系统开发环节中，随着经常使用的用户个体越来越多，表数据也会随着期间的推移，单表的数据量会越来越大。
以订单表为例，假设每天的订单量在 4 万左右，那么一个月的订单量就是 120 多万，一年就是 1 多万，随着年数的参与和单日下单量的参与，订单表的数据量会越来越宏大，订复数据的查问不会像最后那样便捷极速，假设查问关键字段没有走索引，会间接影响到用户体验，甚至会影响到服务能否能反常运转！
上方我以某个电商系统的客户表为例，数据库是 Mysql，数据体量在 100 万以上，详细引见分页查问下，不同阶段的查问效率状况（订单表的状况也是相似的，只不过它的数据体量比客户表更大）。
上方咱们一同来测试一下，每次查问客户表时最多前往 100 条数据，不同的起始下，数据库查问功能的差异。
可以十清楚晰的看出，随着终点位置越大，分页查问效率成倍的降低，当终点位置在 1000000 以上的时刻，关于百万级数据体量的单表，查问耗时基本上以秒为单位。
而理想上，普通查问耗时超越 1 秒的 SQL 都被称为慢 SQL，有的公司运维组要求的或许愈加严厉，比如小编我所在的公司，假设 SQL 的口头耗时超越 0.2s，也被称为慢 SQL，必需在限定的期间内尽快优化，不然或许会影响服务的反常运转和用户体验。
关于千万级的单表数据查问，小编我刚刚也经常使用了一下分页查问，终点位置在 10000000，也截图给大家看看，查问耗时结果：39 秒！
没有接触过这么大数据体量的同窗，或许多少对这种查问结果会感到吃惊，理想上，这还只是数据库层面的耗时，还没有算后端服务的处置链路期间，以及前往给前端的数据渲染期间，以百万级的单表查问为例，假设数据库查问耗时 1 秒，再经事先端的数据封装处置，前端的数据渲染处置，以及网络传输期间，没无心外的状况下，差不多在 3～4 秒之间，或许有些同窗对这个恳求时长数值还不太敏感。
据互联网软件用户体验报告，当平均恳求耗时在1秒之内，用户体验是最佳的，此时的软件也是用户留存度最高的；2 秒之内，还勉强过的去，用户能接受；当超越 3 秒，体验会稍差；超越 5 秒，基本上会卸载软件。
有的公司为了优化用户体验，会严厉控制恳求时长，当恳求时长超越 3 秒，智能丢弃恳求，从而倒逼技术优化调整 SQL 语句查问逻辑，甚至调整后端全体架构，比如引入缓存两边件 redis，搜查引擎 elasticSearch 等等。
继续回到咱们本文所须要讨论的疑问，当单表数据量抵达百万级的时刻，查问效率急剧降低，如何优化优化呢？
二、处置打算
上方咱们一同来看看详细的处置方法。
2.1、打算一：查问的时刻，只前往主键 ID
咱们继续回到上文给大家引见的客户表查问，将select *改成select id，简化前往的字段，咱们再来观察一下查问耗时。
可以很明晰的看到，经过简化前往的字段，可以很清楚的成倍优化查问效率。
实践的操作思绪就是先经过火页查问满足条件的主键 ID，而后经过主键 ID 查问局部数据，可以清楚优化查问效果。
-- 先分页查问满足条件的主键ID id bizuser id -- 再经过火页查问前往的ID，批量查问数据 bizuser id 2.2、打算二：查问的时刻，经过主键 ID 过滤
这种打算有一个要求就是主键ID，必需是数字类型，通常的思绪就是取上一次性查问结果的 ID 最大值，作为过滤条件，而且排序字段必需是主键 ID，不然分页排序顺序会杂乱。
可以很明晰的看到，带上主键 ID 作为过滤条件，查问功能十分的稳固，基本上在20 ms内可以前往。
这种打算还是十分可行的，假设业务对排序要求不多，可以驳回这种打算，功能也十分杠！
但是假设业务对排序有要求，比如经过客户最后修正期间、客户最后下单期间、客户最后下单金额等字段来排序，那么上方引见的【打算一】，比【打算二】查问效率更高！
2.3、打算三：驳回 elasticSearch 作为搜查引擎
当数据量越来越大的时刻，尤其是产生分库分表的数据库，以上经过主键 ID 启动过滤查问，效果或许会不尽人意，例如订复数据的查问，这个时刻比拟好的处置方法就是将订复数据存储到 elasticSearch 中，经过 elasticSearch 成功极速分页和搜查，效果优化也是十分清楚。
关于 elasticSearch 的玩法，之前有给大家引见过详细的通常，这里不在过多撰书。
三、小结
不知道大家有没有发现，上文中引见的表主键 ID 都是数值类型的，之所以驳回数字类型作为主键，是由于数字类型的字段能很好的启动排序。
但假设表的主键 ID 是字符串类型，比如 uuid 这种，就没方法成功这种排序个性，而且搜查功能也十分差，因此不倡导大家驳回 uuid 作为主键ID，详细的数值类型主键 ID 的生成打算有很多种，比如自增、雪花算法等等，都能很好的满足咱们的需求。