mysql如何实现读写分离配置_在Proxy端或中间件配置读写规则-mysql教程-PHP中文网

ProxySQL读写路由需手动配置mysql_query_rules表：首条规则匹配^SELECT.（不含FOR UPDATE）至读组20，次条兜底匹配.至写组10，规则active=1且apply=1后执行LOAD+SAVE生效。

mysql如何实现读写分离配置_在proxy端或中间件配置读写规则

ProxySQL 中如何配置读写路由规则

ProxySQL 的读写分离不是靠自动识别 SELECT 或 INSERT 就完事的，它依赖明确的 mysql_query_rules 表配置。默认不启用任何规则，必须手动插入匹配条件和目标 hostgroup，否则所有流量都走默认 hostgroup（通常是写组）。

常见错误是只配了主从后端、没加规则，结果应用连上去还是全打到主库；或者规则顺序错乱，SELECT 被更宽泛的正则先匹配，导致误入写组。

先确认主从已注册进 mysql_servers 表，且状态为 ONLINE
确保主库在 hostgroup 10（写组），从库在 hostgroup 20（读组），这只是惯例，实际可自定义
向 mysql_query_rules 插入两条核心规则：一条匹配以 SELECT 开头、不带 FOR UPDATE 的语句，destination_hostgroup=20；另一条兜底，把其余所有语句（含事务、写操作、带锁读）路由到 hostgroup=10
规则 active=1 且 apply=1 才生效；修改后必须执行 LOAD MYSQL QUERY RULES TO RUNTIME，再 SAVE MYSQL QUERY RULES TO DISK 持久化

示例关键 SQL：

INSERT INTO mysql_query_rules (rule_id,active,match_digest,destination_hostgroup,apply) VALUES (1,1,'^SELECT.*',20,1);
INSERT INTO mysql_query_rules (rule_id,active,match_pattern,destination_hostgroup,apply) VALUES (2,1,'.*',10,1);
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;

为什么不能只靠 SQL 类型判断读写

单纯用 SELECT / UPDATE 关键字切分读写，在真实业务中极易出错。比如 SELECT ... FOR UPDATE 是写意图，必须走主库；事务内第一条语句是 SELECT，后续却有 UPDATE，整个事务也必须绑定主库，否则会读到旧数据或报错。

ProxySQL 本身不解析事务上下文，所以这类逻辑得靠应用配合或额外规则兜底。

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

SELECT ... FOR UPDATE 和 SELECT ... LOCK IN SHARE MODE 必须显式排除在读规则外，建议用 match_pattern 写负向匹配，或单独建 rule 优先级更高地路由到写组
对强一致性要求的读（如用户刚下单查订单），应用应主动加注解或设置 session 变量（如 SET SESSION sql_route_to='master'），再配合 ProxySQL 的 match_digest + apply=0 + 下一条规则捕获该变量
DDL 语句（CREATE/ALTER）必须走主库，但它们不一定是 INSERT/UPDATE/DELETE，需单独规则覆盖

MySQL Router 与 ProxySQL 在规则配置上的差异

MySQL Router 是官方轻量代理，定位就是“开箱即用”的读写分离，但它不支持自定义 SQL 级路由规则。它的读写分离仅基于连接 URL 的 read-only 属性或客户端发起连接时指定的 role（如 PRIMARY / SECONDARY），底层靠 MySQL Group Replication 或 InnoDB Cluster 的元数据自动识别节点角色。

MySQL Router 无法识别单个 SQL 是读是写，也不支持正则匹配、缓存、重写等高级功能
它适合已部署 MGR 集群的场景，配置只需指定 metadata-cache 和 routing 段，无需维护 query rules 表
ProxySQL 则适用于传统主从架构，规则灵活，但必须人工维护 mysql_query_rules，且每次变更都要 reload
如果用 MySQL Router 却没上 MGR，它只能做静态路由（比如固定把某端口映射到某 IP），谈不上真正的读写分离

配置后如何验证规则是否生效

最直接的方式不是看监控面板，而是用 PROXYSQL ADMIN 接口查命中统计。连上 6032 端口后，查 stats_mysql_query_rules 表里的 hits 字段，能清楚看到每条规则被触发了多少次。

如果 SELECT 规则 hits 为 0，说明应用发的语句根本没匹配上——检查是否带前导空格、大小写、换行符，match_digest 默认区分大小写且不忽略空白
如果写规则 hits 远高于读规则，可能是读规则被跳过，检查 rule_id 顺序和 apply 值：只有 apply=1 的规则才会终止匹配流程
临时开启 mysql-monitor 模块的查询日志（monitor_username 需有 PROCESS 权限），可抓取原始语句验证匹配逻辑
别依赖 SHOW PROCESSLIST 看后端连接，因为 ProxySQL 复用连接，实际后端连接数 ≠ 应用并发数