你有没有经历过那种场面？ 用户一多，页面加载慢得像老牛拉破车，客服电话被打爆，一个接一个； 主库 直接飙到90%以上，连登录都失败，运维半夜被电话叫醒，手都在抖； 大促当天，订单提交卡得动不了
你有没有经历过那种场面？
用户一多，页面加载慢得像老牛拉破车，客服电话被打爆，一个接一个；
主库CPU直接飙到90%以上，连登录都失败，运维半夜被电话叫醒，手都在抖；
大促当天，订单提交卡得动不了，前端报错“连接超时”，后台日志全是“Connection refused”——看得人头皮发麻。
说实话，问题根本不是服务器不够强。
真正的问题是：数据库同时在扛读和写，这就像让一个司机一边开车，一边在副驾修发动机，能不崩吗？
解决办法其实就一个：把读和写分开。
让从库专门干“查”的活，主库专心处理“改”和“删”。
听起来简单，但现实是——80%的项目第一轮就栽在配置上。
不是代码跑不通，而是压根没搞清楚：从库的数据到底同步了吗？
为什么读写分离能救命？先看真家伙的效果
某电商平台上线读写分离后，读请求吞吐量直接翻了3倍，主库负载下降40%，大促期间稳如老狗，没出过一次单点崩溃；
单个MySQL实例在5000 QPS时延迟直接炸到300%，而拆成主从架构后，平均响应时间从800ms干到了120ms，体验直接起飞；
有一次主库突然宕机，从库居然还能撑住查询服务，系统没全瘫——那一刻，团队集体松了口气。
这些不是纸上谈兵，是阿里、微信、美团这些大厂实打实跑出来的经验。
但你也得知道：背后全是血泪教训。主从延迟、配置冲突、缓存穿透、数据不一致……哪一环没踩坑，都不容易活下来。
三种主流实现方式怎么选？哪个最省心？
说白了，就三个选择，各有各的命：
ShardingSphere（JDBC）：不用改一行代码，配置完就能跑，对业务透明，后期维护也轻松。适合中大型项目，追求稳定、无侵入的团队。
dynamic-datasource-spring-boot-starter：得手动加
@DS注解，虽然比自己写拦截器省事，但还是得改代码。小团队想快速升级旧项目，可以试试。手动写AOP/拦截器：必须改代码，还容易出错，调试起来头大。除非有特殊需求，新手千万别碰。
✅ 结论一句话：优先上 ShardingSphere。
它最省心，对代码无侵入，后期好维护。
但注意啊——它也不是万能药。表结构乱、字段命名瞎起、外键关系一堆，哪怕用了它，分片路由照样给你整崩溃。
手把手教你用 ShardingSphere 实现读写分离（别光看，要动手）
第一步：引入依赖（pom.xml）
org.apache.shardingsphereshardingsphere-jdbc-core-spring-boot-starter5.3.2
❗ 版本一定要盯紧！不同版本配置差异大，别图省事用新版本。
特别警告：别用 4.1.1，这个版本在某些网络环境下会触发死锁，尤其高并发读写混合场景下，一碰就炸。
（我见过一个项目，线上跑了三个月才暴雷，排查了整整一周……）
第二步：配置 application.yml
spring: shardingsphere: datasource: names: master,slave01 master: url: jdbc:mysql://192.168.1.100:3306/db_master?useSSL=false&serverTimezone=UTC&autoReconnect=true&failOverReadOnly=false username: root password: yourpass driver-class-name: com.mysql.cj.jdbc.Driver slave01: url: jdbc:mysql://192.168.1.101:3306/db_slave?useSSL=false&serverTimezone=UTC&autoReconnect=true&failOverReadOnly=false username: root password: yourpass driver-class-name: com.mysql.cj.jdbc.Driver rules: readwrite-splitting: data-sources: rw_ds: write-data-source-name: master read-data-source-names: - slave01 load-balance-algorithm-name: random algorithms: random: type: RANDOM
几个关键点，记住了：
write-data-source-name必须指向主库；
read-data-source-names列出所有从库，别漏了；
load-balance-algorithm-name决定读请求怎么分摊，RANDOM是最简单的；
autoReconnect=true这个参数千万不能少。
否则连接池断开后没法自动恢复，应用直接雪崩，一个接口挂掉，整个系统跟着崩。
第三步：确认主从复制真的通了（别跳过！）
这是最容易被忽略的一环。
很多人以为配好了就能跑，结果上线一测，发现从库查不到数据——不是框架不行，是你根本没验证主从同步是否生效。
检查方法很简单：
在主库执行一条
INSERT INTO user(name) VALUES('test')；登录从库，跑
SELECT * FROM user，看能不能看到这条记录；更狠一点：在主库执行
SHOW SLAVE STATUS\G，看Slave_IO_Running和Slave_SQL_Running是否都是Yes。
提醒一下：
如果从库显示
Last_Error，大概率是权限不够，或者主库的 binlog 格式不是ROW（记得检查binlog_format=ROW）；某地午后暴雨，网络波动大，主从延迟可能飙到几秒——这很常见，别一看到延迟就报警，数据滞后是常态，不是故障。
第四步：浏览器测试，看是不是真走了从库
访问
/user/list（查询接口）→ 查日志或看打印的SQL，应该走的是slave01；访问
/user/save（新增接口）→ 日志里应该走master；从库数据不变，主库有新记录 → 成功！
⚠️ 踩坑点来了：
有些框架（比如 MyBatis）默认用主库连接，就算你配了读写分离，也不一定自动走从库。
只有显式标记为SELECT语句，才可能被识别；事务里（
@Transactional）的读写操作，不管什么类型，都会走主库——这是设计如此，别指望它变。
分库分表要不要一起上？什么时候该加？
先别急着上分库分表，先问问自己：你的表是不是快撑爆了？
| 表类型 | 建议单表最大行数 | 超过后风险 |
|---|---|---|
| 用户表 | 1000万以内 | 查询慢、锁冲突多 |
| 订单表 | 1000万以内 | 删除困难，备份耗时 |
| 流水表 | 500万以内 | 影响统计性能 |
✅ 建议：一旦单表超过500万行，就得开始考虑分库分表了。
但别盲目跟风——不是所有业务都需要分表。有些系统数据量不大，但频繁更新，分片反而增加跨库查询成本，得不偿失。
分库分表怎么做？两种经典套路
按用户ID分库
用user_id % 8决定去第几个库。
查询时，只要知道用户ID，就能直接定位，不用遍历所有库——效率拉满。按时间分表
比如订单表按月分表：order_2024_01,order_2024_02。
适合历史数据归档，也方便清理旧数据，比如每年删掉一年前的表。
⚠️ 避坑提醒：
别按非主键字段分片，比如按用户名分库，那以后查某个用户，得遍历所有库，性能直接拉胯；
分库数量建议留点余地，比如先分8个库，未来能轻松扩到16个；
一旦启用分库分表，所有跨库查询都得重新设计。别指望一条 SQL 跨库搞定，那是梦。
数据库中间件怎么选？MyCat vs ShardingSphere
| 对比项 | ShardingSphere | MyCat |
|---|---|---|
| 是否支持读写分离 | ✅ 是 | ✅ 是 |
| 是否支持分库分表 | ✅ 是 | ✅ 是 |
| 是否对代码无侵入 | ✅ 是（JDBC模式） | ❌ 需要客户端连接代理 |
| 是否支持动态配置 | ✅ 支持热更新 | ❌ 需重启 |
| 是否易运维 | ✅ 有控制台、监控 | ❌ 依赖手动管理 |
| 企业级功能 | ✅ 安全、高可用、智能路由 | ❌ 功能较弱 |
✅ 结论：除非你对 MyCat 熟得像自家厨房，且业务特别简单，否则直接上 ShardingSphere。
但如果你项目里已经用了 MyCat，别轻易换。迁移成本太高，尤其是涉及大量 SQL 重写和连接池改造，动一次就是一场灾难。
常见问题（FAQ）——全是血的教训
Q1：读写分离后，从库数据滞后怎么办？
→ 滞后是正常的，一般在毫秒级。如果超过1秒，得看主从网络、binlog传输有没有堵住。
建议开启半同步复制（rpl_semi_sync_master_enabled=ON），能有效降低延迟，但写性能会稍降一点——权衡之下，值。
Q2：只有一台从库，万一挂了咋办？
→ 建议至少配两个从库，用主从 主主架构。也可以用 Keepalived 做自动切换。
但别以为切完就万事大吉——应用可能还在用老连接，得配合连接池的重试机制，不然照样出问题。
Q3：我用 Redis 缓存了，还需要读写分离吗？
→ 需要！ 缓存只能扛热点数据，但全量查询、聚合查询、复杂统计，根本缓不了。
举个例子：某系统缓了用户信息，但“最近7天活跃用户”这种聚合查询，没法缓，还得走数据库。
Q4：能不能只用 MySQL 自带的 ReplicationDriver？
→ 可以，但功能太有限。它只支持简单主从切换，不支持分片、动态路由、负载均衡。
只适合极小项目，生产环境别碰，风险太大。
Q5：改完配置，程序启动报错，说找不到数据源？
→ 检查是否误引入了 Druid 自动装配。在 application.yml 加一句：
spring: datasource: druid: enabled: false
否则会冲突导致启动失败。
更狠的坑：某些版本的 Druid 会主动创建连接池，和 ShardingSphere 的数据源打架，直接内存溢出，排查起来头大。
最后劝退指南：什么情况千万别上读写分离？
项目只有几百用户，每天访问不到1万次 → 直接放弃，没必要折腾；
数据库表结构乱得像迷宫，没有主键，字段名五花八门 → 上了也白搭，分片路由直接崩；
预算低于5万，又没专职运维 → 强烈不建议用 ShardingSphere，维护成本远高于收益；
系统依赖大量复杂联合查询 → 读写分离后跨库查询变成噩梦，不如先优化表结构。
✅ 平替方案：
用 Redis 本地缓存 缓解热点查询压力；
用 数据库连接池（HikariCP） 连接复用 提升吞吐；
用 分页 懒加载 降低单次查询数据量。
总结：
读写分离不是“一键解决高并发”的魔法。
它是在架构层面对数据库压力的合理分流，但前提是：
主从同步得稳，别三天两头断；
代码逻辑别绕过路由规则，别以为“随便写条SQL就行”；
运维能力得跟上，不能出了问题只会看日志；
有应对延迟、故障、回滚的预案，别等崩了才想起来补。
别再幻想“配个yml就搞定一切”。
真正的高并发，拼的是细节、底线，还有那股子持续迭代的劲儿。
有时候，最狠的不是技术，是耐心。