你的数据库开始扛不住了。用户越来越多，查询越来越慢。你看了监控，CPU不算高，内存也够——但读请求量太大了。
大多数业务对数据库的访问，读远大于写。电商、内容站、社交应用，读写比可以达到5:1甚至10:1。这意味着你90%的数据库负载来自查询，只有10%来自写入。
读写分离，就是把你服务器上那台数据库——主库负责写，从库负责读。读请求分散到多台机器，主库的压力就下来了。
什么场景需要读写分离？
读写分离不是万能药。用对了地方效果明显，用错了地方白折腾。
适合的场景：读多写少
这是读写分离最典型的适用场景。如果你的应用查询量远大于写入量（读写比超过5:1），单库的读压力已经让主库喘不过气了，读写分离就能起作用。
关键指标：观察主库的CPU使用率——如果CPU大部分时间花在处理读请求上，且峰值已经接近或超过80%，就该考虑分离了。
不适合的场景：写多读少
如果写入操作比例大于读取操作，那么大量写操作仍然在主库进行，主库的压力并没有得到有效缓解。读写分离达不到预期效果。
不敏感的场景：允许一定延迟
主从之间通过异步复制同步数据，必然存在延迟（通常是毫秒到秒级）。如果你的业务对数据实时性要求极高（比如库存扣减、余额查询），直接读从库可能会读到旧数据。这类场景要么强制读主库，要么不适合用读写分离。
怎么实现读写分离？
实现方式分两种：中间件方案和应用层方案。
中间件方案：对应用透明
你不需要改业务代码，只需要在数据库和应用程序之间加一层代理。
云厂商自带的读写分离：阿里云、华为云、金山云等主流云厂商都提供数据库代理服务。你开通后，应用连接代理地址，代理自动识别SQL类型——写请求发主库，读请求发从库。优点是开箱即用，无需改造。
ProxySQL：开源的数据库代理工具，支持MySQL和PostgreSQL。它通过协议感知的请求路由，把读请求按权重分配到多个从库，还能做连接复用和查询缓存。适合需要精细控制流量分配的场景。
应用层方案：在代码里区分读写
你需要在代码中配置两个数据源，一个连主库、一个连从库。根据SQL类型选择使用哪个数据源——写操作（INSERT/UPDATE/DELETE）走主库，读操作（SELECT）走从库。
ShardingSphere-JDBC：这是ShardingSphere的轻量级Java框架，在JDBC层提供读写分离能力。它以jar包形式集成，无需额外部署。缺点是只支持Java应用。
Spring Boot双数据源：在Spring Boot中配置主库和从库两个DataSource，通过AOP切面根据方法名自动路由（如find*、get*走从库，save*、update*走主库）。
需要注意的坑
主从延迟：这是读写分离最头疼的问题。从库的数据是从主库异步复制过来的，存在延迟。如果业务要求强一致性（刚写入的数据立刻能读到），读请求必须走主库。
如何规避：华为云DDM支持在主从架构下通过/*+ db_type=master*/HINT强制指定查询走主节点，确保读到最新数据。
读取权重配置：可以灵活调整主库和从库的读流量比例。读多写少的场景，可以把主库读权重设为0，所有读请求由从库承担，更好保证主库性能。
一个真实案例
某电商平台商品详情页的读请求是写入的几十倍。单库扛不住，高峰期CPU经常90%以上。启用了云厂商的数据库代理服务，配了1主2从。主库负责订单写入，从库负责商品详情查询。主库CPU降到40%，从库CPU稳定在60%。用户打开商品页的速度从1.2秒降到了0.4秒。业务代码一行没改，只是把连接地址换成了代理地址。
如果你的业务也是读多写少，读写分离可能是性价比最高的优化手段。大部分云厂商的数据库代理服务，不需要改代码就能用。先去控制台看看，你的数据库能开启读写分离吗？