一文读懂Sql Server读写分离和分库分表

读写分离

1. 顾名思义 就是读和写分离 在不同数据库操作 减免操作之间影响 提升性能
   读写分离通过将数据库的读操作（SELECT）和写操作（INSERT/UPDATE/DELETE）分发到不同的物理实例上，从多个维度优化资源利用和并发处理能力，从而显著提升整体性能。
2. 思路：主从同步 发布订阅 主库应对写 从库应对 读 可扩展从库数量
3. 适用场景：读多写少，对数据实时性要求较高的业务（如电商商品查询）
4. 实现建议：
   优先在读多写少​（读写比>4:1）的场景中使用读写分离。
   通过数据库中间件（如ShardingSphere）自动路由读写请求，减少代码侵入性。
   监控主从延迟（SHOW SLAVE STATUS），设置阈值告警（如延迟>1秒触发预警）
5. 注意事项与局限性
   数据延迟问题：
   异步复制可能导致从库数据滞后，业务需容忍短暂不一致性。
   解决方案：对一致性敏感的读操作仍路由到主库。
   写能力瓶颈：
   读写分离仅扩展读性能，写能力仍受限于主库。
   解决方案：结合分库分表分散写压力。
   成本增加：
   需额外硬件和维护从库，成本上升。
   解决方案：云数据库（如 Azure SQL）按需扩展从库

读写分离如何提升性能

1. 负载分离：减少资源争用 减少锁的使用
   问题场景：
   在单库架构中，读操作（共享锁，S 锁）和写操作（排他锁，X 锁）会竞争同一数据库的资源：
   锁冲突：写操作需要独占资源（X 锁），会阻塞读操作（S 锁）和其他写操作。
   CPU/IO 瓶颈：混合读写负载可能导致 CPU 和磁盘 IO 过载。
   读写分离的优化：
   主库（Primary）：仅处理写操作，避免读操作占用资源。
   从库（Secondary）：通过复制技术（如 AlwaysOn、事务复制）同步主库数据，独立处理读操作。
   效果：
   写操作无需等待读操作释放锁，减少锁冲突。
   读操作不再占用主库的 CPU 和 IO 资源，降低主库压力

<