尽管scale-out(向外扩展)是当前非常流行的MySQL扩展方式，有趣的是在以下的条件下，scale up(向上扩展)也是不错的选择-廉价的内存，快速的存储设备，更高的用电效率。我现在每周都能遇到一个使用Fusion-IO设备的客户。我曾经见过的最有趣的选择是，在系统仍有很多可用的read资源的时候去购买一块SSD——-如果是我的话，我宁愿去购买内存，而将存储设备提供给写操作。

　　以下是我的benchmark:

　　Percona-XtraDB-9.1 release

　　Sysbench OLTP workload with 80 million rows (about 18GB worth of data+indexes)

　　XFS Filesystem mounted with nobarrier option.

　　Tests run with:

　　RAID10 with BBU over 8 disks

　　Intel SSD X25-E 32GB

　　FusionIO 320GB MLC

　　对每一个测试用例，分别使用从2G 到 22G的buffer pool (以此模拟数据大小跟内存可用大小之间的差异).

　　硬件是 Dell 900.

　　首先，我们使用在RAID10上做的测作为一个基准. Y轴上transactions/second (越多越好), X轴上innodb_buffer_pool_size的大小:

　　

　　让我指出这个图有趣的几个特点:

　　A箭头所指的地方就是内存可以装下全部数据的时候，这个时候性能最好。很重要的事，一旦你达到这个点，你完全不需要增加内存。

　　B箭头所指的地方就是数据大小刚刚超过buffer pool的时候.这对大部分用户来说是最痛苦的-因为此时内存下降哪怕10%(即数据大小超过内存10%)性能将下降2.6倍。在线上应用中，最符合这一点的就是”上周一切都运行良好，但现在越来越慢”.这种情况我觉得增加内存是目前最好的办法。

　　C箭头所指的地方就是数据大概是buffer pool的3倍，这时你增加内存可能不是一个好办法，可能SSD才更加适合，请看下图：

　　

　　在上面所说到的C箭头所指的地方(即数据是内存的三倍大), 在这个图中Fusion-IO提高了大概5倍的性能 ( Intel SSD提高了2倍). 如果使用内存来提高性能，你需要增加60%的内存来达到2倍当前性能的提升，或者增加260%的内存来达到5倍当前性能的提升，设想一下当你达到C箭头这个地方，你的内存是32G而数据是100G，那么现在就很有趣了:

　　你能再往机器上添加一个32G的内存吗(内存槽够用不?)

　　你的预算允许装载SSD吗?(因为你很可能会需要不止一块SSD，很多人都使用了8块SSD).

　　2倍或者5倍的性能提升有用么?.

　　这里我们保持尽可能多热数据，但是可能我们这里讨论的更多的是不要低估了你的活跃数据量，因为很可能它比你的预期要多很多。

　　注意：这里的测试仅仅表现了趋势，具体的各个点的细节会和你的机器有关.

　　下面是我的测试结果:

Buffer pool, GB	FusionIO	Intel SSD	RAID 10
2	450.3	186.33	80.67
4	538.19	230.35	99.73
6	608.15	268.18	121.71
8	679.44	324.03	201.74
10	769.44	407.56	252.84
12	855.89	511.49	324.38
14	976.74	664.38	429.15
16	1127.23	836.17	579.29
18	1471.98	1236.9	934.78
20	2536.16	2485.63	2486.88
22	2433.13	2492.06	2448.88