你有没有遇到过这种情况：网站用得好好的，突然卡得不行，点个页面要转半天。一查才发现，数据库撑不住了。其实很多问题，靠一个简单的办法就能缓解——读写分离。
什么是读写分离？
简单说，就是把“写数据”和“读数据”分开处理。比如你发了一条朋友圈，这是“写”；朋友刷到你的动态，这是“读”。通常“读”的请求远比“写”多得多。如果全都压在一个数据库上，写操作容易被读操作拖慢。
读写分离的做法是：主库负责写，比如插入、更新、删除；多个从库负责读，通过同步机制复制主库的数据。这样，读的压力就被分摊了。
提升性能最直接
想象一下银行柜台，一个人既办存款又办查询，队伍肯定长。但如果开两个窗口，一个专门存取款，另一个只查余额，效率立马提升。数据库也一样，主库专心写，从库分担读请求，响应更快，系统更稳。
提高系统的可用性
万一主库出问题，虽然不能写新数据，但从库还能继续提供查询服务。比如电商大促时数据库挂了，虽然不能下单，但用户还能看商品信息，不至于整个网站瘫痪。
便于扩展和维护
业务增长后，加个从库比升级主库便宜多了。你可以按需增加读节点，应对流量高峰。平时做备份或数据分析，也可以指向从库，不会影响主库性能。
实际配置示例
以常见的MySQL主从配置为例，应用层需要识别SQL类型，把请求路由到不同数据库：
// 伪代码示意：简单判断SQL类型进行路由
function getConnection(sql) {
if (sql.startsWith("SELECT")) {
return slaveConnection; // 读走从库
} else {
return masterConnection; // 写走主库
}
}当然，实际项目中会用中间件如MyCat或ShardingSphere来自动处理，开发人员几乎不用改代码。
也不是万能药
读写分离有个小坑：主从同步有延迟。刚写完马上读，可能从库还没同步到，看到的是旧数据。这种情况叫“读延迟”，需要在业务上容忍，比如订单提交后跳转页面时不立刻查状态，而是等几秒再刷新。
所以，不是所有系统都必须上读写分离。小项目、读写量都不大的情况下，反而增加复杂度。但一旦用户量上来，这招就很关键了。