性能优化策略：大数据量实时处理、排序与分页查询的优先级排列解析

大数据量即时计数排序分页检索优化综述

大数据量即时计数排序分页检索（在并发量较低时）的瓶颈不在于函数（如count，sum等）的执行，也不在于having语句，甚至不是order by操作，慢速的根本原因在于“数据量过大本身”。解决方法是将表划分为M个相互独立的部分，可以是分表，也可以是保留一个取模结果的冗余字段。实践表明，不分表的方式比分表更灵活，只需简单配置，即可动态分割大表，随意调整M的大小。

将一条耗时较长的SQL（超过30秒）拆分为N条执行速度极快的SQL（单条SQL执行时间控制在20毫秒以内），然后在Web应用中以适当的线程数并发查询这些快速的小SQL，并汇总结果。第一步查询中并发执行这N条小SQL，仅取排序字段和标识字段，其他字段全部舍弃。汇总结果后，定位出当前页面要显示的pageNum条数据，再进行第二步查询，取出页面上需要展示的所有字段。这一点至关重要，其他几点都可以忽略，这一点是最关键的。下面慢慢解释一下：

a) 第一种方式是将数据库中所有记录（仅取排序字段和标识字段，且不进行sum，count，having，order by等操作）全部拉到Web应用中，在Web应用中完成所有计算。

b) 第二种方式是将数据库中所有记录进行sum，count，having等操作后的所有行数拉到Web应用中，在Web应用中完成剩余计算。

c) 第三种方式是将数据库中所有记录进行sum，count，having，order by等操作后，将limit后的数据拉到Web应用中，在Web应用中对limit后的数据进行再次计算。

显然，第一种方式仅从数据库中提取数据是不可行的。以lg_order_count_seller为例，1500万行数据，如果仅计算id，seller_id和order_count这三个bigint类型，至少需要831500 0000= 360000000=340M的内存，拉到内存中后存储需要841500 0000= 460M，这还不包括List的2的n次方这个特点和计算排序等的内存开销，不仅数据库与Web应用机器的IO承受不住，就是应用自身也可能发生OOM。

第二种方式，所有记录进行sum，count，having等操作后，由于是group by seller_id的，总数据量变为100万（即卖家总数），这样一来，总共需要83100 0000= 23M的内存，拉到内存后，需要84100 0000= 30M，再加上List的2的n次方这个特点和计算排序等的内存开销也不会超过100M，IO的时间和内存开销勉强可以接受。

第三种方式，所有记录进行sum，count，having，order by等操作后，将limit后的数据拉到Web应用中，因为做了limit，所以数据量很小，无论是IO还是内存开销都已经很小，可以忽略。

综合以上三种，第三种方式适用于页面的前n页和后n页，因为这个limit的数据量随着页数的增大而增大，当大到每个切分后的小表的数据量时就转为第二种方式。

第二种方式适用于页面的第[n+1, totaoPageNum-n]页。

将N条小SQL并行执行时解决排序不稳定性的方法

①问题描述：

优化前，还是一条大慢SQL查询时，由于数据库排序是稳定排序，所以当两条记录排序字段值相同时，他们在页面上的页码位置是固定的。优化后，当并行执行这N条小SQL时，由于无法控制这些小SQL的先后执行顺序，导致在Web应用中当两条记录的排序字段值相同时，在页面上的页码位置是随机的。

②解决办法：

除了拉标识字段(seller_id)和排序字段(order_count_sum)之外，再取一个unique（id）的字段，当两条记录的排序字段值相同时，再用这个unique的字段（在卖家监控中这个字段是id）进行第二次排序。这样就解决了排序不稳定的问题。

③也许，看到这里会有疑问，为什么不用seller_id？seller_id也是唯一，这样不是少取id这个字段，减少IO了吗？seller_id虽然也是唯一，可以辅助排序，但是不要忘记数据库的排序规则是：如果两列的值相等，那么序号在前的排在前面，这里的序号就是主键(自动生成，autoincrement)，如果用seller_id的话还是不能保证排序的稳定性，只能用主键id。

优先加载页面上的主要元素，然后再去异步加载次要元素，反映在卖家监控页面中，查数据和查页页码的SQL语句基本相同，是在竞争同一资源，所以需要做一个策略，优先把资源让给查数，数据查完之后再去查页码。

限流

由于多线程取数据并没有从本质上提高数据库性能，所以必须针对大数据量即时计数排序分页检索做限流。我这里打个比方：食堂有6个窗口，物流团队吃饭要买6个菜，平均每买1个菜需要1分钟的时间，如果派我一个人去一个窗口买的话需要6分钟的时间。假如派6个人分别去6个窗口买这6个菜，只需要1分钟的时间。但是，如果除了物流团队，再来其他5个团队呢，也就是说6个团队每个团队买6个菜共买36个菜，这样子有的团队先买完，有的团队后买完，但平均时间还是6分钟。本质上没有变化。所以，对于特定的查询条件，必须进行限流。让每分钟至多有6个团队买菜，这样子能使得情况变得不至于太糟糕。

从根本上改变现状

这一点从目前来看只能是展望了，比如mysql数据库换更为强大的oracle数据库，或更换InnoDb引擎为其他，或更换SATA硬盘为SSD等等。从实践效果来看，优化后的效果是很明显的。相同的查询条件，原来一个页面查询时间由于超过60秒超时了，根据1-6点建议优化之后，查询时间变为2秒至3.5秒之间。

淘宝怎样优化标题关键词如何挑选排序

一个优秀的标题，能为你吸引更多的流量，因此今天我们为大家剖析一下如何挑选关键词？

一、关键词的相关性

关键词的相关性与店铺的精准流量密切相关，我们也深知精准的流量才能带来转化。假设你售卖小风扇，却使用与大风扇相关联的关键词吸引流量，那么进入你店铺的流量将是不精准的，更不用说转化率了。

与产品不相关的关键词选择不仅无法带来流量，还会打乱你店铺中的标签。有时你甚至会受到淘宝的惩罚，简直是得不偿失的典型例子。因此建议各位卖家在选择关键词时，一定要挑选与自己产品相关性高的词汇。

二、关键词与店铺标签相契合

我们挑选关键词也要根据与店铺标签相契合的原则，通过店铺中产品标题中关键词的选择，进一步强化我们的店铺标签。我们向大家推荐一个比较可靠的选择关键词的平台，那就是生意参谋，生意参谋确实非常好用，我们可以在里面找到我们的主要人群的一些特点，然后挑选出相匹配的关键词。

产品关键词的选择最好能与店铺相匹配，并且要根据产品的一些特性，基础的一些信息来作为参考。还需要参考生意参谋上的人群特征看是否匹配，如果满足这些条件的关键词，我们就选用。

三、商城占比

许多人根本没想到商城占比会与标题有什么关系，但实际上商城占比的数据对于我们选择关键词有着非常大的影响。比如以手机为例。

通过图片可以看到，“华为荣耀9”这个关键词商城占比达到90%以上。这意味着这个词的使用流量已经达到了90%以上，几乎就要达到百分之百了。

竞争如此激烈，天猫店可能都没有太多的竞争优势，更不用说普通的淘宝店铺了。商城占比对于我们关键词的选择有很大的影响，希望大家都能引起重视。

四、关键词点击

我们所选择的关键词点击率一定要非常高，因此我们在生意参谋上寻找关键词时，就一定要考虑三个因素：点击率、点击人气、点击热度。这三个指数越高的词汇，证明人们对这个产品的需求越大。

新品想要崛起，仅仅依靠淘宝给我们的那些扶持是不够的。因此我们要抓住每一个机会，让我们的产品尽可能多地展现在买家的面前。

你本身积累了一定的流量之后，淘宝才会给你更多的扶持。虽然主图是决定点击的重要因素，但是关键词也有它特定的效果。因此我们在选择时，也要尽量选择点击率高的关键词。

五、在线商品数与支付转化率

我们可以通过生意参谋来找到在线商品的数量。如果与关键词相关的在线商品的数量比较少，那么你在搜索这个关键词的时候，你的产品展现的机会也就越大，因此在线商品数也可以成为我们选择关键词的一个参考依据。

另外选择关键词的时候，支付转化率一定要高的词汇才可以进入我们的考虑之中。因为支付转化率也基本上等同于我们店铺的成交量，如果一个关键词不能给我们店铺带来成交量，那么选择它将是无用的。