分布式数据库代理实战：选型、部署与踩坑全记录-平芜编程栈

说起来挺有意思，我最早接触到“分布式数据库代理”这个词，是在公司业务量上来之后，单实例MySQL开始频繁报警，DBA把库拆成了三套集群，结果业务代码里数据源配置乱成一锅粥，每次发版都提心吊胆。后来我们决定在应用和数据库之间加一层代理，也就是标题里说的“分布式数据库代理”，才总算把这块理顺。这篇文章就围绕我实际搭建和运维这套代理层的经历展开，讲讲它到底解决了什么问题、选型时怎么避坑、部署起来有哪些关键步骤，以及生产环境里那些文档不会告诉你的踩坑记录。如果你正在做分库分表、读写分离，或者纯粹被多数据源折磨得不行，这篇应该能给你一个完整的参考。

1. 分布式数据库代理到底解决什么问题：先搞清楚为什么需要它

很多人一听“数据库代理”就以为是给数据库加个反向代理，或者干脆和Nginx反向代理混为一谈，其实完全不是一回事。分布式数据库代理是介于应用层和数据库存储层之间的中间件，它接收应用的SQL请求，然后根据规则把请求转发到正确的数据库节点上。它解决的是分布式数据库场景下的“接入混乱”问题，而不是网络层面的转发问题。

1.1 业务代码直连多库的混乱现场

先说我实际遇到的场景。最开始业务量不大，所有表都在一台MySQL上，代码里一个DataSource搞定。后来表数据到了几千万级，单库扛不住了，于是按业务域拆成订单库、用户库、支付库，再加上读写分离，光从库就有三四个。这个时候你打开项目代码一看，数据源配置可能有七八个，每个Mapper都要指定自己走哪个数据源，@DS注解满天飞。更要命的是，新来的同事根本搞不清某个查询应该连哪个库，一不小心连错库，轻则慢查询，重则业务数据直接串了。

这种“业务代码直连多库”的方式，本质上是把路由逻辑硬编码进了应用层。一旦哪天需要把某个分片再拆细一点，或者把某个从库摘掉，你得回业务代码里改配置、改注解、重新发版。发版期间服务不可用不说，改错了就是生产事故。我见过最夸张的一次，一个团队把订单查询路由到了用户库，结果前端页面硬生生卡了半分钟才超时，最后排查下来就是数据源配错。

1.2 代理层在架构里的位置与职责

加了一层数据库代理之后，架构就变成这样：

业务应用 -> 数据库代理（统一入口） -> 后端多个数据库节点（主库/从库/分片）

应用层不再关心数据到底在哪台机器上，它只需要连接代理的地址和端口，剩下的路由、转发、读写分离全部由代理层完成。代理层的核心职责主要有这几块：

统一接入：所有应用只有一个数据库入口，配置简单，不需要各自维护一堆数据源。
读写分离：根据SQL类型自动路由，SELECT走从库，INSERT/UPDATE/DELETE走主库。
分片路由：根据分片键把请求打到对应的分片节点，业务无感知。
连接池复用：代理统一管理到后端的连接，避免应用大量短连接把数据库打崩。
高可用切换：后端节点故障时，代理可以自动摘除并切换，应用甚至可以无感知。

打个比方，没有代理层的时候，应用像是访客要自己记住公司每个部门在几楼几号办公室，敲门之前还得确认对方是不是自己要找的人。有了代理层，访客只需要去前台，前台会根据你的需求帮你安排到对应的部门。前台就是那个代理。

1.3 和通用反向代理（Nginx）的本质区别

这里要重点说一下，为什么Nginx这种通用反向代理不能直接拿来当数据库代理用。Nginx擅长的是HTTP/HTTPS协议层面的转发，比如location /api转发到某个后端服务，它可以解析URL、改写头部、处理证书，做得非常细。但它对MySQL的二进制协议是“看不懂”的，就算用stream模块做四层TCP转发，它也只是一个盲转，不知道你发的是一条SELECT还是一条UPDATE，更不可能做读写分离、分片路由。

数据库代理是“SQL感知”的，它能把你的SQL解析出来，读懂你要查哪张表、条件是什么、走哪个分片，然后再决定转发到哪里。这就像同样是“代理”，Nginx是快递中转站，只负责把包裹运到对应城市；数据库代理则是懂业务的调度中心，知道包裹里是什么物品，还知道该送哪个仓库。所以别想着拿Nginx省事，对于数据库这种有状态、SQL语义复杂的场景，必须上专用的数据库代理组件。

2. 代理层选型：自研、ProxySQL、Vitess、ShardingSphere怎么选

确定了要加代理层，接下来的问题就是用哪个方案。市面上的选择不少，我简单列一下主流的四条路线，然后逐个分析它们的适用场景和代价。

方案	SQL感知能力	分片路由	读写分离	高可用	学习成本	适用规模
自研代理	可控	可控	可控	需自己实现	极高	特殊定制需求
ProxySQL	强（基于规则）	一般（主要做读写分离/路由）	极强	强	低	中小规模，MySQL为主
Vitess	强	强	强	强	高	大规模，分片复杂
ShardingSphere-Proxy	强	强	强	中	中	中等规模，Java生态

2.1 四种方案的本质差异

先看ProxySQL。这个组件在MySQL生态里非常popular，核心设计思路是基于规则的路由，它不关心你的业务表结构，只根据SQL文本、用户、Schema等条件匹配规则，然后转发到指定的主机组。它的读写分离配置非常成熟，秒级切换，性能也好。代价是分片能力偏弱，它不太适合那种需要按某个字段把一张大表拆到几十个节点的场景，更适合“多实例但每张表是完整逻辑表”的部署方式。

再看Vitess，这是YouTube出身的分片方案，设计目标就是解决大规模OLTP场景下的分片问题。它会把一张逻辑大表拆成很多个分片，每个分片落在不同的MySQL实例上，应用通过VSchema映射表来路由。它很强，但引入的概念非常多：cell、keyspace、shard、vtgate、vttablet，光这些词就能劝退不少人。如果你的业务还没到“单表数据量爆炸、必须分片”的阶段，上Vitess其实是过度设计。

ShardingSphere-Proxy算是Java生态里比较均衡的选择，它既能做读写分离，也能做分片路由，对业务侵入低，因为应用连的是代理的端口，不需要改代码。它的劣势是性能损耗比ProxySQL略高，而且和Java技术栈绑定比较深，运维起来需要一定的Java功底。

自研这条路我放到后面单独说，因为我觉得必须给所有动了“自己写一个数据库代理”念头的人泼盆冷水。

2.2 为什么很多团队一开始选ProxySQL

我们团队当时的情况是：数据库还是MySQL，规模中等，主要痛点是读写分离和统一接入，分片需求还没那么强烈。这种情况下ProxySQL几乎是性价比最高的选择。部署轻量，一个二进制文件跑起来就行；配置是类SQL语法，DBA上手很快；规则是基于正则和条件匹配的，调整规则无需重启，直接在管理端改然后LOAD MYSQL QUERY RULES TO RUNTIME就能生效；监控也做得不错，自带一堆状态表。从踩坑的角度说，我们用了两年多，稳定性相当可靠，没有出现过一次因为代理本身导致的雪崩。

这里要提醒一点：选ProxySQL不代表以后不能分片，只要你的分片路由规则能在代理层表达（比如按用户ID取模路由到不同主机组），ProxySQL也能做。但如果你的分片维度非常细、需要跨分片聚合，那还是老实考虑Vitess或者ShardingSphere这类专门为分片设计的方案。

2.3 自研代理的代价与前提

我在社区看到不少技术分享，动不动就说“我们自研了一套数据库代理”，好像很厉害。但说实话，自研数据库代理的坑比想象中多得多。你要处理MySQL协议的解包和封包，要理解COM_QUERY、COM_STMT_PREPARE这些命令的语义，要做连接管理、事务状态跟踪，要设计路由规则引擎，还要处理各种异常情况比如后端连接断开、事务回滚边界、流式结果集等。这里面任何一个环节出问题，用户的SQL不是报错，就是数据落到错误的库上，后果都比单纯性能慢严重得多。

当然也有自研的合理前提：比如你们有非常特殊的SQL路由需求，现有组件完全表达不了；或者团队有深厚的协议层开发经验，并且愿意投入大量人力维护。我见过一个金融团队自研代理，是为了实现复杂的租户隔离和审计，这种定制需求确实只能自己写。但如果你只是觉得“开源的东西不好用、想自己写一个更可控的”，我建议先租一台机器，把MySQL协议文档读一遍再决定。另外要区分一下，有人提到的“Java动态代理”和数据库代理是两码事，动态代理是Java编程里的设计模式，用来做方法拦截、AOP这类事，不是用来代理数据库流量的，别混在一起。

3. 一次完整的代理层部署实战：从安装到读写分离生效

光说不练没有意义，我把我们当时部署ProxySQL的过程拆开讲。以下步骤基于ProxySQL 2.x版本，后端清一色MySQL 8.x，拓扑是一主两从。

3.1 环境与拓扑规划

先画出规划拓扑：

应用服务器 | | (3306端口，业务无感知) v ProxySQL实例（服务器A，单点或双节点） | |--- 主库 MySQL-1（读写） |--- 从库 MySQL-2（只读） |--- 从库 MySQL-3（只读）

ProxySQL本身可以单实例部署，但生产环境建议双实例通过Keepalived做高可用，或者在应用层做多个连接入口。我当时第一步先用单实例验证整套流程，稳定后再加高可用，这个节奏比较稳妥。版本选择上，直接上最新的2.x稳定版，1.x已经是老古董了，很多功能比如mysql_servers的max_latency字段在1.x里都没有。

3.2 安装与最小配置

ProxySQL官方提供了yum/apt仓库，也可以直接下载二进制包，解压就能跑。测试环境我更喜欢直接用docker跑，一行命令起来非常快。但生产环境我倾向于服务器本地安装，减少一层虚拟化损耗：

# 从官方仓库安装（CentOS/RHEL为例） cat > /etc/yum.repos.d/proxysql.repo <<'EOF' [proxysql_repo] name=ProxySQL YUM repository baseurl=https://repo.proxysql.com/ProxySQL/proxysql-2.4.x/centos/$releasever gpgcheck=1 gpgkey=https://repo.proxysql.com/ProxySQL/proxysql-2.4.x/centos/$releasever/RPM-GPG-KEY-PROXYSQL EOF yum install -y proxysql

安装完成后启动：

systemctl start proxysql systemctl enable proxysql

ProxySQL的管理接口默认监听在6032端口，用admin用户登录：

mysql -uadmin -padmin -h127.0.0.1 -P6032

这里要提醒一下，默认密码是admin，生产环境务必第一时间改掉，否则任何人连上管理端口就能把你的路由规则改掉，风险极大。

接下来就是核心配置。第一步注册后端节点到mysql_servers表：

INSERT INTO mysql_servers(hostgroup_id, hostname, port, weight) VALUES (10, '192.168.1.101', 3306, 100), -- 主库，hostgroup 10 (20, '192.168.1.102', 3306, 50), -- 从库1，hostgroup 20 (20, '192.168.1.103', 3306, 50); -- 从库2，hostgroup 20

hostgroup_id是主机组的意思，你可以理解为把一批功能相同的节点编成一组。这里我把主库放到组10，两个从库放到组20，后面通过路由规则把读写分类到这两组。

第二步配置业务账号。注意ProxySQL里配置的用户名和密码，必须和后端MySQL里的真实用户一致，因为应用连接代理时用这个账号，代理再拿这个账号去连后端：

INSERT INTO mysql_users(username, password, default_hostgroup) VALUES ('app_user', 'app_pass_123', 10);

default_hostgroup是默认主机组，当没有规则匹配时，所有流量都会走这个组，这里我默认走到主库组10。

第三步配置读写分离规则。这是ProxySQL最核心的东西，我配了两条规则：

-- 所有SELECT查询，除了一些特殊场景，都走走从库组20 INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (1, 1, '^SELECT.*', 20, 1), (2, 1, '^INSERT.*|^UPDATE.*|^DELETE.*', 10, 1);

match_pattern是正则表达式，规则按rule_id从小到大依次匹配，命中了就按destination_hostgroup转发。这里有一个非常容易踩的坑：如果你用^SELECT.*把所有SELECT都转发到从库，那SELECT ... FOR UPDATE这类需要加锁的查询也会被转到从库，一旦它在从库执行就会导致锁失效或者数据不一致。所以实际生产环境，我加了一条更高优先级的规则，把SELECT.*FOR UPDATE单独拦截下来强制走主库：

INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (0, 1, '^SELECT.*FOR UPDATE', 10, 1);

规则rule_id越小优先级越高，所以FOR UPDATE规则排在所有普通SELECT之前。这个细节很多人忽略，等到出现数据不一致问题才回头来找规则漏洞。

配置写好后，需要显式加载并保存到运行时：

LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK; LOAD MYSQL USERS TO RUNTIME; SAVE MYSQL USERS TO DISK; LOAD MYSQL QUERY RULES TO RUNTIME; SAVE MYSQL QUERY RULES TO DISK;

只有执行了LOAD ... TO RUNTIME，配置才会真正生效；只有执行了SAVE ... TO DISK，重启后才不会丢。这个操作流程我当时背得滚瓜烂熟，因为第一次部署时忘了SAVE TO DISK，重启后所有配置全没了，白白排查了一个多小时。

3.3 验证路由是否生效

配置完成后的第一件事，不是急着让业务切流量，而是手动跑几条SQL验证路由结果。我习惯这样验证：

# 用业务账号连接代理的3306端口 mysql -uapp_user -papp_pass_123 -h127.0.0.1 -P3306

然后在代理管理端查询规则命中统计：

SELECT rule_id, hits FROM stats_mysql_query_rules;

如果规则生效，hits字段会自动累加。再进一步验证具体落到哪台后端机器，可以看stats_mysql_connection_pool：

SELECT hostgroup, srv_host, status, ConnUsed, Queries FROM stats_mysql_connection_pool;

你会看到SELECT语句大多命中hostgroup20的从库节点，而INSERT/UPDATE/DELETE命中hostgroup10的主库节点。到这一步，读写分离基本就走通了。

4. 分片路由的命门：代理键和自然键怎么选

聊完读写分离，再说代理层里另一个技术含量更高的点——分片路由。如果说读写分离是把读和写分开，那么分片路由就是把一张大表切到多个节点，然后让SQL精准落到对应的分片。这里最关键的决策就是：用什么字段做分片键。我见过太多团队在这里翻车，所以单独拿出来讲。

4.1 代理键与自然键的定义

先说概念。自然键是指业务上本身就存在、有业务含义的字段，比如用户ID、手机号、订单号，这些字段业务上唯一并且稳定；代理键则是由系统生成的、和业务无关的ID，典型的就是自增主键、雪花算法生成的ID、UUID这种。

在分布式数据库代理的路由设计里，选代理键还是自然键，不能看哪个“更标准”，而要看哪个字段真正出现在你的高频查询条件里。这个点非常反直觉，因为大多数人的第一反应是“用主键路由，主键肯定是唯一标识啊”。但问题在于：如果这个主键是业务上几乎不用的代理键，比如UUID，而业务查询大多按user_id来查，那么你按UUID做分片，每一条按user_id的查询都需要广播到所有分片，代价巨大。

4.2 选错路由键的灾难：跨节点查询

举个我踩过的真实例子。有一张订单流水表，存储量到了几亿条，我们决定把它按order_id分区，因为订单号是自然键、基数高、分布均匀，看起来是完美的分片键。结果上线之后发现，运营后台和用户端的查询几乎都是“查这个用户最近一个月的订单”，SQL里大量出现WHERE user_id = ? AND create_time > ?，但分片键是order_id，代理根本没法从user_id推算去哪个分片。

于是代理只能把这条SQL广播到所有分片，等所有分片返回后再聚合。单条SQL还好，一旦并发上来，代理层CPU直接飙升，后端每个分片都承受着原本只需要一个分片承受的查询量，最后把整个集群拖垮。这个事故给我们的教训非常直接：分片键不是选“唯一且均匀”的字段，而是选“查询条件里最高频出现”的字段。之后我们痛定思痛，把分片键改成了user_id，按用户维度做分片，那些按order_id的查询虽然变成了跨分片，但这类查询占比极低，而且可以通过反向索引表来解决，总体代价小得多。

4.3 实际项目里的路由键设计经验

总结下来，我在实际项目里挑选分片键时有几条硬性标准：

高频查询维度优先：哪个字段频繁出现在等值查询条件里，就优先考虑以它为分片键。
基数要有足够区分度：分片键的取值范围不能太小，像性别、状态这类字段只有几个值，绝对不行。
分布尽量均匀：避免出现热点，比如按某个ID取模，要保证各节点数据量和查询量接近。
尽量不要更新：分片键一旦变更，意味着数据要从一个分片迁到另一个分片，代价极大（虽然代理层支持这种迁移，但不是免费的）。

如果业务查询维度实在太多，比如既按user_id查，又按order_id查，怎么做？我的建议是“主分片键+辅助索引表”。也就是数据按user_id分片，同时建一张小表专门存order_id和分片位置的映射关系，按order_id的查询先查映射表拿到分片号，再直接路由过去。这种设计比把所有维度都塞给代理层要靠谱得多，也没有那么高的复杂度。

5. 生产环境踩坑记录：端口占用、连接风暴、路由不准

ProxySQL本身非常稳定，但配置复杂度和运维坑是一样不少。我把生产环境里踩过的几个典型问题完整复盘一遍，排查链路直接给出来，方便你以后遇到类似问题能少走弯路。

5.1 代理端口被占用的启动失败

这是我们代理集群第一次扩容新节点时遇到的问题。新机器上部署好ProxySQL，systemctl start proxysql，结果服务怎么都起不来，日志里一堆报错。仔细看才发现，所有错误指向同一个根因：Address already in use，也就是端口被占用。

排查过程其实很简单：

# 查看端口占用情况 ss -lntp | grep 6032

结果发现6032端口被一个残留的旧进程占着。这台机器之前装过一个测试用的ProxySQL实例，后来进程没杀干净，这次安装新版本时旧进程还占着端口。处理方式也很直接，先kill残留进程，再确认端口释放，然后重启服务。这类问题本身不复杂，但它提醒了我一个很重要的运维习惯：部署新的中间件实例前，先检查端口占用，尤其是同一台机器上装过同类组件时，一定要把残留进程清干净，否则被坑时可能完全想不到是这个原因。

类似的坑还有端口配置错误。有一次我们把代理监听端口6033误写成了后端MySQL的3306，应用连代理时实际连到了后端的MySQL实例，行为表现非常诡异：有的请求能通，有的请求报权限错误，因为应用账号在MySQL那边没有对应权限。排查了半天才恍然发现是端口写错了。所以部署完第一件事，务必用ss -lntp确认监听端口和配置一致。

5.2 连接数被打满的根因定位

另一个让我印象深刻的坑是“代理连接池被打满”。现象是某个下午业务反馈系统变慢，随后出现大量Too many connections报错。由于我们所有应用都连的是代理，先去看ProxySQL的连接统计：

SELECT hostgroup, srv_host, status, ConnFree, ConnUsed, ConnErrors FROM stats_mysql_connection_pool;

发现主库所在的hostgroup10连接数爆满，几乎全是ConnUsed状态。再往后端MySQL看，SHOW PROCESSLIST里全是Sleep状态的空闲连接，但代理还在持续发起新连接。追根溯源后发现，问题出在应用侧：有一个定时任务在扫表时没有正确释放连接，导致连接泄漏，每次循环都从连接池借出一堆连接但只还不还，久而久之连接数打满。

这个问题的本质是“应用连接池配置和代理连接池配置没有对齐”。比如应用侧的连接池maxActive设成了200，但代理侧mysql_servers里该后端节点的max_connections没调大，两边一加起来就爆了。解决方案是：

应用侧严格控制连接池大小，确保连接生命周期有上限。
代理侧mysql_servers的max_connections按实际需要调大。
给连接设置wait_timeout和interactive_timeout，让长时间空闲的连接自动释放。

这里还要注意一个细节：ProxySQL的mysql_servers表里有max_connections字段，但很多人在初始化配置时根本没设置，导致默认值很小，稍微上点量就爆。我们后来直接把主库组的max_connections调到500，从库组调到300，才算消停。

5.3 TLS/SSL转发场景下的证书校验问题

这是个比较进阶的坑，但分布式数据库代理生产环境几乎都会遇到。如果后端MySQL开了SSL连接，而ProxySQL到后端的连接也启用SSL，就会涉及证书校验。我们当时遇到的问题是：代理到后端连接频繁报错，日志里出现类似证书主机名校验失败的信息（跟Nginx里常见的net::ERR_CERT_COMMON_NAME_INVALID道理一样，就是证书CN和访问的主机名不匹配）。

排查链路是这样的：

确认MySQL端已经配置SSL，且证书CN是某个域名，比如db.internal.example.com。
但ProxySQL配置mysql_servers时，hostname字段填的是数据库的IP地址。
代理发起SSL握手时，按IP去校验证书，自然就报主机名不匹配。

解决办法有两种：一是把mysql_servers的hostname改成和证书CN一致的域名，然后通过/etc/hosts做解析，让代理能通过域名访问MySQL；二是在连后端时关闭主机名校验，只做证书链的加密校验。具体用哪种，取决于你的安全要求。比较简单的做法是，如果内网环境已经足够可信，可以不强制代理到后端的高强度SSL，只保证应用到代理这一段是加密的。但如果你有等保或合规要求，那就必须把证书校验完整配好，不能嫌麻烦。

5.4 路由不准的排查链路

最后一个坑是路由规则明明配了，但流量还是全部走主库。这种情况最容易发生在规则上线后的一周内，现象是主库负载高企，从库几乎没流量。

完整的排查链路按下面走，基本都能定位到问题源头：

先看规则是否加载到了运行时：在管理端执行SELECT rule_id, active, match_pattern, destination_hostgroup FROM mysql_query_rules，再执行SELECT * FROM runtime_mysql_query_rules，对比两者是否一致。有时候你改了规则但忘了LOAD MYSQL QUERY RULES TO RUNTIME，配置压根没生效。
再看规则命中情况：SELECT rule_id, hits FROM stats_mysql_query_rules，如果hits为0，说明这条规则根本没被匹配到。这时候检查match_pattern正则是不是写错了，比如转义字符、锚点、大小写匹配问题。MySQL的SQL是大小写不敏感的，但正则匹配本身是敏感的，select和SELECT不一样，所以规则里要么用(?i)忽略大小写，要么把常见大小写都写全。
确认规则是否被更高优先级的规则抢先：rule_id越小优先级越高，如果你有一个更靠前的规则把所有流量都匹配并apply=1了，后面的规则就不会执行。这是特别容易犯的错，比如在测试时写了一条match_pattern='.*'的默认转发规则放在前面，之后加了新规则全被它吞了。
确认连接的会话是否复用了旧的hostgroup：有时候规则没问题，但连接是从连接池复用的，而这个连接之前已经绑定了某个hostgroup，ProxySQL为了保持事务一致性不会随便切换主机组。这种场景比较迷，需要看连接状态或用SELECT ... ;手动测试。

把这几步走完，路由不准的问题十有八九都能定位。印象里有一次是同事写正则时把.*写成了*，正则直接不合法，那批规则全部加载失败，流量自然全走默认主机组，主库被压到报警。找到原因后，我养成了一个习惯：任何线上规则的变更，先在一台测试实例上跑通，确认hits在增长后再同步到生产。

6. 让代理层跑得更稳：监控调优与故障转移

部署完成、踩坑踩完，代理层的维护才刚刚开始。我很想把“配置好了就完事”的幻觉打破，因为代理层一旦出问题，受影响的不是某一条SQL，而是整个接入它的业务集群。

6.1 关键监控指标别只看CPU和内存

刚开始运维代理层时，我也只盯着CPU、内存、磁盘这些基础指标，后来发现这远远不够。代理层真正要盯的是下面这四类指标：

连接数：stats_mysql_connection_pool里的ConnUsed和ConnFree。连接数趋势能提前暴露连接泄漏和后端过载。
路由命中率：stats_mysql_query_rules里各规则的hits占比。如果某条本应高命中的规则命中率很低，说明规则设计有问题或SQL写法偏离预期。
后端延迟：stats_mysql_connection_pool里的latency_us字段，反映代理到后端节点的延迟。某一节点延迟突然飙升，很可能是慢查询或网络抖动。
错误数：stats_mysql_connection_pool里的ConnErrors，以及ProxySQL错误日志。错误数持续增长通常意味着后端节点不稳定或者账号权限出了问题。

这些指标我建议接入现有的监控体系，配置告警阈值。比如ConnErrors超过某个值就告警，latency_us超过预设值就通知值班同学。别等业务方来投诉才去看，那时候往往已经晚了。

6.2 连接池和超时参数的调优实践

连接池调优没有万能公式，得结合你的并发模型来定。我以ProxySQL为例给出几个重点参数：

参数	配置位置	我的建议
`mysql-connection_max_age`	管理端gloabl变量	设为3600秒，连接不一直长存，周期性重建，规避MySQL侧资源老化
`mysql-connect_timeout`	全局变量	设1000-3000毫秒，太短容易在抖动时误判，太长则拖慢故障感知
`mysql-wait_timeout`	全局变量	控制代理到后端的空闲连接存活时间，设为60-120秒，避免大量Sleep连接堆积
后端`max_connections`	`mysql_servers`表	按后端实际吞吐能力设置，主库500，从库300以上

调优过程中不断压测，观察连接数和延迟的变化，找到适合你集群的合理区间。另外提醒一个容易被忽略的参数：mysql-threads，它控制ProxySQL用来处理后端读写操作的线程数，如果业务并发很高，默认4个线程肯定不够，建议翻倍持续观察。

6.3 故障转移测试不能只做一次

代理层的重要职责之一是故障转移，但这个能力如果只在“真正出事”时才验证，风险极大。我们团队每季度会做一次主动故障演练，模拟主库宕机，验证代理是否真的能把流量切到从库或者备用主库。操作流程大致如下：

选定一个业务低峰时段，提前通知所有相关方。
在MySQL主库所在服务器上执行SHUTDOWN或者用防火墙规则临时屏蔽主库端口。
观察ProxySQL的mysql_servers表，确认主库节点被标记为OFFLINE_SHUN。
观察应用侧是否出现连接中断或长时间超时。
把写流量切到备用主库（或提升从库），验证业务可以恢复正常写入。
恢复原主库，重新确认节点状态回归ONLINE，然后让流量回切。

这个演练每次都能发现一两个配置问题，比如某次我们发现SHUN超时阈值设置太短，主库短暂抖动就被踢出集群，结果导致多余的主从切换。代理层的故障转移是“最后一道防线”，它必须经过充分验证，不能靠侥幸。

7. 尾声：一点体己话

文章写到这儿，核心内容基本都覆盖了。最后分享一点我个人的感受。分布式数据库代理这个组件，本质上是把“连接管理、路由、治理”这些脏活累活集中到一个层，它处在应用和数据库之间，看似透明，实则责任重大。它不能解决分布式事务、不能解决最终一致性、更不能让你拍脑袋就把单库“分布式”了——它解决的是“接入与路由”的问题。先想清楚路由维度、再选组件、再动手部署，这个顺序不能乱，否则只会把原本在应用层就已经很混乱的状态，原封不动地搬到代理层重新上演一遍。从我们团队上线代理层到现在，系统稳定性提升非常明显，业务开发只需要连接一个地址，DBA也能在代理层统一做读写拦截和审计。要说还有什么可以继续深挖的，我觉得是结合现有的监控体系把代理层的SQL审计数据沉淀下来，做更细化的调用分析和容量规划。这篇分享就到这里，如果你也在折腾数据库代理层，欢迎交流想法。