sql读写分离（数据库读写分离优缺点）

1. 一台服务器，怎么实现数据库的读写分离
2. 数据库读写分离优缺点

一台服务器，怎么实现数据库的读写分离

方法1 ：里面建立两个数据库实例，一个作写，一个作读

方法2:服务器上建两个虚拟机，一个虚拟机放写数据库，一个放读数据库

方法3:服务器上放写数据库，再建一个虚拟机放写数据库

----------------------

实现方法:

数据库之间同步，然后修改代码读写分别指向相应的数据库，就可以了。

数据库读写分离优缺点

在传统的编码的过程中，往往是在数据库由于抗不住服务器的压力，或者是IO达到瓶颈之后，必须用到分库的时候，才采用读写分离的方案，个人认为读写分离的作用远不止此。今天，根据博主我作为程序猿的经验，来和大家分享一下数据库读写分离带来的优点。

一，读写分离带来的扩展性更强

在我们编码的过程中，随着项目的业务增多，必然会致使业务接口越来越多，接口越多，带来的维护成本就相对较高，如果没有对应文档的记录，即使作为研发人员的我们，都很大可能忘记那些接口有那些功能，那些接口被调用过多少次。

以上就很可能带来一个很严重的问题，举例说明：在学校考试成绩管理系统中，我写了100个select接口，10个insert接口，10个update接口，10个delete接口，分别对应不同业务需求，这些接口被调用的次数无限，随着服务器的压力增加，需要对部分查询接口（查询最新的成绩等）进行优化，最开始的常见的查询方式可能是按照直接在数据库中查询时间最新的成绩记录，进行返回，优化的方案为给最新的成绩记录打一个标记。可是，后续的插入，修改，删除接口，都需要更新标记，如此多的接口，在没有文档的情况下，维护起来基本不可能，此时要怎么办呢？

此时都希望，要是所有的插入，修改，删除（即写接口）都可以调用一下我的维护标记接口就好了，对！要是按照读写分离的架构进行设计，我们就可以把我们的维护接口写到写接口里面，这样可以极大简化我们的维护量。

二，读写分离方便管理

按照数据库的常用接口，由于功能的特定性，增，删，改可以归为一类，查可以单独归为一类，采用读写分离的数据库设计，在业务调用起来更加规范，相对于增删查改一起，粒度较小，更容易管理。

而且写接口容易对数据造成影响，写文档的时候可能需要重点记录，读取接口由于不会影响数据，相对好管理一点，博主一向的原则是重点记录写接口，能复用的不增加接口。

1. 读写分离有优点，也有缺点。
2. 优点是可以提高数据库的性能和可扩展性。
读写分离将读操作和写操作分离到不同的数据库实例上，可以减轻单一数据库实例的负载压力，提高读操作的响应速度。
同时，通过增加读库的数量，还可以实现水平扩展，进一步提升系统的性能。
3. 缺点是会引入数据一致性的问题。
由于读写分离将读操作和写操作分离到不同的数据库实例上，可能会导致读操作读取到的数据不是最新的。
这就需要在应用程序中加入一些机制来保证数据的一致性，例如通过主从同步或者其他方式来保证数据的同步更新。
此外，读写分离还会增加系统的复杂性和维护成本，需要额外的工作来管理多个数据库实例。
4. 总结来说，数据库读写分离可以提高系统的性能和可扩展性，但同时也会引入数据一致性的问题，并增加系统的复杂性和维护成本。
在实际应用中，需要根据具体的业务需求和系统情况来选择是否使用读写分离。

到此，以上就是小编对于MySQL读写分离的问题就介绍到这了，希望介绍的2点解答对大家有用，有任何问题和不懂的，欢迎各位老师在评论区讨论，给我留言。