mysql如何配置读写分离_mysql读写分离配置方法

来源：这里教程网时间：2026-02-28 20:31:28 作者：

MySQL 读写分离是一种常见的数据库优化手段，通过将读操作和写操作分发到不同的服务器上，减轻主库压力、提升系统性能。实现 MySQL 读写分离通常需要借助中间件或应用层逻辑控制，以下是几种常见配置方法。

1. 基于中间件的读写分离（推荐）

使用 MyCat 或 ShardingSphere 实现自动路由

MyCat 和 Apache ShardingSphere 是常用的数据库中间件，支持 SQL 解析、读写分离、分库分表等功能。

配置步骤（以 ShardingSphere-Proxy 为例）：

安装并启动 ShardingSphere-Proxy 编辑配置文件
server.yaml
设置登录权限编写
config-readwrite-splitting.yaml
定义主从结构：

dataSources:
  write_ds:
    url: jdbc:mysql://192.168.1.10:3306/mydb?serverTimezone=UTC&useSSL=false
    username: root
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
  read_ds_0:
    url: jdbc:mysql://192.168.1.11:3306/mydb?serverTimezone=UTC&useSSL=false
    username: root
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
rules:
  - !READWRITE_SPLITTING
    dataSources:
      rw_ds:
        writeDataSourceName: write_ds
        readDataSourceNames:
          - read_ds_0
        loadBalancerName: round_robin
    loadBalancers:
      round_robin:
        type: ROUND_ROBIN

重启 Proxy，客户端连接 Proxy 地址即可自动实现读写分离

2. 应用层手动控制读写分离

在代码中指定数据源

适用于 Spring Boot 等框架，通过 AOP 或 AbstractRoutingDataSource 动态切换主从库。 配置多个数据源：主库用于 INSERT/UPDATE/DELETE，从库用于 SELECT 使用注解如 @DS("master") / @DS("slave") 控制数据源选择 注意事务中的读操作会强制走主库，避免主从延迟导致数据不一致

示例逻辑：

写操作 → 主库
普通查询 → 从库
事务内查询 → 主库

3. 使用 MaxScale 中间件

MariaDB 提供的数据库代理服务

MaxScale 可解析 SQL 类型，自动将写请求发送给主节点，读请求分配给从节点。 配置主从复制环境 安装 MaxScale 并编辑
/etc/maxscale.cnf
定义监听端口、路由规则和服务类型

关键配置片段：

```ini [Read-Write-Service] type=service router=readwritesplit servers=server1,server2 user=maxscale password=mxs_password

[Listen] type=listener service=Read-Write-Service protocol=MariaDBClient port=4006

<ul>
  <li>应用连接 MaxScale 的 4006 端口，由其完成自动分流</li>
</ul>
<H3>4. 注意事项与前提条件</H3>
<p><strong>读写分离依赖主从复制机制</strong></p>
<font color="#333333">必须先配置好 MySQL 主从复制（Replication），确保从库能实时同步主库数据。</font>
<ul>
  <li>启用 binlog，设置唯一 server-id</li>
  <li>主库开启 GTID 推荐，便于故障转移</li>
  <li>监控主从延迟，避免因网络问题导致读取脏数据</li>
  <li>部分强一致性场景仍需强制走主库查询</li>
</ul>
基本上就这些。选择哪种方式取决于架构复杂度和维护成本。中小项目可用应用层控制，大型系统建议用 ShardingSphere 或 MaxScale 统一管理。