要坚持写文，确实是这样。。。
程序员小a：老板，今天交易量上去了，2k多w啊。。。哔哩哔哩
老板：做的不错，年终奖，你懂得。。。
一个月后。。。
客户：怎么网页这么卡，什么垃圾服务
客服：您稍等，我看看（哎呦喂，我操了，真tm卡，赶紧联系技术人员）
程序员小a：哼哧哼哧，哎呦卧槽，数据库一个select卡死了，赶紧各种搜索，请教，寻求大牛。。。
。。。。
最终：老板做出了惊人的行为，关闭网站，停止运营。。。
--------------------------------------------------------------------------------------------------------------------
如上是很多大型网站的初期运营现象，懂点技术的同学们应该有所所耳闻，初期设计和运营主要为了商务发展，技术上忽略了不少关键因素，尤其是web时代，交易量多数为是正切函数
（tan=谈进特，哈哈，喜欢这个读音）走势
那好，问题来了
如何降低数据对数据库的压力？？
常规降低服务器压力，一般有多机负载，水平扩展之类，主要将应用做模块切分，降低耦合度，分布式部署各模块，挂载负载均衡器等，都可以充分做到服务器的压力降低和引流作用；当然细节方法还有很多，也针对各种应用具体场景各有所长，如对静态资源做反向代理，缓存等等，优化业务场景，对于特殊业务场景减少前后端的连接次数等
降低数据库压力，也是本文讨论的重心，分库分表，有垂直切分和水平切分；垂直切分将数据源按照不同的场景做库的隔离，如多租户按照商户号切分、参数数据库、业务数据库切分等，相对而言比较单一；水平切分算是数据库少见的几个大招了，对表做水平分割，将大数据量的单表按照一定的规则（常用的像hash、用户号取模等）拆分成n个小表，但注意的是，不是说拆的越多越好，表多了，查询起来，自然效率也有点降低，且拆分过程中，注意小表归一的原则，毕竟在一张表操作效率高于多张表。
你会如何做
如果确定要分库分表的话，那就考虑下分的规则
1）你的客户是多租户模式么，如果是，你的租户间是否有粘性，如果没有粘性，简单的降压扩容方案就是一个租户一个库，也就是最单一的垂直分库
2）接上个问题，一个租户一个库，是不是有点浪费呢，实际情况中，更多的是1-3号租户交易量都很小，5-9号可能很大，那垂直切分已经不合适了，就得水平切分，将核心的交易数据表，水平拆分，按照日期、流水号等都可以，动态将数据均衡划分到各个库、表中
推荐方案
常用的有drds、mycat等，还有一些开源的产品，对于应用方案，目前正在测试中和应用中性能压测，此块稍后更新
拓展思考
1）真的只有做分库分表才能解决么？
可以先考虑下，数据存量问题，真的需要保留一年访问数据么？？可不可以限制用户访问数据期间呢？是吧，如果限制了用户的访问期间，比如最近3个月，再配合好的数据备份方案、数据缓存方案，是不是不做分库分表也能缓解压力。
