读写分离的场景
当数据库系统出现瓶颈时，有很多种优化方式，读写分离只能算是其中的一种，它主要解决的问题是，数据库的读多写少，读请求非常多，但是写请求非常少；为什么呢？我们分几种情况讨论：
读多写少：
1）并发读不需要事务，而写入数据需要事务， 假如写入数据是200ms，而读数据是10ms；1s内如果全是读请求，则可以达到100qps。如果1s内有2个写请求，qps可能就降低到60qps；
2）此种情况下做读写分离，一个主库可以挂多个从库(假如3个)，那么此时1s的并发直接提升到300qps；
写多读少：
1）读写分离是多同mysql实例之间的同步是靠binlog日志的，如果写比较多，也就是同步binlog的次数会比较多，这种情况更容易产生主从延迟问题；
2）即使想对这种情况做读写分离意义不大，因为再怎么分离，接收写请求的实例也只有一台，也提升不了写的并发量，如果做mysql集群实现多主模式，技术挑战可能更大；
数据量多：
表数据单过大，导致查询效果低，此种模式下做读写分离解决不了问题，因为读写分离每张表的内容是一模一样的；此时做sql优化和分库分表的方案可能会更好一些；
————————————————
版权声明：本文为CSDN博主「Louis.No1」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/shixiaoling123/article/details/108975665