
📌 **关键词**：ProxySQL、数据库中间件、读写分离、MyCAT、ShardingSphere、主从复制、查询路由、高可用

---

👋 大家好，我是数据库小学妹！

我们前面学完主从复制、读写分离，感觉动态数据源、AOP 注解、强制读主，这条路终于走通了。后面发现在Spring 配了两套数据源，事务里还要手动处理，加个从库就得改代码重新发版。连接池管理、故障切换这些更麻烦的事，我压根没考虑到。

最近我就把市面上主流的数据库中间件翻了个遍，最后选了 ProxySQL。今天把选型和踩坑的过程捋一遍，省得你再走我的弯路。

---

## 一、手写读写分离的痛点

初学读写分离时，手写代码确实轻量好用。但系统跑起来之后，问题一个个冒出来：

| 痛点 | 手写代码 | 中间件 |
|------|---------|--------|
| 新增从库 | 改代码、发版、重启 | 改配置，秒级生效 |
| 从库故障 | 代码判断连接失败再切主库 | 自动摘除故障节点 |
| 连接池 | 每个数据源单独配 | 统一管控 |
| 多语言 | Java 写一套，Python 再写一套 | 任何语言连过来都行 |
| 负载均衡 | 自己实现轮询/权重 | 内置支持 |

说白了，中间件就是在应用和数据库之间加一层代理，脏活累活它全包了。

---

## 二、选型：为什么是 ProxySQL？

市面上做读写分离的中间件我重点看了三个：ProxySQL、MyCAT、ShardingSphere。

| 维度 | ProxySQL | MyCAT | ShardingSphere |
|------|----------|-------|----------------|
| 定位 | 轻量级 MySQL 代理 | 分布式数据库中间件 | 生态最全的数据库中间件 |
| 部署复杂度 | 低，单进程 | 中，依赖 ZooKeeper | 高，概念多、配置复杂 |
| 读写分离 | 原生支持，规则灵活 | 支持 | 支持 |
| 分库分表 | 不支持 | 支持 | 强项 |
| 故障自动切换 | 内置健康检查 | 需额外部署 | 需配合其他组件 |
| 配置方式 | SQL 语句配置 | XML 配置 | YAML/Java API |
| 性能损耗 | 很低（C++ 开发） | 中等 | 中等 |
| 学习曲线 | 平缓 | 中等 | 陡峭 |
| 适合场景 | 纯读写分离 | 分库分表 | 分库分表 + 企业级需求 |

我当时只需要读写分离，没有分库分表的需求。MyCAT 和 ShardingSphere 功能太重，为了一个读写分离引入一套复杂架构，成本和收益不成正比。ProxySQL 轻量、专注、性能好，够用就行。

当然，如果你已经在用 ShardingSphere 做分库分表，直接用它做读写分离也顺理成章。选型没有绝对对错，看现状。

---

## 三、ProxySQL 核心概念

动手之前，先搞清楚几个核心概念，不然配置的时候会一脸懵。

### 3.1 三层配置体系

ProxySQL 的配置分三层，这是最容易搞混的地方：

```
┌─────────────┐
│  RUNTIME    │ ← 正在生效的配置（内存中，最快）
├─────────────┤
│  MEMORY     │ ← 你正在编辑的配置（还没生效）
├─────────────┤
│  DISK       │ ← 持久化到 SQLite 的配置（重启不丢）
└─────────────┘
```

操作逻辑：**改 MEMORY → LOAD 到 RUNTIME → SAVE 到 DISK**。

刚开始我老是忘了 SAVE，重启 ProxySQL 后配置全没了，又得重新配一遍 😭

### 3.2 几个关键表

ProxySQL 的配置存在表里，不是配置文件，这点和传统中间件很不一样：

| 表名 | 作用 |
|------|------|
| `mysql_servers` | 后端 MySQL 实例（主库、从库都在这登记） |
| `mysql_users` | 应用连接 ProxySQL 用的账号 |
| `mysql_query_rules` | 核心：定义读写分离规则 |
| `mysql_replication_hostgroups` | 主从组别管理（自动故障切换用） |

---

## 四、实战：从零搭起来

### 4.1 Docker 启动

```bash
docker run -d \
  --name proxysql \
  -p 6033:6033 \
  -p 6032:6032 \
  proxysql/proxysql:2.5

# 6033 是应用连接端口，6032 是管理端口
```

连接管理端口，开始配置：

```bash
mysql -u admin -padmin -h 127.0.0.1 -P 6032 --prompt='ProxySQL> '
```

### 4.2 添加后端 MySQL 实例

```sql
-- 添加主库（写节点）
INSERT INTO mysql_servers (hostgroup_id, hostname, port, weight, comment)
VALUES (10, 'mysql-master', 3306, 1000, '主库-写');

-- 添加从库（读节点）
INSERT INTO mysql_servers (hostgroup_id, hostname, port, weight, comment)
VALUES (20, 'mysql-slave1', 3306, 500, '从库1-读');
INSERT INTO mysql_servers (hostgroup_id, hostname, port, weight, comment)
VALUES (20, 'mysql-slave2', 3306, 500, '从库2-读');

-- 加载到 RUNTIME 并持久化
LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
```

`hostgroup_id` 是分组用的：10 是写组，20 是读组。权重 `weight` 决定流量分配比例，两个从库都是 500，流量就是对半分。

### 4.3 配置应用账号

```sql
-- 添加应用连接账号（应用用这个连 ProxySQL）
INSERT INTO mysql_users (username, password, default_hostgroup)
VALUES ('app_user', 'app_pass', 10);

LOAD MYSQL USERS TO RUNTIME;
SAVE MYSQL USERS TO DISK;
```

`default_hostgroup=10` 的意思是：默认请求都走写组（主库），除非后面的规则明确指定读组。

### 4.4 核心：配置读写分离规则

这是最关键的一步，规则决定了哪些 SQL 走主库、哪些走从库。

```sql
-- 规则1：SELECT 且不在事务中 → 走读组（20）
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply)
VALUES (1, 1, '^SELECT.*', 20, 1);

-- 规则2：事务中的 SELECT → 要走主库（保证一致性）
INSERT INTO mysql_query_rules (rule_id, active, match_digest, match_pattern, destination_hostgroup, apply)
VALUES (2, 1, '^SELECT.*FOR UPDATE', 10, 1);

-- 规则3：写操作（INSERT/UPDATE/DELETE）→ 走写组（10）
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply)
VALUES (3, 1, '^(INSERT|UPDATE|DELETE)', 10, 1);

-- 规则4：默认兜底，走写组
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply)
VALUES (4, 1, '.*', 10, 1);

LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;
```

规则按 `rule_id` 从小到大匹配，匹配到就停止。所以顺序很重要：先匹配 SELECT FOR UPDATE（要读主），再匹配普通 SELECT（读从），再匹配写操作，最后兜底走主库。

---

## 五、验证效果

应用连接改成 ProxySQL 的地址：

```yaml
spring:
  datasource:
    url: jdbc:mysql://proxysql:6033/mydb
    username: app_user
    password: app_pass
```

然后用 `stats_mysql_query_digest` 表查看路由情况：

```sql
SELECT digest_text, sum_time, count_star, hostgroup
FROM stats_mysql_query_digest
ORDER BY count_star DESC
LIMIT 10;
```

如果看到 SELECT 的 `hostgroup` 是 20，INSERT/UPDATE 的 `hostgroup` 是 10，恭喜，读写分离生效了 ✅

---

## 六、踩坑实录（血泪史）

### 💣 坑 1：事务里的读操作被路由到从库

**现象**：一个事务里先 INSERT 了一条数据，紧接着 SELECT 查出来是空的。

**原因**：SELECT 被规则匹配到读组，去从库查了，但从库还没同步完这条数据（主从延迟）。

**解决**：开启事务时，ProxySQL 会自动把所有请求路由到同一个 hostgroup（默认是事务开始的那个）。但我当时没用事务包裹，就出问题了。

正确做法：涉及"写后立即读"的逻辑，要么放事务里，要么在 SQL 前加注释强制走主库：

```sql
/* hostgroup=10 */ SELECT * FROM orders WHERE user_id = 123;
```

### 💣 坑 2：从库挂了，流量没自动切走

**现象**：一个从库宕机后，ProxySQL 还在往上面发请求，导致部分查询报错。

**原因**：没配健康检查，或者检查间隔太长。

**解决**：用 `mysql_replication_hostgroups` 表让 ProxySQL 自动管理主从状态：

```sql
INSERT INTO mysql_replication_hostgroups (writer_hostgroup, reader_hostgroup, comment)
VALUES (10, 20, '主从自动管理');

LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
```

配上之后，从库挂了会自动摘流量，主库挂了会触发切换（配合 MGR 或 Orchestrator 效果更好）。

### 💣 坑 3：规则写得太宽泛，漏匹配

**现象**：有些查询没被规则匹配到，全走到了默认的主库，从库闲置。

**原因**：`match_digest` 用的是正则，`^SELECT.*` 看起来能匹配所有 SELECT，但如果 SQL 里有换行或者注释，就可能匹配不上。

**解决**：用 `SELECT ... FOR UPDATE` 这种明确的模式做精确匹配，普通 SELECT 放最后兜底。规则宁可写细一点，别贪多。

### 💣 坑 4：忘了 SAVE 到 DISK

**现象**：重启 ProxySQL 后，所有配置都没了。

**解决**：每次改完配置，记得 `SAVE MYSQL ... TO DISK;`。后来我写了个脚本，改完自动 LOAD + SAVE，再也没丢过配置。

### 💣 坑 5：监控没跟上，出问题了才知道

**现象**：ProxySQL 本身挂了，应用全连不上，半小时后才被发现。

**解决**：监控 ProxySQL 的关键指标：
- `ProxySQL_Threadpool_TrxNum`：当前事务数
- `mysql_server_ping_errors`：后端节点健康状态
- `stats_mysql_connection_pool`：连接池使用情况

配合 Prometheus + Grafana，ProxySQL 出问题能秒级告警。

---

## 七、总结

选型这件事，说难也难，说简单也简单。

我目前只需要读写分离，没有分库分表的需求。ProxySQL 做不了分库分表，但恰好够用，这就是最合适的选择。

手写代码做读写分离，短期轻松长期痛苦。中间件看似多引入一层，省掉的是后面无限叠加的维护成本。

规则顺序和事务一致性，是读写分离最容易翻车的两个地方。配规则的时候多测几遍，别等上线了再翻车。


👋 我是数据库小学妹，一个用设计师思维学数据库的转行人。你们在读写分离选型上踩过什么坑？

---

*本文基于 ProxySQL 2.5 + MySQL 8.0 环境。不同版本配置略有差异，建议参考官方文档确认参数。*


📌 关键词：ProxySQL、数据库中间件、读写分离、MyCAT、ShardingSphere、主从复制、查询路由、高可用

读写分离中间件怎么选？ProxySQL 落地踩坑与选型对比

📌 摘要：本文介绍了数据库中间件ProxySQL在读写分离场景下的优势与实战配置。相比手写代码实现读写分离，ProxySQL具备自动故障切换、连接池统一管理等优势。文章对比了ProxySQL、MyCAT和ShardingSphere的特性，指出ProxySQL在纯读写分离场景下的轻量级优势。详细讲解了ProxySQL的三层配置体系和核心概念，并提供了从Docker部署到规则配置的完整实践指南。最

后端

数据库

架构设计

选择ProxySQL作为轻量级数据库中间件，解决手写读写分离的痛点。相比MyCAT、ShardingSphere，ProxySQL专注读写分离、配置简单、性能损耗低。核心配置三层体系与关键表管理，支持自动故障切换和负载均衡。实战中注意规则顺序、事务一致性及健康检查，避免常见配置陷阱。适合纯读写分离场景，提升高可用性与运维效率。

分布式数据库

负载均衡

中间件

路由

SQLite

Python

MySQL

Java

2026年中大促 | AI 领航 智绘未来

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

选择ProxySQL作为轻量级数据库中间件，解决手写读写分离的痛点。相比MyCAT、ShardingSphere，ProxySQL专注读写分离、配置简单、性能损耗低。核心配置三层体系与关键表管理，支持自动故障切换和负载均衡。实战中注意规则顺序、事务一致性及健康检查，避免常见配置陷阱。适合纯读写分离场景，提升高可用性与运...

读写分离中间件怎么选？ProxySQL 落地踩坑与选型对比-腾讯云开发者社区-腾讯云

读写分离中间件怎么选？ProxySQL 落地踩坑与选型对比

读写分离中间件怎么选？ProxySQL 落地踩坑与选型对比

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐