ProxySQL读写路由需手动配置mysql_query_rules表：首条规则匹配^SELECT.（不含FOR UPDATE）至读组20，次条兜底匹配.至写组10，规则active=1且apply=1后执行LOAD+SAVE生效。
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，整个事务也必须绑定主库，否则会读到旧数据或报错。
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
ProxySQL 本身不解析事务上下文，所以这类逻辑得靠应用配合或额外规则兜底。
-
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 复用连接，实际后端连接数 ≠ 应用并发数
真正难的不是配通，而是让规则覆盖住所有边界情况：隐式事务、存储过程里的动态 SQL、ORM 自动生成的奇怪语法……这些往往要在线上压测时才暴露。
