MySQL读写分离是一种常见的数据库架构设计模式，旨在提高系统的性能和可用性。它通过将读操作和写操作分离到不同的MySQL实例上来实现。
读写分离的原理
- 主服务器（Master）：负责处理所有的写操作（如INSERT、UPDATE、DELETE），保持数据的一致性。
- 从服务器（Slaves）：负责处理所有的读操作（如SELECT），提供数据的查询服务。
具体实施读写分离主要包括以下步骤：
- 配置主服务器：将所有写操作指向主服务器，确保主服务器是可写的。
- 配置从服务器：将所有读操作指向从服务器，确保从服务器是只读的。
- 同步数据：将主服务器上的数据同步到所有从服务器上，以保持数据的一致性。
- 负载均衡：使用负载均衡器或代理服务器来分发读请求到多个从服务器，以提高读的性能和可伸缩性。
- 监控与自动切换：监控主服务器的状态，如主机故障或网络故障，自动切换到另一个主服务器。
读写分离的好处
- 提高读的性能：通过将读操作分发到多个从服务器上，可以减轻主服务器的读压力，提高整体的读取性能。
- 提高可用性：当主服务器发生故障时，可以快速切换到其他从服务器，保证系统的正常运行。
- 分担主服务器的负载：将读操作分担到从服务器上，可以让主服务器更集中地处理写操作，从而提高整体的系统性能。
需要注意的是，读写分离不是完美的解决方案，它也存在一些局限性和挑战，例如数据同步延迟、数据一致性问题、复杂的配置和维护等。因此，在设计和实施读写分离时，需要根据具体的应用场景和业务需求进行综合考量和权衡。
读写分离的缺点
主从结构最大的缺点在于主从延迟，导致往主库写入的数据跟从库读出来的数据不一致。尤其是在高并发状态往主库写入的数据量很多的时候，延迟会很严重。
如何判断主从延迟？
在从库上，可以查看show slave status查看如下参数：
1.seconds_behind_master是否为0。如果不为0，则表示有延迟。
2.read_master_log_pos和
读写延迟解决方法
1.强制走主库方案
业务方自己判断走主库还是从库，很多proxy都支持强制走主库。
优点：业务比较灵活，可以满足大多数条件。
缺点：遇到所有的查询都要走主库的情况。这个时候主从架构就失去了意义。
2.判断主备无延迟方案
2.1 通过判断seconds_to_master参数来判断，但是只能精确到秒，不够准确。
2.2 通过判断master_log_file和read_master_log_pos, 以及relay_master_log_file和exec_master_log_pos来判断。
2.3通过gtid来判断
需要设置auto_position=1.retrived_gtid_set和executed_gtid_set一样，则说明主备无延迟。