代理中间件无法替代mysql权限系统，因其仅按sql类型路由而不校验表级权限；真正权限判断由后端mysql的mysql.user等系统表执行，proxysql无acl_check能力，必须结合mysql原生权限、proxysql路由规则与应用层约束协同实现表级读写分离。
不能直接靠代理中间件做表级读写权限分离——它不处理权限校验，只做路由。 ProxySQL、MaxScale 这类代理中间件本身不检查 SELECT 是否被允许访问某张表，也不拦截 UPDATE t1 而放行 UPDATE t2。它们的“读写分离”是基于 SQL 类型（SELECT vs INSERT/UPDATE/DELETE）或语句特征（如是否含 FOR UPDATE）做路由，不是权限控制。真要实现表级读写隔离，必须组合数据库原生权限 + 代理路由规则 + 应用层约束。
为什么代理中间件无法替代 MySQL 权限系统？
ProxySQL 的 mysql_query_rules 表能匹配 SELECT FROM users 并路由到从库，但它不会拒绝 UPDATE orders 请求——只要该 SQL 语法合法、用户有连接权限，它就照常转发。真正的权限判断发生在后端 MySQL 实例上，由 mysql.user 和 mysql.tables_priv 等系统表执行。代理层没有读取这些权限表、也没有执行 ACL_CHECK 的能力。
常见误判场景：
- 给应用配置一个通配符用户
'app'@'%'，在主库授了SELECT,INSERT，在从库只授SELECT——但 ProxySQL 把INSERT发到从库时，MySQL 会直接报错ERROR 1290 (HY000): The MySQL server is running with the --read-only option，这不是权限拒绝，而是只读模式拦截 - 想让某用户只能查
logs表、不能查users表，仅靠 ProxySQL 规则匹配SELECT.*FROM logs并放行，对SELECT.*FROM users却不做阻断——后者仍会被发到从库，最终由从库的权限系统拒绝，但请求已发出、延迟已产生
真正可行的表级读写分离组合方案
必须分三层协同：MySQL 权限控制为底线，ProxySQL 路由为加速器，应用逻辑为兜底。
-
后端权限层：在主库创建用户并授予具体表的
INSERT,UPDATE,DELETE权限，在从库创建同名用户但只授对应表的SELECT权限。例如：GRANT SELECT ON mydb.logs TO 'app'@'%'; GRANT INSERT,UPDATE ON mydb.orders TO 'app'@'%'; -
ProxySQL 路由层：用
mysql_query_rules显式匹配表名，避免误路由。例如规则：match_pattern='^SELECT.*FROM[[:space:]]+logs[[:space:]]'→destination_hostgroup=20（从库组）；match_pattern='^UPDATE[[:space:]]+orders[[:space:]]'→destination_hostgroup=10（主库组）。注意正则需锚定开头，避免SELECT * FROM logs JOIN users被错误匹配 -
应用层约束：关键操作（如涉及
users表的SELECT）强制走主库，避免从库延迟导致脏读。可用 Spring 的@ReadOnly注解 +AbstractRoutingDataSource标记线程上下文，与 ProxySQL 的apply_mysql_query_rules=1配合生效
ProxySQL 表级路由的坑点与参数细节
直接用正则匹配表名看着简单，实际容易失效。几个关键点：
-
match_digest比match_pattern更可靠，它匹配的是 SQL 归一化后的 digest（如SELECT ? FROM ?），但无法区分具体表名；真要按表路由，必须用match_pattern并开启case_sensitive=0 - 多表查询（
SELECT a.id FROM users a JOIN logs b ON a.id=b.user_id）会同时匹配两个表名正则，导致规则冲突。此时应优先匹配更具体的表，或改用schemaname字段做库级隔离 -
mysql_servers中从库必须设read_only=1，否则 ProxySQL 的monitor模块无法自动识别角色，hostgroup分组会错乱 - 规则顺序很重要：
rule_id小的先匹配。把高优先级表（如users）的规则放在前面，避免被泛匹配规则（如SELECT.*FROM \w+）提前截断
最易被忽略的一点：ProxySQL 不会帮你做权限兜底。哪怕你把所有 SELECT FROM users 都路由到主库，如果应用代码里写了 UPDATE logs SET status=1 WHERE id=123 却没加路由标记，它仍可能被发到从库——然后 MySQL 报错，而不是静默拒绝。所以表级读写分离从来不是单靠中间件就能落地的事，它是权限、路由、应用三者咬合的结果，缺一不可。
