用只读从库分担查询压力

主库 CPU 长期偏高，翻慢查询日志一看，大头是报表和统计类查询——这种局面加一台只读从库，往往比直接升主库配置更划算。思路是把写入和实时读留在主库，把"不嫌数据旧几秒"的查询挪到从库。 哪些查询适合下放 报表、导出、数据分析、后台列表这类查询的共同点：能容忍秒级延迟，单次扫的数据量大。下放到从库后，主库的锁竞争和内存缓冲池压力都会明显回落。反过来，交易流程里的状态查询、写完马上要展示的数据，不要下放，原因看下一节。 延迟的影响 主从复制是异步的，主库提交到从库追平有时间差，正常毫秒到秒级，主库高峰或大事务时会拉长。所以从库的数据永远是"稍旧"的。判断能不能下放就看一条：这个业务接受读到几秒前的数据吗？接受，下放；不接受，留主库。拿不准的查询先在从库手动跑一遍，和主库最新结果对照看差异，比会上争论靠谱。 路由怎么实现 常见三种做法。 应用层双数据源：代码里配主、从两套连接，业务自己决定走哪边，最直白，适合下放点少的项目。 中间件分流：数据库中间件按 SQL 特征自动把读请求分到从库，业务代码几乎不改，代价是多一层组件要维护。 注释标记转发：报表 SQL 统一带 /* read_only */ 注释，代理层识别后转发从库，改动集中、规则一目了然。 无论哪种，从库记得设 super_read_only=ON，杜绝误写。挑哪种实现不重要，重要的是规则集中在一个地方维护，别散落在各业务代码里各写各的。 一句提醒 从库不是越多越好，每加一台，主库就多一份复制流要维护，写多的业务先看自己的写 TPS（每秒事务数）再定数量。另外，下放之前先把手头慢 SQL 优化一轮——很多时候优化做完，连从库都省了。