为什么数据库读写分离可以提高性能

为什么数据库读写分离可以提高性能

Mysql的读写分离真的能提高性能吗？
在网上经常看到这样的文章，某某论坛压力太大，于是在后台把mysql服务器分离成两台A、B，A专门做写操作，再通过数据复制把数据写到B，读取数据都来自B很疑惑，除了机器的性能强大和IO能获得一些好处（一台机变两台机）以外，真的能改进性能吗？B机器还照样要写（复制也是写），而且写得一点不少。中间产生的lock也是一样的。复制可以稍微有几秒的不同步时间，感觉就跟采用了低优先级写差不多，差别只是，如果用了低优先级写，在写入的时候网页要停顿一下，现在用了复制，网页不停顿了，但可能再打开的时候发现还没写上（因为可能存在复制时延），其实都是半斤八两了

6 个回复

crazyhadoop
对于很多互联网业务来说，非常有效果，读多写少的场景非常适合。
2013-07-17 10:15
T-Bagwell - What's the fucking is going on?
赞同来自: lingjiujianke
能提高性能读和写之间不互相影响
2013-07-19 10:18
wang290
肯定的，很多场景读写是不均衡的，比如一个视频网站，上传的人毕竟少数啊，看得人多啊，只读操作起来比较读写混在一起容易处理多了。
2013-07-17 10:26

Shell_HAT - Do all in command line
一般来说，是的。减少I/O竞争，提高性能。至于具体在你的环境里面有多大帮助，需要具体的测试。

基本正确，除了读请求和写请求写反了，另外主从库的写是异步的，这也是为什么从库有可能有脏数据（旧数据）的原因。 至于查询的分配，写请求不用说了，都是要给写库的。主要是读请求。 关于读请求，如果你的应用可以接受脏数据，就可以让读库接受所有读请求，否则要通过监控复制延迟来决策读查询分配，举例说如检测到复制落后太多，则读请求分配到写库，如复制无落后或在应用业务接受范围内，则读请求分配给读库。 至于你说的不重要的（可接受脏数据的）读分给读库，重要的（不可接受脏数据的）读分给写库，这种可行性不高，因为大部分应用都不能接受脏数据，那必然大部分读都会分给写库，那这样的话做读写分离意义就不大了。