读写分离不能优化InnoDB读写比例，真正影响性能的是InnoDB引擎配置、事务行为与索引设计；不调优这些，仅做读写分离会加剧主从延迟和一致性风险。
读写分离本身不能优化InnoDB的读写比例，它只是把读请求从主库卸载出去；真正影响读写比例感知和性能的，是InnoDB引擎层配置、事务行为与索引设计——这两者不调优，光做读写分离反而会放大主从延迟和一致性风险。
为什么读写分离后查询还是慢？关键在InnoDB缓冲池和索引覆盖
常见现象：读请求被路由到从库，但 SELECT 依然响应慢，EXPLAIN 显示 type=ALL 或 Extra=Using filesort。这不是读写分离的问题，而是InnoDB没被正确喂养。
-
innodb_buffer_pool_size设置过小（比如仍用默认 8M 或 128M），导致频繁磁盘页加载，所有查询都变慢，无论主从 - 缺少覆盖索引，InnoDB不得不回表查聚簇索引，即使走索引也慢——尤其在高并发读场景下，
Buffer Pool争用加剧 - 从库执行
SELECT时若涉及JOIN或ORDER BY，而字段没建联合索引，Using temporary会吃光内存并触发磁盘临时表
主库写入瓶颈卡在哪？InnoDB日志与锁机制才是根因
用户常误以为“加了读写分离，写就一定不卡”，但实际中主库 INSERT/UPDATE 延迟飙升，往往和InnoDB底层行为强相关：
-
innodb_log_file_size过小（如默认 48M），导致频繁 checkpoint，写入吞吐受限；建议设为 512M~2G（需配合innodb_log_files_in_group调整） - 长事务未提交，持续占用
Undo Log和 MVCC 版本链，阻塞 purge 线程，间接拖慢后续写入 - 非必要使用
SELECT ... FOR UPDATE或LOCK IN SHARE MODE，在高并发下极易引发行锁等待，SHOW ENGINE INNODB STATUS中可见大量WAITING FOR THIS LOCK TO BE GRANTED - 自增主键缺失或用 UUID 作主键，导致插入时 B+ 树频繁分裂、页迁移，
innodb_page_splits指标飙升
读写分离下哪些读必须走主库？别信中间件自动识别
ProxySQL / HAProxy 不会理解业务语义，所谓“智能读写分离”只按 SQL 类型粗分 SELECT vs INSERT，对以下场景完全失效：
- 刚写完数据立刻查（如注册后跳转个人页）：从库可能还没同步，必须显式走主库，例如在 SQL 中加注释
/* FORCE_MASTER */ SELECT ... - 聚合类统计查询（
COUNT(*),SUM()）涉及大表且无合适索引：从库压力反而比主库高，容易拖垮复制线程 - 使用
READ-COMMITTED隔离级别但依赖当前读（如SELECT ... FOR UPDATE）：从库不支持加锁，必须发往主库 - 查询依赖
information_schema或performance_schema：这些库不复制，只能在主库执行
InnoDB独立表空间 + 行格式选型，直接影响读写IO分布
很多人忽略文件组织方式对读写分离架构的实际影响。共享表空间（ibdata1）会让所有表争抢同一文件锁，而独立表空间（innodb_file_per_table=ON）才能让 IO 更可控：
- 开启
innodb_file_per_table后，每个表对应一个.ibd文件，DROP TABLE可立即释放磁盘空间；否则删表只标记逻辑删除，ibdata1永远不缩容 - 行格式推荐用
ROW_FORMAT=DYNAMIC（MySQL 5.7+ 默认），相比COMPACT更节省大字段（TEXT/VARCHAR）存储开销，减少页内碎片，提升随机读效率 - 对写密集型表（如日志、消息记录），可单独设置
innodb_flush_log_at_trx_commit=2（主库）+sync_binlog=1000，平衡持久性与吞吐；但切记：这会牺牲极端宕机下的最多 1 秒数据
真正卡住读写分离效果的，从来不是代理层转发逻辑，而是你有没有让 InnoDB 在主库上少等 IO、在从库上少做计算。参数调得再细，如果 SELECT 还在全表扫描、UPDATE 还在锁整行，读写分离只是把问题从一台机器搬到另一台。
