MySQL读写分离是一种通过将数据库的读操作和写操作分配到不同数据库实例上执行的架构方案，目的是降低单一数据库实例的负载压力，提升整体数据库服务的并发处理能力。其核心依赖MySQL的主从复制机制，通过主库和从库的数据同步，保证多个数据库实例之间的数据一致性，从而让读请求可以分散到多个从库上处理。
MySQL读写分离的核心基础：主从复制
要实现读写分离，首先需要搭建MySQL主从复制架构，主从复制的工作流程如下：
- 主库开启二进制日志（binlog），所有写操作都会记录到binlog中
- 从库的I/O线程连接主库，读取主库的binlog内容，并写入到自身的中继日志（relay log）中
- 从库的SQL线程读取中继日志的内容，在从库上重新执行这些操作，完成数据同步
主从复制完成后，主库和从库的数据会保持一致，此时就可以将写请求发送到主库，读请求发送到从库，实现读写分离。
读写分离的具体实现原理
请求分发逻辑
读写分离的核心逻辑是对数据库请求做分类处理：
- 所有写操作（INSERT、UPDATE、DELETE、DDL语句等）全部路由到主库执行，保证数据修改的源头唯一，避免数据冲突
- 所有读操作（SELECT语句等）根据预设的规则路由到一个或多个从库执行，分摊读请求的压力
常见的请求分发方式
实际落地中，读写分离的请求分发通常有两种实现方式：
1. 应用层代码分发
在应用程序的代码中，根据SQL语句的类型，手动选择连接主库还是从库的数据源。以下是一个简单的Java示例，展示如何根据SQL类型选择数据源：
import java.sql.Connection;
import java.sql.SQLException;
import java.util.regex.Pattern;
public class DataSourceRouter {
// 匹配写操作的正则，涵盖INSERT、UPDATE、DELETE、CREATE、ALTER等
private static final Pattern WRITE_SQL_PATTERN = Pattern.compile("^(INSERT|UPDATE|DELETE|CREATE|ALTER|DROP|TRUNCATE)", Pattern.CASE_INSENSITIVE);
private Connection masterConnection;
private Connection slaveConnection;
public Connection getConnection(String sql) throws SQLException {
// 判断SQL是否为写操作
if (WRITE_SQL_PATTERN.matcher(sql.trim()).find()) {
return masterConnection;
} else {
return slaveConnection;
}
}
}
2. 中间件层分发
通过独立的数据库中间件（如MyCat、ShardingSphere-Proxy等）来实现请求分发，应用层只需要连接中间件，不需要关心读写分离的逻辑。中间件会解析接收到的SQL语句，自动将写请求转发到主库，读请求转发到从库。以下是ShardingSphere的读写分离配置示例：
# ShardingSphere读写分离配置
schemaName: read_write_splitting_db
dataSources:
master_ds:
url: jdbc:mysql://127.0.0.1:3306/master_db?useSSL=false&serverTimezone=UTC
username: root
password: root
slave_ds_0:
url: jdbc:mysql://127.0.0.1:3307/slave_db_0?useSSL=false&serverTimezone=UTC
username: root
password: root
slave_ds_1:
url: jdbc:mysql://127.0.0.1:3308/slave_db_1?useSSL=false&serverTimezone=UTC
username: root
password: root
rules:
- !READWRITE_SPLITTING
dataSources:
read_write_splitting:
type: Static
props:
write-data-source-name: master_ds
read-data-source-names: slave_ds_0, slave_ds_1
loadBalancerName: round_robin
loadBalancers:
round_robin:
type: ROUND_ROBIN
读写分离的注意事项
虽然读写分离能提升数据库性能，但使用时需要注意以下问题：
- 主从复制存在延迟，写操作完成后立即读从库，可能会读取到旧数据，需要根据业务场景做延迟处理或者强制读主库的配置
- 从库的数量需要根据读请求的并发量来调整，过多的从库会增加主库的同步压力
- 如果主库故障，需要手动或者自动将从库提升为主库，保证写服务可用，通常会配合高可用方案一起使用
读写分离与主从复制的关系总结
主从复制是读写分离的基础，没有主从复制保证主从库的数据一致性，读写分离就无法正常运作。读写分离是主从复制的典型应用场景，通过合理分配读写请求，最大化利用主从架构的性能优势。两者结合可以有效应对高并发场景下的数据库压力，是很多中大型系统数据库架构的标配方案。