业务优化不是一步到位的

准备

在项目开始的时候为了能快速的迭代开发，基本上字段都是添加在一个表上。下面我们以一个商品表为例来说明业务的变化和数据库的优化。

当然对于真正的需求商品表的字段是不可能那么少的，这边只列出一些代表性的字段进行说明/实验。

造一些模拟数据(这些数据有些不准确，但不影响):

简单数据查询和展示

这时候一般都会有展示商品列表，并且需要进行分页的需求。这对于开发来说可谓是相当简单就一个 LIMIT 基本就能搞定。
如下显示(这边就以数据库命令行简陋的输出来代替前台页面的展示):

表字段分类

上面的商品数据可以分为两类

第一类：基本属于静态的。如：name、price。

第二类：数据进场发生改变并带有一些统计意义的。如：inventory、sales_num、sales_amount。

注意：其实 inventory 这个字段应该属于另外一类。这边就不计较那么多。

引入缓存

由于业务发展，架构的改变开始引入了缓存(redis/memcache)，一般情况下会把商家的基本信息存放在缓存中。

这时候如果将商品的所有信息都放入缓存，由于那些实时统计的字段会影响到缓存的使用效率。这时候就应该把字段(inventory、sales_num、sales_amount)拆分到另外一张表中
当然将这种频繁更新的字段和静态字段分库不仅仅是为了提高缓存的利用率，也是为了将操作 MySQL 表的资源经常分散，从而降低某一张表资源挣用过热现象。
这时候就增加了一张统计表：

修改代买满足商品列表业务

这时候开发只需要做一个表连接 + LIMIT 一般就可以满足展现商品列表并且分页的需求。
SQL如下：

可以看到完成这个列表展示也是十分的简单。

小插曲:

上面的商品字段的划分有经验的人一眼其实就能判断出是否需要进行分表。有时候也会碰到一些不起眼的字段其实修改的也是很频繁的。这时候就不能凭靠自己的感觉来做事了，这时候就需要用数据说话了。需要计算出表中的那些字段修改的比较多。

那要如何计算出那些字段修改的频繁呢，这边有两个工具可以帮到你：

第一个是wubx大神写的：https://github.com/wubx/mysql-binlog-statistic

第二个是笔者写的：https://github.com/daiguadaidai/mysql_binlog_stat

具体如何使用都有说明。

业务又进一步发展了

由于业务的发展，一些基本的功能不能满足。为了然产品不单调，开始有了各种统计/报表。这时候什么实时计算，离线统计等等架构都慢慢的搭建了起来。
这时候开始区分一般型业务和统计型业务。为了迎合业务的在数据库设计方面也会分成统计库和基本库。
这时候的 goods、goods_stat这两个表就不在同一个库，或不在同一个实例上了。这时候对于开发来说就不能使用JOIN了。这时候就需要根据需求进行分开查询了。这也是开发很不愿意的地方，因为需要增加比较多的工作量。

异步请求的引入

使用前台Ajax或其他异步请求技术来完成对数据进行多次查询。(下面我以Ajax技术来说明)

第一步：查询出基本数据并且完成分页。语句如下：

第二步：在前台页面先展示的就只有这些基本的数据。这时候需要通过Jquery技术获取每一个goods_id的值并且将数据异步发送到后端获取相关商品的统计数据。

最终获取的数据的SQL如下(这边以goods_id=1为例)：

第三步：获取到某一个商品的统计数据并且传输到了前端，之后前端通过JQuery技术就能将统计数据和基本数据拼凑在一起。

如下展示(发起一个异步请求拼凑情况):

所以前台如果需要完整的展现出说有的商品统计信息就需要发起 10 个异步请求，并获取数据在前台展现。
最终拼凑出完整数据如下显示：

从上面可以看到我们为了获取完整的商品列表数据总共需要花11个对应用服务器或数据库的请求(1基本信息 + 10统计信息)。
如果我们的请求并发极限在2000左右那么现在只能有 182 用户同时访问商品列表(2000 / 11)。
这时候就需要考虑如何增加用户并数。

合并请求，提高用户并发数

第一步(和之前一样)：查询出基本数据并且完成分页。语句如下：

第二步：使用JQuery技术收集所有goods_id，并且一次性将这些goods_id传入到后台获取商品统计数据

最终获取的数据的SQL如下：

第三步：在前端通过JQuery技术将获得的数据进行循环拼凑。最终获得如下效果：

通过上面的将请求合并我们发现原来的 11个请求就变为了 2个请求这时候我们的 用户并发就变成了 1000 比原来提高了5倍多。

注意:在第二步上我多获取了一个 goods_id 主要是为了在前端能找到相关的拼凑元素的位置(会一点开发的一般都明白)。

需求还没有完

这时候需求又增加了，商品列表需要有排序功能。可以通过 inventory、sales_num、sales_amount分别排序。

这样对原来获取数据的步骤就不一样了(这边以inventory排序为例)：

第一步：获取商品统计表信息并且对inventory进行排序。

SQL如下：

第二步：使用JQuery技术收集所有goods_id，并且一次性将这些goods_id传入到后台获取商品基本信息。

最终获取的数据的SQL如下：

第三步：在前端通过JQuery技术将获得的数据进行循环拼凑。最终获得如下效果：

如果需要对sales_num、sales_amount进行排序展现，方法是一样的。

需求是不断的

这时候业务方又要求说需要按 inventory、sales_num、sales_amount。这时候我生气了。用户确实有这样的需求吗？这样的需求多吗？一般只要单个查询就能满足80%的人的要求了吧。吧啦吧啦开始对撕了。