突破数据库瓶颈
在网站发展过程中，随着访问量的不断增加，业务逻辑的复杂度的增长，数据库的通常会成为瓶颈，制约着并发量的增长。如何提升数据库的效率与并发量成为重要课题。
在我们添加索引，采用存储过程，优化SQL语句这些之外我们还能做些什么呢？
如上图所示，根据业务拆分数据库，比如拆分成用户库，产品库，订单库，评论库等，每部分数据间的关联其实并不大，拆分后对业务逻辑的清晰度会有更一步的体现，如果再配合上SOA架构，一份逻辑接口对应一个数据库，那将会提供一个非常清晰的数据逻辑，防止每个前段系统都与部分甚至所有数据库都有访问关联，对问题的查找与数据管理提供极大便利。经过拆分，数据库的承载能力在理论情况下有了*拆分个数倍的提升。
在拆分后，并发量有了一定的提升，随着数据表中数据量的不断增长，我们又将面临查询速度变慢的问题，通常来说在MS SQL中单表数据达到50W以上查询效率将极大的下降。此时我们需要做的工作将非常明确，将单表拆分成多表。此时的拆分方式可有多种，如根据用户段拆分，将1-10000的userid的数据存放在product_0中，10000-20000的userid的数据存放于product_0中….；根据productid拆分，对productid取模，如取模后为0则存放于product_0，为1存放于prodcut_1…；建立一个DB，这个DB单独保存user_id到DB的映射关系，每次访问数据库的时候都要先查询一次这个数据库，以得到具体的DB信息，然后才能进行我们需要的查询操作。以上方式各有利弊，需根据业务场景具体选择。
数据库访问越来越频繁，压力继续增长，此时我们必须继续进行拆分以满足业务需求。在数据库访问中，只有少部分是进行的写操作，大部分是对数据的读取。我们可以根据此特性将数据库的读写分离出来，DB_Prodct_Write专门用来写入数据，而DB_Product_Read1,DB_Prodct_Read2…从写库中订阅数据用于查询操作，此时可订立策略如随机访问数据库，也可指定某个只读库为某项业务专用等。由于数据库的复制延迟，最新的数据有可能会访问不到，大部分的应用场景对数据的实时性要求并不会要求达到插入即显示的效果，如果实时性要求特别高，那么通常对此的解决策略是数据配合缓存一起，最新插入数据同时缓存起来，读数据的时候读库配合缓存一起。
在某些场景下读操作也会相当的频繁，比如论坛，此时我们对写库也需进行进一步拆分，如上图所示。安装表拆分相似逻辑拆分成多个写库，进一步提升写库的并发能力，然后将写库中的数据通过服务或其他方式同步到总库中，读库从总库中进行订阅获取完整的此部分数据。
在各种策略应用的同时，我们应该认识到数据库的本职工作---保存数据。在大数据量情况下不论你是建立索引优化存储过程优化查询语句，在做模糊匹配分页数据查询等场景时还是有可能会遇到查询缓慢的问题，这些问题的解决并非继续挖掘数据库的潜力能够解决，如果我们理解了数据库是用来干嘛的，也许就没有这许多烦恼，这诸多的问题其实在数据已经保存的情况下都不是问题，数据处理的方式多种多样，我们应该选择合适的工具去完成合适的事，比如模糊匹配分页这些就应该配合搜索去使用。我们保存在数据库中的数据通常都是原始数据，之后怎么使用应该根据业务需要灵活选择，而非一切都需要通过数据库本身来实现。