ProxySQL通过持续轮询后端MySQL节点的read_only值（默认每60秒），将结果记录在monitor.mysql_server_read_only_log表中，并据此自动将节点分配至writer_hostgroup或reader_hostgroup，实现动态读写组划分；主库必须read_only=OFF、从库必须read_only=ON且持久化，否则会导致写失败或读路由错误。
为什么 ProxySQL 的 mysql_server_read_only_log 是判断读写组的关键
ProxySQL 不靠你手动配置“哪个是 master 哪个是 slave”，而是持续轮询每个后端 MySQL 节点的 read_only 状态。它把结果记在 monitor 库的 mysql_server_read_only_log 表里，再据此自动把节点分进 writer_hostgroup 或 reader_hostgroup。
常见错误是只在从库设了 read_only=ON，但没确认主库是否为 read_only=OFF（默认就是 OFF，但有些运维会误加）。如果主库也设成 ON，ProxySQL 就找不到可写的节点，所有写请求都会失败，报错类似：ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement。
- 必须确保主库
read_only=OFF（检查：SELECT @@read_only;） - 从库必须
read_only=ON，且该值需持久化到 my.cnf，否则重启后失效 - ProxySQL 默认每 60 秒查一次
read_only，可通过mysql-monitor_writer_is_also_reader控制是否允许主库参与读 —— 生产环境建议关掉（设为0）
MASTER_AUTO_POSITION=1 和 GTID 模式下如何避免事务跳过或重复
启用 GTID 后，CHANGE MASTER TO ... MASTER_AUTO_POSITION=1 是强制要求。它让从库不再依赖 binlog 文件名和 position，而是靠 Executed_Gtid_Set 自动计算缺失事务。但如果中间件（如 ProxySQL）或应用层在事务中混用读写连接，就可能触发 GTID 冲突。
典型现象：应用发起一个事务，先在主库执行 INSERT，再切到从库查刚插入的数据，结果查不到 —— 因为从库有复制延迟；更糟的是，若此时从库还没收到该 GTID 对应事务，而 ProxySQL 又把后续语句路由到从库，就可能因 gtid_executed 集不包含该 GTID，导致事务被拒绝或静默跳过。
- 所有客户端连接 ProxySQL 时，必须使用
transaction_persistent=1（在mysql_users表中设置），否则事务内语句可能被跨节点路由 - 不要在事务中执行
SELECT并期望立刻看到刚写的行；要么显式走写连接（用/*+ USE_MASTER */注释），要么接受最终一致性 - 检查从库是否真正追上：对比主库
SELECT @@gtid_executed;和从库SELECT @@gtid_executed;，差集即未同步事务
ProxySQL 如何通过 mysql_query_rules 强制事务走主库
仅靠 read_only 分组不能解决“事务内读写混合”问题。必须用查询规则把带事务上下文的 SQL 显式钉死到写组。ProxySQL 的 mysql_query_rules 支持基于正则、digest、甚至注释做路由，对 GTID 场景尤其关键。
容易踩的坑是规则顺序错乱：ProxySQL 按 rule_id 升序匹配，一旦前面的规则命中（比如匹配了所有 SELECT），后面的事务相关规则就永远不会生效。
- 优先级最高的规则应匹配显式事务控制语句：
match_pattern = '^START TRANSACTION|^BEGIN|^COMMIT|^ROLLBACK'，destination_hostgroup = 10（写组） - 其次匹配带 hint 的读请求：
match_pattern = '/*\+ USE_MASTER \*/'，同样指向写组 - 最后才是普通读写分离规则；务必设
apply = 1终止匹配，避免穿透 - 规则加载后必须执行
LOAD MYSQL QUERY RULES TO RUNTIME和SAVE MYSQL QUERY RULES TO DISK，否则重启丢失
GTID 模式下 enforce_gtid_consistency=ON 导致的 DDL 失败怎么解
开启 GTID 后，MySQL 会拒绝任何无法安全生成 GTID 的语句，比如 CREATE TABLE ... SELECT、CREATE TEMPORARY TABLE、或跨引擎操作（InnoDB + MyISAM）。这类语句在 ProxySQL 中执行时，不会报错“GTID 不一致”，而是直接返回：ERROR 1782 (HY000): Statement violates GTID consistency。
这不是 ProxySQL 的问题，是 MySQL 层面的硬性限制。绕过它等于破坏 GTID 安全性，所以不建议关 enforce_gtid_consistency。
- 把
CREATE TABLE ... SELECT拆成两步：CREATE TABLE+INSERT ... SELECT - 临时表改用内存表：
CREATE TEMPORARY TABLE ... ENGINE=MEMORY（仍需确保不涉及非事务引擎） - DDL 操作统一走主库连接，并在应用层加重试逻辑 —— 因为 DDL 在 GTID 下是原子事务，失败即回滚，不会残留半截状态
最常被忽略的一点：即使你没写这些语句，某些 ORM（如旧版 Django 或 Laravel）在 auto-migration 时会自动生成 CREATE TABLE ... SELECT，上线前务必检查生成的 SQL。
