SQL数据库读写分离的核心是主从复制与读写路由协同：主库通过binlog记录变更，从库用IO线程拉取、SQL线程重放实现异步同步；应用层或中间件路由将写操作发往主库、读操作默认发往从库，事务内读也走主库；通过强制主库读、延迟监控、缓存或GTID等待等策略保障一致性。

SQL数据库读写分离的核心，就是把写操作集中到主库、读操作分散到从库，靠的是“主从复制 + 读写路由”两个环节协同工作。

主库怎么把数据同步给从库？

主库开启二进制日志（binlog），所有增删改操作都会被记录成逻辑或行级变更事件。从库启动两个线程：IO线程连接主库拉取binlog，存为中继日志（relay log）；SQL线程再逐条重放这些日志，更新自身数据。这样就实现了异步、单向的数据同步。

• 主库必须设置唯一 server-id，并启用 binlog，推荐使用 ROW 格式，避免语句级复制的不确定性
• 从库也需配置不同 server-id，加上 read_only=1 防止误写
• 主库要创建专用复制账号（如 'repl'@'%'），授予 REPLICATION SLAVE 权限
• 从库执行 CHANGE MASTER TO 指令时，需指定主库当前的 binlog 文件名和位置（可用 SHOW MASTER STATUS 查看）

请求怎么知道该发给主库还是从库？

应用发起 SQL 后，需要一个决策层判断类型并转发——这就是读写路由。它不改变 SQL 本身，只决定目标数据源。

• 写操作（INSERT/UPDATE/DELETE/DDL）一律走主库，确保强一致性
• 读操作（SELECT）默认走从库，但要注意主从延迟带来的数据滞后问题
• 事务内若含读操作，默认全部路由到主库，避免同一事务读到旧数据
• 可结合注解（如 @ReadOnly）、AOP 切面或 ThreadLocal 上下文动态切换数据源

常见路由实现方式对比

路由可以放在不同层级，各有利弊：

• 应用层路由：Spring Boot 中用 AbstractRoutingDataSource + 多数据源配置，控制粒度细、性能好，但代码侵入性强
• 中间件代理：如 ShardingSphere-Proxy、MyCat、MySQL Router（8.2+ 支持自动识别读写），对业务透明，运维集中，但多一次网络跳转，存在单点风险
• 驱动层支持：MySQL Connector/J 提供 replication 和 loadbalance 两类 URL，适合简单场景，灵活性较低

一致性怎么保障？

完全实时一致不可能，但可通过策略控制延迟影响范围：

• 关键读（如刚注册就查用户信息）可强制走主库，加 @DataSource("master") 注解即可
• 从库延迟监控很重要，可通过 SELECT MASTER_POS_WAIT() 或比对 Seconds_Behind_Master 判断
• 避免在从库执行耗时长的分析查询，否则可能拖慢同步进度
• 写后立即读的场景，建议引入缓存兜底，或用 GTID + wait_until_sql_applied 机制等待同步完成