第12天-《DBA实战手记》阅读打卡
#Root先锋约 4 分钟在数据库架构的世界里，许多人盲目追逐潮流，却深陷认知误区。有人以为分库分表就是解决问题的 “万能钥匙”，有人在CAP理论的抉择中晕头转向，更有人对数据库的拆分与合并毫无头绪。实际上，从CAP理论的权衡取舍，到垂直与水平拆分的精妙解耦，再到数据库合并的战略考量，每一步都藏着颠覆传统认知的关键操作。
01
CAP理论
在分布式系统中，一致性(Consistency）、可用性(Availability)、分区容错性(Partition Tolerance)三者无法同时满足，需根据业务场景取舍。
CP 优先：金融、支付场景，选强一致数据库（如CockroachDB），牺牲短暂可用性换数据正确性。
AP 优先：社交、内容平台，选最终一致数据库（如Cassandra），保证用户随时可访问。
02
数据库拆分
随着业务的快速发展，数据量与访问量呈爆炸式增长，传统单一数据库逐渐不堪重负。数据库拆分迫在眉睫，一方面，它能有效解决性能瓶颈问题，避免因数据量过大导致查询缓慢、系统响应延迟；另一方面，当业务逻辑日益复杂时，垂直拆分可将不同功能模块的数据分离，实现业务解耦，提升开发和维护效率。水平拆分则能分散数据存储压力，增强系统的扩展性和可用性，让数据库架构更适配高并发场景，保障系统在海量数据下仍能稳定高效运行 。
垂直拆分
优点：
业务耦合度降低，不同模块独立运维（如电商拆分为用户库、订单库）。
单库数据量减小，索引效率提升，适合初期业务快速迭代。
缺点：
跨库Join复杂，需通过应用层解决（如微服务接口调用）。
单库仍可能面临容量瓶颈（如订单库数据爆炸式增长）。
应用场景：
中小型企业业务模块化初期，或单体应用向微服务转型阶段（如美团早期拆分用户/商家库）。
水平拆分
优点：
突破单机存储限制，支持TB级数据扩展（如按用户ID哈希分库）。
读写负载分散到多个节点，提升并发能力（如支付宝交易库按日期分片）。
缺点：
分布式事务处理复杂（如跨分片转账需2PC 协议）。
分片规则难调整（如新增节点需数据重平衡，可能引发集群抖动）。
应用场景：
互联网头部企业核心业务（如微信红包按用户 ID分片），或数据量预测将超1TB的场景。
03
分库分表不是分布式
分库分表的局限性
核心特征：
手动分片+中间件路由(如MyCat/Sharding-JDBC），本质是“单机数据库的集群化拼接”。
缺点：
缺乏全局协同：无自动分片、故障转移机制，需人工处理节点宕机（如主从切换需手动修改路由规则）。
事务与索引痛点：跨分片事务依赖中间件实现（性能损耗大），全局二级索引维护成本极高。
典型案例：
某电商早期用Sharding-JDBC分库，大促时因分片键设计缺陷导致订单查询超时，最终被迫迁移至分布式数据库。
真正的分布式数据库
自动分片与均衡：如CockroachDB基于 Range自动分片，节点增减时自动迁移数据（无需人工干预）。
全局事务与索引：支持分布式ACID事务（如 Spanner的TrueTime 协议），全局二级索引自动同步。
应用场景：需弹性扩展、高可用、低运维成本的中大型业务（如字节跳动的OLTP场景选用 TiDB）。
04
数据库合并
1. 合并场景
业务整合：企业并购后统一数据平台（如滴滴收购快的后合并司机/乘客库）。
技术升级：从多异构数据库回归统一架构（如某银行将Oracle+MySQL合并为 PostgreSQL集群）。
2. 优点
降低运维复杂度：统一监控、备份策略，减少多数据库适配成本（如 DBA 只需维护一套技术栈）。
提升数据一致性：消除跨库数据冗余（如用户信息在多个库同步失败的问题）。
3. 缺点
迁移风险高：历史数据清洗、ETL过程可能引发业务中断（如某电商合并订单库时出现订单状态丢失）。
性能挑战：合并后单库数据量激增，需提前做好索引优化与读写分离（如加 Redis缓存）。
4. 实施策略
双写过渡：新旧库同时运行，通过 CDC工具（如Canal）同步数据，验证一致性后切流。
分阶段合并：先合并非核心业务库（如日志库），再逐步迁移核心交易库（如支付库）。
决策口诀
CAP 选型：金融选CP，流量选AP，网络不稳优先P；
拆分策略：业务先行垂直拆，数据爆炸水平拆，中间件过渡需谨慎；
分布式认知：分库分表是 “体力活”，真分布式靠 “智商税”（自动化能力）；
合并原则：非必要不合并，要合并必双写，小步快跑防翻车。