ProxySQL 启动后连不上 MySQL 是因未手动插入后端节点到 mysql_servers 表；读写分离失效多因正则匹配不区分大小写或未启用规则；配置需经 INSERT → LOAD TO RUNTIME → SAVE TO DISK 三步才持久生效。
ProxySQL 启动后连不上 MySQL？检查 mysql_servers 表是否已插入后端节点
ProxySQL 不会自动发现后端 MySQL 实例，必须手动往 mysql_servers 表里写入地址、端口、权重和状态。漏掉这步，所有查询都会报错 Unknown MySQL server host 或直接超时。
- 先连 ProxySQL 管理接口：
mysql -u admin -padmin -h 127.0.0.1 -P 6032 - 插入主库（hostgroup_id=1）：
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (1, '192.168.1.10', 3306); - 插入从库（hostgroup_id=2）：
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (2, '192.168.1.11', 3306); - 别忘了加载并保存：
LOAD MYSQL SERVERS TO RUNTIME;和SAVE MYSQL SERVERS TO DISK;
读写分离没生效？重点看 mysql_query_rules 的 match_pattern 和 destination_hostgroup
ProxySQL 不靠语法解析做读写判断，而是靠正则匹配 SQL 文本。默认规则只把 SELECT 发到 hostgroup_id=2（从库），但如果你的语句带换行、注释或大小写混用，可能根本匹配不上。
- 常见失效场景：应用发的是
select * from t1（小写），而规则写的是^SELECT（大写开头） - 建议统一用忽略大小写的正则：
^select\b，并加case_sensitive=0 - 确保
apply=1且active=1，否则规则不启用 - 验证规则是否命中：
SELECT hits, destination_hostgroup FROM stats_mysql_query_rules WHERE rule_id = 1;
主库写入后从库查不到新数据？不是 ProxySQL 的锅，是 MySQL 复制延迟或事务隔离级别导致的
ProxySQL 本身不干预复制逻辑，它只按规则转发。如果应用在写完主库后立刻发 SELECT，而从库还没追上，就会看到旧数据——这不是配置错误，是架构固有约束。
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 对强一致性要求高的语句（如刚注册就查用户），应强制走主库：
/*+ USE_MASTER */ SELECT ... - ProxySQL 支持 hint，但需开启
mysql-query_rules.fast_forward=0并在规则中匹配注释 - 检查复制延迟：
SHOW SLAVE STATUS\G看Seconds_Behind_Master - 避免在
REPEATABLE READ下依赖“写后立即读”，MVCC 可能让你看不到自己刚写的行
配置改了但不生效？Runtime / Memory / Disk 三层状态容易搞混
ProxySQL 的配置分三层：内存运行态（RUNTIME）、内存配置态（MEMORY）、磁盘持久态（DISK）。只改其中一层，重启或 reload 就丢。
-
LOAD XXX TO RUNTIME：让修改立刻生效，但重启丢失 -
SAVE XXX TO DISK：写入disk.db，保证重启加载 - 典型操作顺序：
INSERT→LOAD TO RUNTIME→SAVE TO DISK - 查当前运行配置用
stats库表（如stats_mysql_query_rules），查原始配置用main库表（如mysql_query_rules）
ProxySQL 的读写分离不是开箱即用的黑盒，每个转发决策都取决于你填进 mysql_servers 和 mysql_query_rules 的那几行 SQL。最常被跳过的，是 LOAD 和 SAVE 这两步，以及正则没开 case_sensitive 导致规则静默失效。
