什么原因促使团队做出分库分表的决定
团队决定实施分库分表（Sharding）通常源于以下核心问题的爆发或预见性规避，这些问题的本质是单机数据库在数据量、并发量或复杂性上的极限被触及。以下是促使团队做出这一决策的关键原因：
1. 性能瓶颈：数据库不堪重负
慢查询激增： 单表数据量过大（如超千万甚至亿级）导致简单查询都变慢（如全表扫描），索引效率急剧下降。
高并发阻塞： 大量并发读写请求（如秒杀、热点数据）导致连接池耗尽、锁竞争激烈（行锁、表锁）、CPU/IO 持续飙高，响应时间陡增甚至超时。
I/O 成为瓶颈： 磁盘读写速度跟不上数据增长，即使优化索引也难以解决物理I/O限制。
2. 数据量爆炸：存储与运维压力
单表数据量过大： 超出单机存储上限（如 MySQL 单表建议在千万级以下，实际根据硬件和业务可能更低）。
单库数据量过大： 备份恢复耗时过长（小时级甚至天级），DDL操作（如加字段、加索引）风险极高且耗时无法接受。
存储成本高企： 超大单机实例成本（尤其是云数据库）远超分库后的多个较小实例。
3. 系统扩展性受限
垂直扩展（Scale-Up）失效： 即使升级到最强大的单机（CPU、内存、SSD），性能提升已无法匹配业务增长曲线，性价比极低。
需要水平扩展（Scale-Out）： 业务高速增长预期明确，必须采用分布式架构，通过增加相对廉价的普通服务器节点来线性扩展数据库能力。
4. 架构演进与解耦需求
微服务化驱动： 应用层已拆分为微服务，要求数据库层也按业务边界拆分（垂直分库），实现真正的独立部署、开发、运维和扩展。
降低耦合度： 避免所有业务表堆在一个“大泥球”库中，减少跨业务模块的意外影响（如一个慢查询拖垮整个库）。
5. 提升可用性与故障隔离
降低单点故障风险： 所有数据放在一个库/实例上，一旦宕机或损坏，整个业务停摆。分库后，故障被隔离在单个分片内。
精细化容灾： 可为不同重要性的业务库（如核心订单库 vs 日志库）设置不同的备份和恢复策略。
团队不会轻易决定分库分表，因为其复杂度、成本和风险陡增。决策前通常会经历以下过程：
充分优化单机性能：
优化 SQL 和索引（消除慢查询、避免全表扫描）。
引入缓存（Redis/Memcached）减轻读压力。
实施读写分离（主库写，多个只读从库分担读请求）。
升级硬件配置（Scale-Up）。
归档或清理历史数据。
监控指标持续恶化：
CPU、内存、磁盘 IO、网络 IO 长期高位运行。
慢查询日志占比过高，关键业务 SQL 响应时间 SLA 频繁被打破。
数据库连接池经常满载，应用端出现大量连接超时错误。
业务增长的明确信号：
数据量年增长率远超预期，预测将在短期内达到单库/单表极限。
并发请求量（尤其是写请求）已接近或超过单库处理能力。
核心业务（如支付、订单）因数据库瓶颈频繁出现卡顿或失败，影响用户体验和收入。
评估成本与收益：
预估分库分表带来的开发成本（代码改造、中间件引入、测试）、运维复杂度提升（部署、监控、扩容、数据迁移）。
权衡不分库分表带来的业务风险（宕机、性能劣化导致用户流失）和未来更高的单机成本/扩展瓶颈。