保姆级教程 | 慢查询治理之读写分离

▌ 技术引导

这玩意儿真不是搞搞而已，读写分离落地的痛，我亲身体验过。记得某次用了分库分表的方案，结果因为没控制好写入负载，直接整垮了主库。更糟的是，应用层没做逻辑分片，连个判断写入主库还是从库的逻辑都没搞，结果全堆到主库，数据库直接卡死。真不是开玩笑，这种问题要是不提前踩点，出了问题连踪影都找不到。

我真正靠谱的方案是在应用层加个路由中间件，通过配置文件定义哪些表走读，哪些表走写，再配合动态DNS把流量分发出去。比如在Spring Boot里用MyBatis Plus的分表插件，或者直接用ShardingSphere，这些工具都能帮你搞定路由逻辑。别问我怎么知道的，我用过，也踩过坑。

在实际环境中，我见过因为数据一致性的问题导致业务逻辑出错，尤其是在订单表这种高并发写入的场景。这时候就得在应用层或数据库层做一致性保障，比如用canal做数据同步，或者用binlog做补偿。别看着配置简单就上，有些参数调不好，同步延迟能到几十秒。

还有那些没做好备份和事务管理的项目，真是危险。我见过一个项目，没用主从同步，直接用从库做只读，结果写操作误伤到从库，导致整个系统崩溃。别想着偷懒，得在配置文件里写清楚主库和从库IP，用proxysql这样的中间件做路由，还要对连接池做配置，比如max_connections不能太高，池子满了就卡死。

配置文件和参数这块儿，特别容易出问题。我用过一个项目，因为配置的读库权重不对，导致读操作占了80%的连接，写操作却只用主库，结果主库CPU爆了。所以得在配置里写清楚权重和路由规则，甚至用脚本动态调整，避免静态配置带来的风险。

▌ 技术参考

一 技术背景与核心概念

读写分离是为了解决高并发场景下的数据库瓶颈问题，本质上是把写操作路由到主库，读操作分发到从库。原理上是通过中间件实现的，比如proxysql、shardingjdbc，或者直接在应用层做逻辑处理。主库负责事务和写入操作，从库用于查询，这样能有效降低主库压力。但这种方案不是万能的，尤其在数据一致性、事务管理、连接池配置这些地方，稍有不慎就会引发严重问题。我见到的很多项目，因为没控制好写入比例，导致主库负载过高，甚至出现连接超时。

二 具体操作方法或配置步骤

要真正落地读写分离，得在应用层加上路由规则。比如用MyBatis Plus的分表插件，或者直接使用ShardingSphere。具体来说，要在配置文件里定义数据源，主库和从库的IP、端口、权重等参数。比如在application.yml里配置：

spring:
datasource:
master:
url: jdbc:mysql://10.10.0.1:3306/db
username: root
password: 123456
slave:
url: jdbc:mysql://10.10.0.2:3306/db
username: root
password: 123456
weight: 100

然后通过配置规则，让某些表只走主库，其他表走读库。比如用ShardingSphere的读写分离配置：

spring:
shardingsphere:
master-data-source-name: master
slave-data-source-names: slave
props:
sql:
show: false
execution:
split-by: none

这种方案虽然简单，但需要结合应用层逻辑，比如判断查询是否是写操作，才能正确分发到主库或从库。

三 常见踩坑场景与避坑方案

最常见的坑是没处理好事务一致性。比如在订单表上做写操作，却在库存表上用了读库，导致数据不一致。这种问题很难排查，因为表之间没有关联。我见过一个项目，因为没在事务里使用主库，结果订单状态更新了，库存还没同步，导致后续逻辑出错。解决办法是事务中所有表必须走主库，或者用canal做数据同步，实时更新读库数据。

另一个坑是连接池配置不当。比如用了HikariCP，但maxPoolSize设得太低，导致主库连接不够用，读库又没抢到，直接卡死。这时候得在连接池配置里区分主从连接池，比如用不同的maxPoolSize和timeout参数。比如：

hikari:
data-source-names:
master:
maximum-pool-size: 20
connection-timeout: 5000
slave:
maximum-pool-size: 50
connection-timeout: 3000

这样主从连接池就不会互相影响，读写分离更稳定。

四 性能影响或效率对比

读写分离在写操作负载高的情况下，能显著降低主库压力。比如一个电商应用，每天有上百万的订单写入，如果全用主库，CPU和内存会直接飙到上限。但一旦分成了主从架构，写操作只走主库，读操作分发到从库，主库的负载能降低30%以上。不过读库的延迟问题不能忽视，尤其在数据量大的情况下，同步延迟可能达到几十秒，这时候查询可能会出现不一致。

另外，读写分离对事务支持有限，特别是在跨库事务的时候，容易出问题。比如一个订单和库存操作必须在同一个事务里，这时候只能用主库，读库不能参与。所以得在应用层做好事务管理，或者用分布式事务框架如seata，来确保一致性。

五 适用场景与局限性

读写分离适用于写操作频繁、读操作多的场景，比如订单、物流、用户登录这些表。但不适合写操作和读操作都频繁的场景，比如即时通讯、支付系统，这些表如果全是写操作，读写分离反而会增加复杂度。我见过一个项目，订单表和用户表都走读写分离，结果写操作冲突太多，导致事务回滚率飙升，反而更慢。

另外，读写分离对数据一致性要求比较低的场景更合适，比如报表查询、日志分析这些。如果业务场景对数据一致性有高要求，比如金融交易，还是得用主库处理所有操作，不能分。所以得根据业务需求来判断，不能盲目跟风。

六 替代方案或进阶技巧

除了中间件，还可以用数据库本身的主从复制来做读写分离。比如MySQL的主从架构，通过binlog同步数据。但这种方案对数据库版本、网络环境、数据同步延迟都有要求，配置起来也比较复杂。我见过一个项目，直接用MySQL的主从复制，结果同步延迟严重，查询结果不一致，最后还是得回退到中间件方案。

进阶一点的做法是用缓存中间件，比如Redis，把高频查询结果缓存起来，减少数据库压力。比如在订单查询场景里，把订单数据缓存到Redis，这样直接从内存里取，不用走数据库。但缓存需要手动更新，容易出脏数据，得配合canal或者binlog做实时同步。这种方案适合读多写少的场景，但对写操作的实时性要求高。

七 具体操作方法或配置步骤

具体配置时，得注意分库分表的键值选择。比如用订单ID作为分片键，这样查询的时候能命中正确的库。但如果是用时间范围查询，分片键就可能失效，这时候得用路由中间件动态计算。比如在ShardingSphere里配置：

sharding:
tables:
orders:
actual-data-nodes: orders_db${0..1}.orders_table${0..1}
database-strategy:
standard:
sharding-column: order_id
sharding-algorithm-name: order_db_algorithm
table-strategy:
standard:
sharding-column: order_id
sharding-algorithm-name: order_table_algorithm

这种配置方式能有效分片，但需要配合应用层的查询条件，确保能命中正确的分片。否则写操作会平均分配，反而增加主库压力。

八 常见踩坑场景与避坑方案

在实际部署中，我遇到过一个坑，就是主库和从库的IP配置错误，导致写操作全都打到从库，主库完全没响应。这种问题很难排查，因为从库也跑了，但没有处理写请求。这时候得在中间件层面做检查，比如proxysql的日志里能看到所有路由的明细，通过日志可以快速定位问题。

还有就是从库负载过高，导致查询变慢。我见过一个项目，从库连接池设置不合理，结果查询队列堆积，最终整个系统卡死。这时候得调节从库的连接池参数，比如maxPoolSize、minPoolSize、idleTimeout等，让从库能处理更多查询。同时还要监控主从库的负载，确保从库不会成为瓶颈。

九 性能影响或效率对比

使用读写分离后，主库的写操作吞吐量通常能提升30%到50%，因为读操作被分散到其他实例。但实际测试中，从库的查询性能可能不如主库，尤其是在频繁更新的情况下。我用过一个项目，从库的查询延迟能达到主库的2倍，这时候得在应用层做补偿，比如在查询时加一个缓存，避免直接访问从库。

另外，读写分离对数据库的索引、查询优化要求更高。因为从库的查询可能涉及全表扫描，这时候得优化查询语句，减少对主库的依赖。比如在订单查询时，用where order_id = ?，而不是全表扫描，这样能有效提升查询效率。

十 适用场景与局限性

读写分离适合业务场景里写操作比较集中，而读操作分布广泛的情况。比如电商平台的订单表，写操作集中在高峰期，读操作分散在各个时间点。这种场景下，读写分离能有效缓解主库压力，提高系统可用性。但如果是写操作和读操作都集中，比如支付系统，这时候就得用其他方案，比如分库分表、分布式事务等。

局限性在于数据一致性问题，尤其是在跨库事务的情况下。比如一个订单和一个库存操作需要原子性，这时候只能用主库处理，不能分库。另外，读写分离对数据库的扩展性要求高，从库得跟上主库的更新速度，否则就会出现数据不一致。因此，在设计时得考虑主从同步的延迟问题，不能盲目追求分库分表。

十一 替代方案或进阶技巧

替代方案中，分库分表是一个更彻底的做法。比如按用户ID分表，每个用户的数据存在不同的表里。这种方法能分散写压力，但查询时需要动态拼接SQL，增加复杂度。我用过一个项目，直接按用户ID分表，结果查询效率反而下降，因为需要判断用户ID属于哪个表，再拼接SQL，增加CPU开销。

进阶技巧是用缓存中间件结合数据库同步，比如Redis和canal。这种方案能进一步降低数据库压力，因为高频查询可以直接用缓存，不需要访问数据库。但得注意缓存失效问题，比如可以设置TTL（Time To Live），或者用canal做binlog同步，实时更新缓存数据。这种方案适合读多写少的场景，但对写操作的实时性要求高。

十二 具体操作方法或配置步骤

在配置读写分离的时候，得确保中间件的版本兼容性。比如proxysql 2.2以上支持dynamic load balancing，能根据负载自动调整流量分配。配置文件里得定义主从库的IP和权重，比如：

[mysqld]
user = proxysql
default_authentication_plugin=mysql_native_password
log_bin = /var/log/mysql/mysql-bin.log
server_id = 1
binlog_format = ROW

然后启动proxysql，配置后端连接信息，比如：

load balancing: write=master, read=slave

这种配置能有效分发流量，但需要定期监控和调整，确保主从库的负载均衡。否则某个从库可能会因为负载过高而崩溃，影响整个系统。

十三 常见踩坑场景与避坑方案

在实际运行中，我遇到过从库查询慢的问题。比如一个项目，从库配置了50个连接池，但实际查询都是慢查询，导致整个系统响应变慢。这时候得在从库上做查询优化，比如开启查询缓存、调整索引、限制慢查询等。另外，还要定期分析慢查询日志，找出性能瓶颈。

还有就是主从库的同步延迟问题，我见过一个项目，主库写入速度很快，但从库同步延迟达到了20秒，导致查询结果不一致。这时候得检查主库的binlog配置，确保同步机制正常。如果同步出现问题，得手动清理binlog日志，或者调整同步策略，比如使用GTID。

十四 性能影响或效率对比

读写分离对系统性能的影响取决于配置是否合理。比如在某个电商项目里，主库的写操作吞吐量提升了40%，但从库的查询延迟增加了5秒。这时候得在应用层做补偿，比如限制查询的并发量，或者增加只读实例的数量，降低单个从库的负载。另外，连接池配置也能影响效率，比如在HikariCP里设置不同的连接池参数，让主从分离更明显。

通过监控工具，比如Prometheus和Grafana，能实时查看主从库的负载情况。比如主库的QPS、CPU利用率、连接数，从库的查询延迟、锁等待等。这些指标能帮助你判断读写分离是否有效，是否需要调整配置。

十五 适用场景与局限性

读写分离适用于读多写少的业务场景，比如报表查询、日志分析、用户信息展示等。但不适合写操作频繁的场景，比如支付、订单创建等。这时候得考虑其他方案，比如分库分表、使用缓存、或者增加主库的硬件资源。

另一个局限是需要额外的中间件支持，比如proxysql、shardingjdbc等。这些中间件虽然能简化配置，但也会增加系统复杂度。我见过一个项目，因为没处理好中间件的高可用问题，导致中间件崩溃，整个系统瘫痪。所以得在中间件上做冗余部署，确保不会单点故障。