今天的话题，要给大家分享的是：百万级数据表分页查询，为什么不是千万，亿级呢，你想啊，单表千万上亿，你不是疯了吗，早就分表了，单表数据量通常都是控制在几百万左右，真正实际项目中，都是百万级数据，维恩老师今天要给大家讲的前提是，项目 redis 缓存策略，架构都搭完了，查询命中了数据库表来查询的情况，如何进行优化，所以我们要搞明白这三个问题：
- 没有百万级以上数据查询分页经验怎么办？
- 提升海量数据查询效率的关键因素？
- 三年工作经验了，如何突破晋升下一阶段？
互联网大厂关于海量数据查询的面试题
互联网大厂必问题 ：通常出现在 阿里/京东 等电商平台面试机率大。
- 百万级数据表分页查询做过吗？
- 你们的查询时间要求是多少？
- 有没有遇到慢查询的情况？
- 你是如何解决的？
注意面试官的预期
面试开始，接招吧
面试官：做过海量数据查询及分页的项目吗？你是怎么优化的？
面试者：是的，在之前的一个项目中的订单业务中涉及到大数据量查询问题
案例场景
1、一个订单业务系统中，在mysql库中订单表（ordertb）500万条记录：
SELECT COUNT(id) FROM ordertb
2、现在的需求是，要筛选：2010全年数据约为200万条，要求分页显示：
大数据量分页查询产生的问题
我们要如何解决这个问题呢？
咱们来讲一讲，建索引的几大原则：
1、最左前缀匹配原则非常重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a =1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。
2、=和in可以乱序比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式。
3、尽量选择区分度高的列作为索引区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条记录。
4、索引列不能参与计算，保持列“干净”比如from_unixtime(create_time) = 2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);
5、尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可。
使用explain查看执行计划
添加索引后的效果
这可咋整？添加了索引的ucreatetime 列相同的数据太多，如下图：
这就要重新分析一下问题了，
1、分页页码越大查询效率越低
2、选择区分度高的列作为索引，否则未索引起反效果
3、需要根据业务场景具体分析，不盲目添加索引
重新分析一下这个问题：
如何解决问题：
把分页限定条件优化为筛选条件，变相降低了分页起始位置。
小结一下
分表后的单表数据量在几百万的情况下，查询优化问题（分页）排查慢查询
咱们要充分理解索引建立的几大原则，然后使用explain查看执行计划，了解慢查询的问题在哪里，这一步是分析问题，再结合业务方面的使用场景，来优化你的SQL语句。
OK，文章最后，威哥想说，经验可以学习，场景来自实际工作，学习Java的路上，咱们一起学习，一起成长！
