如何线性增强MYSQL性能

说到增强mysql性能，大家都会想到一系列的优化方法，但如何做才能线性的增强mysql的性能呢，在多投入一台服务器后，能否取得新增一台服务器带来的性能叠加而不打折扣呢。

我们的目的是化繁为简，去伪存真，在为数众多的优化方法中提取出那些真正能够线性提升mysql性能的方法，先列出几个非常常见的优化方法，然后我们再去分析，这些方法在性能提升方面能带来多少助力，这个投入收益比有多大。

1. 分区表
2. 分库分表
3. 分布式部署

这三种方式是比较通用的常用优化方式，从实现的难易程度上从易到难的顺序是：1<3<=2，第一种方式的实现是最容易的，代码的变动理论上讲也是最少的，但却是最不推荐的优化方式，留着它在列表中，仅仅是为了说明这个功能是存在的，因为分区表有诸多限制，比起使用这种方式带来的助力，分区表带来的麻烦更让人难受。

1. 分区表，分区键设计不太灵活，如果不走分区键，很容易出现全表锁
2. 一旦数据量和并发量上来，如果在分区表实施关联，就是一个灾难
3. 分区表，研发写了一个sql，都不确定mysql是怎么玩的，不太可控
4. 运维方面限制增多，一不小心就会因为使用了分区表踩坑

剩下的两种方式从部署和实现的难易程度上讲差别不是很大，从运维的角度上讲，分布式集群部署的确省心，横向扩展也比较容易，对研发来讲，对代码几乎没有什么影响，这也是分布式数据库在过去的一段时间拥护者和热度很高的主要原因，因为大家都懒，能不出问题，又不会带来工作量的增加，当然最符合人性。但这种方式带来的硬件投入和性能收益比例是打了很多折扣的，部署一个分布式集群动辄就要投入十台左右的服务器，带来的性能提升可能只是单机性能的3倍左右，这还是平均的性能提升，如果具体到某些复杂的查询，这样部署后，性能是否提升就未必一定是正向的了，分布式集群化的部署，会带来很大的内耗，虽然大家都在试图使用更好的算法，但这个内耗是无法避免的，近300%的服务器硬件投入，只能带来可能不到100%的性能提升，这是分布式集群不可避免的性能损耗，随着节点的增多，这个损耗的比例会越来越大，所以，我们会发现，所有的集群部署都是理论上无限美好，而实用中，总是和理想相差很远，因为机器总是笨手笨脚的干活，它们不懂业务，做不到贴近业务的资源倾斜，这就不可避免的会导致资源浪费，好钢没能都用在刀刃上。分布式集群还在进化升级，为的就是提升在资源分配上的可控性，增强人工干预，但这就不可避免的带来集群控制的复杂度上升了至少2个维度，使用这个集群，就会被这个集群特有的技术绑定，这样的集群还有人愿意用吗。所以，分布式部署这条路并不是像看起来那样美好。

说了这么多，该我们的重头戏上场了，除了上面的两个选择，我们还有第三个选择，那就是分库分表，这个方式看起来很笨拙，但却是解决性能瓶颈的终极武器：

1. 没有分区表的各种限制
2. 在业务层实现分库支持，不再依赖分布式和数据库的内部运算，避免了性能损耗，保证了数据库只干数据库的事
3. 对DBA来说，不必关心业务细节，做好库的优化就能带来业务上的助力
4. 对开发来说自己分库分表，自己掌控业务场景与访问模式，可控。

分库分表能够实现线性的性能提升，更能解放DBA和运维的手脚，只要做好了解耦，分库分表就很容易；解耦不只是程序开发者的专利，在数据库的层面也有重要意义。