81、案例实战:陌生人设计APP的MySQL索引设计实战(一)
00 分钟
2022-8-26

81、案例实战:陌生人设计APP的MySQL索引设计实战(一)

从现在开始,我们将会用4篇文章给大家介绍一些MySQL索引设计的实战案例,本来是想要用电商系统的场景给大家介绍索引设计的,但是在整理笔记的时候发现,电商场景的业务是在是太复杂了,可能要把电商的业务讲清楚都需要很大的篇幅,所以决定采取相对较为独立和简单一些的业务场景来讲解案例。
因此首先打算用之前协助过一个朋友的公司项目做过的MySQL索引设计案例来讲解,朋友的公司是做一个陌生人社交APP的,这个业务场景相对较为简单,大家一听就懂是怎么回事,而且这里设计索引页有很多讲究。
首先不知道大家玩过陌生人社交APP没有,相信一些非单身的朋友可能玩的比较少,但是很多单身的年轻人可能都会去玩儿这类的APP,他本身的核心主旨,其实就是你进入APP的时候,需要录入一系列的你的个人信息。
接着APP自己会通过一定的算法推荐一些可能适合你的人给你进行线上交友,当然也有可能是你自己通过一定的条件去搜索和筛选,查找APP上的哪些用户可能比较符合你的期望,你希望去跟对方进行交友。
这里我们忽略掉APP基于算法自动推荐潜在感兴趣的好友给你的部分,就来看看那你通过一系列的条件去筛选一些好友的过程。
我们来思考一下,在你筛选的时候,是针对社交APP在哪个表进行查询?
明显是用户信息表吧,我们可以叫做user_info这么一个表。
那这个表里往往会具备哪些用户的个人信息呢?
大致会包含你的地区(你在哪个省份、哪个城市,这个很关键,否则不在一个城市,可能线上聊的好,线下见面的机会都没有),性别、年龄、身高、体重、兴趣爱好、性格特点、还有照片,当然肯定还有最近一次在线时间(否则半年都不上线APP了,你把他搜出来干什么呢?)
另外如果支持交友过程中让其他人对他进行评价,那么可能还需要包含这个人的一个综合评分。
针对这个用户表进行搜索,可不仅仅是筛选那么简单的,因为你想一下,你除了select xx from user_info where xx=xx 有一系列的条件之外,APP肯定得支持分页展示吧?所以肯定还得跟上limit xx,xx的分页语句。
同时,很关键的一点是,你搜索的时候,肯定不是随便胡乱排序的吧,总得根据一定的规则对筛选出来的结果进行一个培训,把最符合你的条件和期望的用户排列在最上面才可以,各位想想是不是?
那么最终你的SQL语句可能是类似于:select xx from user_info where xx=xx order by xx limit xx,xx
所以这里首先就给我们出了一个难题,之前学习索引使用规则的时候,我们都知道,你在where条件里必须是使用联合索引里最左侧开始的连续多个字段进行筛选,然后排序的时候也必须是用联合索引里的最左侧开始的多个连续字段进行排序。
那问题来了,假设你的SQL需要按照年龄进行范围筛选,同时需要按照用户的评分进行排序,类似下面的SQL:select xx from user_info where age between 20 and 25 order by score, 那就有问题了。
假设你就一个联合索引,age在最左侧,那你的where是可以用上索引来筛选的,但是排序是基于score字段,那就不可以用索引了。那假设你针对age和score分别设计了两个索引,但是在你的SQL里假设基于age索引进行了筛选,是没法利用另外一个score索引进行排序的。
所以说,针对这个实际场景,你要明白的第一个难题就是,往往在类似这种SQL里,你的where筛选和order by排序实际上大部分情况下是没法都用到索引的,所谓鱼和熊掌不可兼得,就是这个意思。
那么除此之外,这个业务场景下的查询语句还有哪些索引设计上的难点呢?下次我们继续分析,这是一个综合性的案例,我们会用多篇文章来讲解,但是一旦大家把这个实际业务场景下的索引设计过程中的综合考虑的因素都理解了,那么自己也能很好的设计索引了

评论