高并发MySQL救星：ProxySQL核心原理与读写分离实战

1. 高并发来了，单机MySQL到底死在哪一步

做后端的朋友应该都有过这种经历：业务量刚开始起量，数据库先是慢查询变多，然后是连接数被打满，最后CPU直接飙到90%以上，整个服务跟着雪崩。我曾经维护过一套单机MySQL，QPS峰值到3000左右时，连接池就开始报错，应用侧全部卡在获取连接上，数据库端的Threads_running动不动就跳到几十上百，线上告警响个不停。

先说一个反直觉的结论：大多数业务系统在达到真正意义上的"数据库瓶颈"之前，最先挂掉的其实是连接层。MySQL默认的连接数上限是151，单条连接哪怕什么都不做，也要占用一个线程和一部分内存。一旦应用实例增多、连接池扩大，单个MySQL实例能支撑的并发连接数很快就到天花板，可是CPU可能才用了30%——这就是典型的"连接瓶颈"掩盖了真正的计算瓶颈。

另一个容易被忽略的死法是主从延迟。很多团队做读写分离，主库写、从库读，但应用直连从库，要么在代码里自己维护多个数据源，要么靠Spring的AbstractRoutingDataSource做动态切换。这种方案有几个天然缺陷：第一，数据库拓扑变了要改代码、要发版；第二，从库挂了应用不会自动摘除；第三，连接池每个节点各自为政，没法全局统一管控。你想想，一个从库宕机，应用还得等连接超时才报错，期间有多少请求会失败？

所以，高并发场景往下走，基本都会走到两个方向：一是分库分表，用ShardingSphere或MyCat这类中间件做分布式改造；二是在单体MySQL外面加一层连接管理、读写分离、流量治理的代理——ProxySQL就是这个位置上的工具。

ProxySQL能做的事，简单概括就是：统一收口所有发往MySQL的SQL流量，通过连接池复用后端连接，按规则把读写流量分发到不同的MySQL实例，还能实时观测每条SQL的响应时间、执行频率和错误统计。它本身几乎不解析SQL语义，只做文本匹配和路由分发，性能开销极小，在常规硬件上可以支撑每秒几万到十几万的转发量。

这篇文章我打算把ProxySQL从原理到落地一次讲透，包括架构设计、安装部署、读写分离配置、监控排障、高可用部署，以及实际运维中踩过的坑。不是那种"复制粘贴几条命令就跑路"的教程，而是把每一步背后为什么要这样做、不做会踩什么坑都写清楚。

2. 先吃透ProxySQL的核心逻辑：三层配置、连接池、查询路由

2.1 三层配置结构：从磁盘到运行时，配置可以热更新

ProxySQL最核心的设计是三明治结构：disk、memory、runtime三层配置。理解这三层，基本就理解了一半的ProxySQL。

• disk层：持久化到磁盘上的SQLite数据库，重启不丢，相当于配置文件落地版。
• memory层：内存中的标准配置，通过LOAD ... TO MEMORY或LOAD ... TO RUNTIME加载进来，修改的是这一层的值。
• runtime层：真正在生效的配置，处理请求时线程直接读取这一层的数据，不经过任何中间转换，所以通过LOAD ... TO RUNTIME热加载时，不需要重启进程就能让新配置立即生效。

这个设计解决了一个核心痛点：数据库中间件的配置变更，不应该成为影响线上流量的"大动作"。改配置、加载、验证、发现问题再回滚，全部可以在几秒内完成，不需要重启进程，也不会断开现有连接。

初次接触的时候我犯过一个糊涂，以为改完配置就完事了。实际上，通过INSERT或UPDATE改的是memory层的临时态，还需要执行LOAD命令推到runtime层才会生效；而要保证重启后配置还在，还得执行SAVE命令写回disk层。完整的操作链是：修改memory → LOAD到runtime → 验证 → SAVE到disk。漏掉最后一步，重启后配置就丢了，这个一定要注意。

2.2 前端连接池和后端连接池，一个MySQL能顶上千连接

ProxySQL是代理模式，应用不直接连MySQL，而是连ProxySQL。这意味着连接被分成两段：

• 前端连接：应用 ↔ ProxySQL。
• 后端连接：ProxySQL ↔ MySQL。

这个拆分最重要的价值在于：MySQL端能保持一个稳定的小规模连接池，而应用端的连接数上限可以开得很大。比如后端连接池只维持100条连接，但前端可以让5000个应用连接排队使用这100条后端连接。后端连接的数量不会随着应用实例的扩容而增长，从根本上解决了MySQL连接数被打满的问题。

后端连接的复用在ProxySQL里是自动完成的，它会根据mysql_servers表的配置，为每个MySQL节点维护一个连接池。连接池中连接的新建、回收、超时断开都由ProxySQL自己管理，应用无感知。连接超时相关的参数主要有mysql-connect_timeout_server_max、mysql-connection_max_age_ms这些，在global_variables里可以调，默认值基本能覆盖大多数场景。

2.3 查询路由：不是智能解析，是优秀的规则引擎

ProxySQL对SQL的处理方式非常务实。它不解析SQL的语义，而是把SQL文本拿出来，去和mysql_query_rules规则表里预定义的正则表达式做匹配，命中哪条规则就执行哪条规则定义的动作。

这看起来简单，实际用起来很灵活。你可以按SQL类型路由，比如SELECT开头的走从库；也可以按表名路由，比如包含order_的表走主库；还可以按用户路由、按客户端IP路由、按关键字路由。甚至可以做到"某一条特定的SQL走某个特定实例"这种颗粒度。

比如这种规则表：

sql复制INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply)
VALUES (1, 1, '^SELECT.*', 20, 1);

意思是：以SELECT开头的SQL，发给hostgroup 20。对，规则表就是这样直接，不需要写什么复杂逻辑。

不过也因为是不解析文本，所以正则表达式的编写质量非常关键。^SELECT.*看起来匹配了所有SELECT语句，但也会把WITH ... SELECT ...或某些以注释开头的查询漏掉、误判，后面我会单独讲。

2.4 为什么是ProxySQL，而不是MyCat或MySQL Router

选型环节，我见过很多团队纠结。这里说一下我的个人评估。

如果你的核心矛盾是"MySQL连接数即将耗尽、读写混跑、从库故障缺乏自动摘除"，ProxySQL是最合适的，安装简单、配置直观、性能开销小。如果你需要的是"一张表拆到多个库"，那ProxySQL不合适，它不管分片，那是MyCat和ShardingSphere的领域。MySQL Router则更轻量，但连接池、健康检测、日志统计这些能力明显弱于ProxySQL。

3. 安装部署与初始化配置：不重启进程的热加载是怎么做到的

3.1 选型对比：二进制包、Yum源、Docker

ProxySQL的安装方式主要有三种，我实际都试过，说下各自的适用场景。

• Yum/Apt源：官方维护了各主要发行版的源，安装最省事，适合生产环境通过配置管理工具批量部署。
• 二进制包：解压即用，适合快速验证或离线环境，但需要自己维护systemd服务。
• Docker：适合本地测试和CI环境，快速起一个实例做验证非常方便，但生产环境我不建议容器化跑ProxySQL——这不是说容器不行，而是它本身很轻，没必要多一层容器编排的复杂度，直接裸机/虚拟机部署更利于排查网络问题。

我用的方式是：生产环境Yum源安装，测试环境Docker一把梭。

Yum安装流程大致是：

bash复制cat >> /etc/yum.repos.d/proxysql.repo <<'EOF'
[proxysql_repo]
name=ProxySQL YUM repository
baseurl=http://repo.proxysql.com/ProxySQL/proxysql-2.4.x/centos/$releasever
gpgcheck=1
gpgkey=http://repo.proxysql.com/ProxySQL/proxysql-2.4.x/repo_pub_key
EOF

yum install -y proxysql

装完之后，先启动一下：

bash复制systemctl start proxysql
systemctl enable proxysql

注意，ProxySQL默认监听两个端口：6033是给应用连的MySQL协议端口，6032是管理端口。管理端口走的是类似MySQL的文本协议，方便你用mysql客户端连上去执行管理操作。

3.2 用mysql客户端连接管理口，开始你的第一轮操作

默认管理员账号是admin:admin，连接命令：

bash复制mysql -h127.0.0.1 -P6032 -uadmin -padmin

连上之后，你会看到类似于MySQL的命令行界面。注意，这里执行的不是MySQL的标准语法，而是ProxySQL自己的管理命令。最常用的几个：

sql复制SHOW DATABASES;
USE main;
SHOW TABLES;

main库里存放了所有核心配置表：mysql_servers、mysql_users、mysql_query_rules、global_variables等。这里有第一次用容易搞混的点：main库的表是活的，可以直接用SELECT查看，也可以用INSERT/UPDATE/DELETE修改，改完靠LOAD ... TO RUNTIME生效。

查看当前生效配置是否正常：

sql复制SHOW PROCESSLIST;

这一步能看到当前通过ProxySQL处理的所有会话。因为我还没有配置任何后端MySQL，所以现在列表是空的。

3.3 第一步就把admin密码改掉，别学网上那些教程

很多教程到这里就结束了，直接开始配后端。我要多说一句：把默认的admin密码改掉再上线，这是最基础的安全习惯。

sql复制UPDATE global_variables SET variable_value='your_strong_pass' WHERE variable_name='admin-admin_credentials';
LOAD ADMIN VARIABLES TO RUNTIME;
SAVE ADMIN VARIABLES TO DISK;

admin-admin_credentials配置控制的是管理口登录账号。同样地，admin-stats_credentials控制的是stats库的只读账号，我一般也会单独设一个，后面监控用。

这里提前交代一个容易被忽略的点：改完admin-admin_credentials后，当前已建立的连接不会断开，下次登录才用新密码。如果你改了之后发现无法登录，先检查一下是不是连接了错误的端口，管理口是6032，不是6033。

4. 核心配置实战：从0到1让读写分离跑起来

4.1 配置mysql_servers：告诉ProxySQL后端有哪些MySQL

以一套经典的一主两从架构为例，主库IP 192.168.1.10，从库 192.168.1.11、192.168.1.12。

sql复制INSERT INTO mysql_servers(hostgroup_id, hostname, port, weight, max_connections) VALUES
(10, '192.168.1.10', 3306, 100, 200),
(20, '192.168.1.11', 3306, 50, 200),
(20, '192.168.1.12', 3306, 50, 200);

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

这里我用了两个hostgroup：10是主库组，20是从库组。weight是权重，影响从库间的流量分配。max_connections是ProxySQL对这个节点保持的最大后端连接数，不要设置得太小，否则高峰期后端连接不够用会排队，建议至少给到200。

做完这一步，可以先验证一下后端节点是否被正常管理：

sql复制SELECT hostgroup_id, hostname, port, status, weight FROM mysql_servers;

如果status显示ONLINE，说明节点在线。如果显示SHUNNED或OFFLINE_SOFT，后面排查健康检测配置。

4.2 配置mysql_replication_hostgroups：让ProxySQL理解主从拓扑

仅仅告诉ProxySQL后端有哪些节点还不够，它还需要知道谁是主、谁是从。通过mysql_replication_hostgroups表，把读写组与复制拓扑关联起来：

sql复制INSERT INTO mysql_replication_hostgroups(writer_hostgroup, reader_hostgroup, comment)
VALUES (10, 20, 'rw-split');

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

这张表的核心作用是让ProxySQL具备自动识别主从角色的能力。它会定期检查后端MySQL的read_only参数：read_only=OFF的节点归入writer组，read_only=ON的节点归入reader组。这样即使主从发生了切换，只要复制关系配置正确，ProxySQL能自动把节点调整到对应的hostgroup，不需要人工介入。

注意一点：MySQL从库都要设置read_only=ON，这不只是安全习惯，也是让ProxySQL正常分组的前提。如果你从库没开read_only，ProxySQL可能把多个节点都识别成主库，路由就乱了。

4.3 配置监控账号：没有监控，故障自动摘除就是空话

ProxySQL需要连到后端MySQL去做健康检查和主从角色探测。这个账号的权限不复杂，但必须存在：

sql复制-- 在后端MySQL主库上执行
CREATE USER 'proxysql_monitor'@'%' IDENTIFIED BY 'monitor_pass';
GRANT REPLICATION CLIENT ON *.* TO 'proxysql_monitor'@'%';

然后在ProxySQL管理口配置监控账号：

sql复制UPDATE global_variables SET variable_value='proxysql_monitor' WHERE variable_name='mysql-monitor_username';
UPDATE global_variables SET variable_value='monitor_pass' WHERE variable_name='mysql-monitor_password';
LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;

配置完之后，等几秒再看监控状态：

sql复制SELECT * FROM monitor.mysql_server_connect_log ORDER BY time_start DESC LIMIT 5;
SELECT * FROM monitor.mysql_server_ping_log ORDER BY time_start DESC LIMIT 5;

正常情况下，这两张表应该能看到成功的记录。如果失败了，优先检查：网络是否通、账号密码是否正确、MySQL是否允许该来源IP访问。很多问题是卡在MySQL账号的host匹配上，'proxysql_monitor'@'%'和实际来源IP不匹配，MySQL的账号匹配规则很严格，建议直接写成ProxySQL服务器的IP，比如'proxysql_monitor'@'192.168.1.20'。

4.4 配置mysql_users：让应用能通过ProxySQL访问数据库

现在开始配置连接ProxySQL的账号，这个账号会映射到后端MySQL的真实账号。

sql复制INSERT INTO mysql_users(username, password, default_hostgroup, max_connections) VALUES
('app_user', 'app_pass', 10, 200);

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

default_hostgroup是默认路由目标，意思是：没有命中任何查询规则时，SQL发往哪个hostgroup。这里我设置为10，也就是主库组。这样做的好处是，就算某条SQL的规则没匹配到，也会走主库而不是报错——这保证了数据不会因为路由错误而出现"查不到刚写入的数据"的情况。

一个容易踩的坑是：mysql_users里配置的账号，必须同时存在于后端MySQL上，且权限要正确。ProxySQL本身不做权限校验，它只是把连接凭证转发给后端。如果后端MySQL没有这个账号，应用通过ProxySQL连接时会报认证失败。

所以一定要在MySQL主库上先建好应用账号：

sql复制CREATE USER 'app_user'@'192.168.1.%' IDENTIFIED BY 'app_pass';
GRANT SELECT, INSERT, UPDATE, DELETE ON yourdb.* TO 'app_user'@'192.168.1.%';

4.5 最关键的一步：配置查询路由规则，让SELECT去从库、其他去主库

后端节点和账号都配好了，但此时所有流量都走默认hostgroup，还没有实现读写分离。真正让读写分流的，是mysql_query_rules表。

sql复制INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply) VALUES
(1, 1, '^SELECT.*', 20, 1),
(2, 1, '^SHOW.*', 20, 1);

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

规则说明：

• rule_id越小优先级越高，ProxySQL按ID从小到大依次匹配。
• active=1表示规则生效。
• match_pattern是正则表达式，匹配的是SQL文本。
• destination_hostgroup是命中后发往的目标组。
• apply=1意味着命中后不再继续匹配后续规则。

这条配置的意图很清楚：SELECT和SHOW开头的查询，统统走从库组；其他SQL（INSERT、UPDATE、DELETE）没有规则命中，走默认hostgroup主库组。

执行完LOAD后，规则实时生效，我习惯先验证一下再收工：

sql复制SELECT rule_id, active, match_pattern, destination_hostgroup FROM mysql_query_rules;

然后从应用侧用app_user连接6033端口，执行一条SELECT 1，再到ProxySQL管理口查看路由结果：

sql复制SELECT username, hostgroup, digest_text FROM stats.stats_mysql_connection_pool ORDER BY time_connected DESC LIMIT 5;

或者更直接，查看当前连接的hostgroup：

sql复制SELECT s.hostgroup, s.srv_host, s.queries, s.bytes_recv FROM stats.stats_mysql_connection_pool s;

这里会看到连接被分配到了hostgroup 20（从库组），说明路由规则生效了。

4.6 一条SQL的完整旅程：从进入到返回，到底发生了什么

为了让你彻底理解这套机制，我完整走一遍：应用通过JDBC发送SELECT * FROM orders WHERE user_id = 123。

1. 请求到达ProxySQL的6033端口，连接进入连接池管理，ProxySQL拿到SQL文本。
2. ProxySQL从连接对应的mysql_users配置中，确定用户是app_user，默认组是10。
3. 查询规则引擎从上到下匹配，规则1的^SELECT.*命中，目标hostgroup被改为20。
4. ProxySQL从hostgroup 20的后端连接池里，挑一条空闲连接（这里受从库负载和权重影响，两个从库会按比例分摊）。
5. SQL发往选中的从库，从库执行完，结果集沿原路返回给应用。
6. 连接归还给连接池，等待下一个查询使用。

整个过程都在ProxySQL用户态完成，涉及的内存拷贝和正则匹配开销都很小。这也是它能扛高并发的底气。

5. 排障与监控：高并发下如何精准定位慢SQL和连接问题

5.1 stats_mysql_query_digest：比慢查询日志更好用的SQL统计

线上出问题的时候，最怕的不是慢SQL本身，而是不知道慢SQL是哪些。MySQL的慢查询日志要开启、要等时间窗口、还要去分析日志，而ProxySQL本身就内置了SQL统计能力，它会把每一条SQL做正则归一化，按digest汇总统计。

先看数据：

sql复制SELECT digest_text, count_star, sum_time, avg_time FROM stats.stats_mysql_query_digest
ORDER BY sum_time DESC LIMIT 10;

关键字段：

• digest_text：归一化后的SQL文本，例如SELECT * FROM orders WHERE user_id = ?。
• count_star：这个SQL被执行的次数。
• sum_time：总耗时（微秒）。
• avg_time：单次平均耗时。

我排查慢SQL的顺序是：先按sum_time排序，找到消耗总时间最多的SQL；再看avg_time，如果平均耗时也高，说明这条SQL本身性能有问题，去数据库执行计划分析索引；如果avg_time不高但count_star极高，说明是高频查询，需要考虑缓存或改批量查询。

有时会遇到一种情况：SQL在数据库端执行很快，但从ProxySQL统计看耗时不低。这时候要怀疑是不是连接池阻塞了——后端连接不足，SQL在ProxySQL里排队，统计里也会体现出来。这种情况去查stats_mysql_connection_pool，看ConnUsed、ConnFree和ConnWait数字，如果等待连接的时间持续偏高，说明后端连接池不够用了，适当调大max_connections或增加从库节点。

5.2 stats_mysql_commands_counters：量化每种SQL操作类型的比例

除了单条SQL的明细，我还会看总体的读写比例：

sql复制SELECT Command, Total_Time_us, Total_cnt, Avg_Time_us FROM stats_mysql_commands_counters;

这张表统计了各类SQL命令的执行次数和耗时分布。通过它，你能直观看到系统的读占比是多少。比如SELECT的Total_cnt占85%、INSERT占10%、UPDATE占5%，那读写分离的收益就非常大。如果读占比很低，读写分离带来的提升就有限，可能会更倾向于考虑其他优化手段。

5.3 从库延迟和高可用状态：别等报警了才想起来看

ProxySQL的健康检查不只是探活，还能检测复制延迟。相关的表是monitor.mysql_server_replication_lag_log：

sql复制SELECT * FROM monitor.mysql_server_replication_lag_log ORDER BY time_start DESC LIMIT 10;

当从库延迟超过阈值时，ProxySQL会自动把该节点标记为SHUNNED，暂停向它分发新请求，避免读到过旧的数据。这个阈值由变量mysql-server_replication_lag_threshold控制，默认是10秒。如果业务对读一致性要求高，可以调小，比如3秒。

这一点非常实用。传统的读写分离代码方案里，从库延迟只能靠告警发现了再摘除，ProxySQL是自动处理的。不过也提醒一句：延迟检测依赖REPLICATION CLIENT权限，监控账号如果权限不全，延迟检测会失效，节点可能一直正常服务但流量分发不受影响，这个问题排查起来比较隐蔽，建议定期检查监控日志表。

5.4 连接层告警：一个容易漏掉的信号

很多团队盯着CPU、内存、慢SQL，但忽略了连接等待。高并发下，数据库本身可能没打满，但连接池已经满了，所有的请求都在排队等待空闲连接，这会导致应用侧的RT急剧上升。

在ProxySQL里，看连接池状态的SQL：

sql复制SELECT hostgroup, srv_host, MaxConnUsed, ConnUsed, ConnFree, ConnWait FROM stats.stats_mysql_connection_pool;

如果ConnUsed接近MaxConnUsed且持续不降，说明后端连接池不够，需要扩容或优化连接配置。ConnWait不为0，说明有请求等待连接。这两个指标可以作为告警项，比直接盯数据库的Threads_running更早暴露问题。

6. 高可用保障：当主库挂了，ProxySQL怎么接手

6.1 主从切换时，ProxySQL会不会自动感知

先说结论：如果你在mysql_replication_hostgroups里配置了主从组，并且监控账号正常，那么当主库宕机或者read_only状态发生变化，ProxySQL会自动感知并调整hostgroup映射，不需要重启。

具体来说，ProxySQL的monitor线程会定期检查每个MySQL节点的状态，对于writer组的节点，如果它连不上了，节点会被标记为SHUNNED，不再接收新请求。如果新提升的主库read_only变成了OFF，ProxySQL会把它自动识别并移动到writer组。

但要注意一个前提：自动感知的是"角色变化"，不是"自动切换主从"。也就是说，MySQL层面的主从切换（比如用MHA、Orchestrator）得先完成，ProxySQL负责的是切换完成后让路由规则自动适配，而不是自己去执行CHANGE MASTER TO。

这个配合逻辑一定要理解清楚。我见过不少人以为ProxySQL能自动完成主从切换，实际上它做不到，也不能让它做——主从切换涉及数据一致性、日志位点、半同步确认等一堆复杂逻辑，好好交给专门的HA工具处理。

6.2 网关层面的补偿：从库宕机自动摘除

主库切换总有意外，但从库宕机是更常见的事件。当某个从库节点不可达时，ProxySQL的监控线程会在mysql-monitor_connect_interval间隔内发现故障，把节点标记为OFFLINE_SOFT或SHUNNED，随后不再往该节点分发新查询。期间其他从库会平滑承接所有读流量，应用侧几乎无感。

这里有个加分项是权重调整。当某个从库被摘除，剩余的从库会按各自权重自动分担流量，不需要你做任何操作。而如果所有从库都挂了，读请求会被路由到writer组（前提是规则里配置了destination_hostgroup的fallback），这个行为可以通过规则设计来演变成"宁可走主库，也不要报错"。

6.3 ProxySQL本身的冗余：别把代理层变成单点

把所有的应用流量都收到ProxySQL之后，你自然会产生一个新的担忧：ProxySQL自己挂了怎么办？

是的，所有架构改动最终都要对得起"可用性"三个字。ProxySQL跑两个实例并共享配置，是一个常见的思路，通常我们用Keepalived或LVS给两个ProxySQL实例做一个VIP漂移，或者用ProxySQL自己的集群功能来同步配置。

我用的方式是：两台ProxySQL + Keepalived虚IP + 配置自动同步。应用只连VIP，正常情况下流量都落在主ProxySQL上；主ProxySQL宕机，Keepalived把VIP漂移到备机，同时备机通过proxysql自带的Scheduler脚本自动从主库拉取配置（或者直接让两个ProxySQL自己组成集群）。

ProxySQL企业版和多实例版本（2.x开始）支持原生的Cluster同步功能，通过配置proxysql_servers表并启用集群同步，多个ProxySQL实例之间会自动同步配置，不需要额外脚本。社区版可以依赖配置管理工具（如Ansible）做定时同步，或者像我之前那样用crontab + mysqldump级别的简单方案——把main库里的配置表定时导出、导入到备机。配置变化频率不高，定期同步足够。

关于VIP漂移的细节这里不展开，但有一点必须提醒：应用连接ProxySQL时，记得在JDBC连接串里配置合理的connectTimeout和socketTimeout。否则VIP漂移导致连接断开时，应用可能会长时间卡在TCP超时上，这种问题在故障切换时反而比MySQL本身更影响体验。

6.4 连接池预热：别在流量高峰重新建立连接

高可用切换最怕的是冷启动。当新的ProxySQL实例接管流量时，连接池是空的，所有应用连接都要逐一建立后端连接。后端MySQL的连接建立（TCP握手+认证+权限检查）是相对昂贵的操作，如果瞬间有几千个连接同时涌入，数据库很可能被压垮。

缓解办法是：提前把ProxySQL预热。启动后立即手动触发一批连接，比如执行SELECT 1，让连接池先建立一部分后端连接。或者更直接的办法是：在业务的低峰期做切换演练，确保ProxySQL的连接池在切换前已经处于预热状态。

另一个技巧是设置mysql-free_connections_pct，控制连接池保留的最小空闲连接比例，避免低峰期把连接全部关闭。

7. 踩坑实录：全网也没有人来提醒你的那些问题

7.1 正则误伤：一条不到20字符的正则，让写操作跑到了从库

我先说一个我真实踩过的坑。当时为了把SELECT分流到从库，写了这条规则：

sql复制INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply)
VALUES (1, 1, '^SELECT.*', 20, 1);

上线几天后，发现一个诡异的问题：某条存储过程返回的数据总是比其他系统慢几秒才更新，排查了很久，最后在ProxySQL的stats_mysql_query_digest里发现，这条存储过程的CALL xxx()查询直接命中了从库组。

原因就是正则：存储过程调用语句实际文本是CALL proc_name()，不匹配^SELECT，看起来不该命中。但问题是存储过程内部发出的SELECT语句，ProxySQL并不感知——它只看到入口SQL是CALL，所以默认全走了主库。而我那条规则的^SELECT没有约束表名，导致存储过程内部的SELECT也被路由到了从库。

解决办法：把规则加上约束，比如只让纯查询语句走从库，存储过程统一走主库：

sql复制DELETE FROM mysql_query_rules WHERE rule_id=1;
INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply)
VALUES (1, 1, '^SELECT .*LIMIT [0-9]+$', 20, 1);

当然实际生产环境不可能只匹配LIMIT查询。更稳妥的做法是：能用正则精确匹配的，绝不写宽泛表达式；实在要宽泛匹配，务必在测试环境压测验证。

7.2 从库没开read_only，两个"主库"同时存在

另一个工作里遇到的事故：某团队的MySQL从库read_only没设，导致ProxySQL把主从两个节点都判定为writer，读写分离失效，部分读流量直接打到主库。主库压力陡增，而业务看到的现象是"数据库CPU突然飙升但慢SQL没有增多"。

排查路径：先看mysql_servers表的status和hostgroup分配。

sql复制SELECT hostgroup_id, hostname, port, status, weight FROM mysql_servers;

结果两个节点都在hostgroup 10（writer组）。再看后端MySQL变量：

sql复制SHOW VARIABLES LIKE 'read_only';

从库的read_only是OFF。修复方案很简单：在从库上执行SET GLOBAL read_only=ON，然后ProxySQL的监控线程在下个周期就能把节点重新归类到reader组。

这里也提醒一下：如果业务有需求要在从库上做临时写入，记得临时打开read_only后再关掉，或者干脆用super_read_only，一切以ProxySQL的分组结果为准。

7.3 MySQL 8.0默认认证插件，连接认证总是失败

MySQL 8.0的默认认证插件是caching_sha2_password，而ProxySQL连接MySQL时，如果账号用了这个插件，可能出现版本兼容问题。

我之前碰到的情况是：ProxySQL的监控账号是MySQL 8.0的，配置完全正确，但monitor.mysql_server_connect_log里全是失败记录，错误信息提示认证插件不支持。

解决办法有两个：

• 在MySQL侧创建账号时指定使用mysql_native_password插件：

sql复制CREATE USER 'proxysql_monitor'@'192.168.1.20' IDENTIFIED WITH mysql_native_password BY 'monitor_pass';

• 或者把ProxySQL升级到2.x版本，新版本已经适配了caching_sha2_password。

如果用的是ProxySQL 1.x，还是老老实实用mysql_native_password靠谱。另外，应用侧连接MySQL 8.0如果也遇到类似认证问题，同理可以用mysql_native_password先顶上。

7.4 连接被KILL：ProxySQL的Scheduler要小心使用

ProxySQL有个Scheduler功能，可以定期执行一些脚本，比如做配置备份、表状态检查等。但Scheduler的执行账号是admin，且执行环境可能不是你预期的那样，如果脚本里有危险操作，后果很严重。

我自己就被坑过一次：写了一个Scheduler脚本定期清除过期监控数据，结果脚本里引用的环境变量没设置，导致它去删除了一张错误的表。幸好当时只是清掉了一些历史统计表，没有影响核心配置。经历了那次之后，我现在对Scheduler的使用原则是：能不用就不用，必须用了，脚本务必在命令行手动跑过完整测试，而且脚本里禁止任何DROP TABLE和TRUNCATE操作。

7.5 连接池的连接泄漏

ProxySQL虽然自身管理连接池，但应用侧的连接使用不当，仍然可能导致连接池连接被占满。典型的场景是应用侧忘记关闭连接，或者在事务里执行了长时间不提交的SQL。这种情况下，连接不会被ProxySQL强制回收，它会一直保持占用状态。

解决思路是围绕应用侧做排查和治理，比如检查连接池配置、设置socketTimeout、监控应用线程栈，而不是试图在ProxySQL层做强制回收。

8. 进阶优化：几个让性能再进一步的小配置

读写分离跑通后，还有几个优化点可以顺手做掉，让整体性能更加平滑。

一是开启慢SQL日志。ProxySQL的日志虽然不如MySQL的慢查询日志那么详细，但stats_mysql_query_digest里已经按耗时排好了序，定期看一眼就够。也可以设置mysql-query_digests相关参数，控制统计表保留的数据量。默认这个表的数据量很大，如果内存受约束，可以调小mysql-query_digests_max_digest_length或增加清理频率。

二是利用mysql_query_rules的cache_ttl做SQL级缓存。ProxySQL可以按规则设置缓存，命中规则的SQL会自动缓存结果集，后续相同查询直接返回缓存，不再走后端MySQL。这个功能很实用，尤其适合热点查询比较固定的场景。不过要谨慎使用，一旦数据更新，缓存没有及时失效，会造成数据不一致。我的经验是：只对低频变更的表开启规则级缓存，并且在业务允许一定延迟的场景下启用。

sql复制INSERT INTO mysql_query_rules(rule_id, active, match_pattern, cache_ttl, apply)
VALUES (20, 1, '^SELECT.*FROM config.*', 60000, 1);

上面的意思是，所有查config表的SELECT，结果缓存60秒。注意cache_ttl单位是毫秒，别把6000当分钟配置了，那缓存6秒就没了。

三是调整连接池参数。mysql-max_connections控制单个后端节点的最大连接数，mysql-max_allowed_packet控制最大包大小。如果业务有大量大字段查询（比如BLOB），max_allowed_packet默认值可能不够，会导致查询报错。我遇到过因为max_allowed_packet太小导致的应用报错，所以建议提前测一下业务最大的SQL包体大小，再做调整。

四是对stats_mysql_query_digest定期清理。统计表是长期累积的，如果业务SQL种类特别多，这个表会持续膨胀，虽然不至于拖垮ProxySQL，但会影响查询性能。我一般写个定时任务，每周清理一次旧的统计记录：

sql复制DELETE FROM stats.stats_mysql_query_digest WHERE time > DATE_SUB(NOW(), INTERVAL 7 DAY);

这类操作在低峰期执行即可。

说实话，我见过不少团队在MySQL参数调优上花了很多精力，但一开始的方向就错了：他们让几千个连接直接怼在MySQL上，MySQL再强也扛不住这种低效的使用方式。ProxySQL的价值不在于把单条SQL从100ms优化到10ms，而在于让MySQL在最健康的状态下工作——连接数可控、读写分离、故障自动摘除、慢SQL可观测。这些能力叠加起来，产生的整体效果往往是翻倍的。

如果你正在为高并发下的MySQL发愁，我的建议是从连接治理和读写分离做起，先别急着上分库分表。ProxySQL这套方案足够轻量，也足够稳定。当然，没有银弹，ProxySQL也解决不了SQL本身性能极烂的问题，它只是把该暴露的问题提前暴露出来，把该治理的环节治理起来。踩过这些坑之后，我最大的体会是：中间件不是装完就完事，真正的技术含量藏在维护和排障里。