分库分表是将大型的数据库拆分为多个小型数据库和表的技术。垂直分库按业务模块拆分，垂直分表是按字段拆分，水平分库分表是按数据行拆分。
需要分库的时机分为：单表数据量超过1000万行，数据库的连接达到瓶颈，磁盘IO称为性能瓶颈。
常见的分片算法分为取模分片，范围分片，哈希分片，一致性哈希等，需要考虑数据均匀性，扩展性，路由复杂性等。
分库分表是解决数据库的性能瓶颈的终极手段，它通过将数据分散到多个数据库实例来提升性能，然而，分库分表也引入了复杂的分布式问题。
垂直分表和水平分表的策略
垂直分库是最容易理解和实施的分库策略，它按照业务领域将不同的表拆分到不同的数据库实例。比如将用户相关表、订单相关表、商品相关表分别放入不同的数据库实例。这种方式的优势是业务边界清晰，拆分后各个数据库的职责单一，便于维护。同时，不同业务模块的负载特性往往不同，拆分后可以针对性地进行优化。
垂直分表则是将单个表的字段按照访问频率和大小进行拆分。将常用的小字段保留在主表中，将不常用的大字段（如 TEXT、BLOB）拆分到扩展表中。这种策略能够有效减少常规查询的 IO 开销，特别是在列存储引擎中效果更为明显。
水平分库分表是最复杂但也是最有效的方案。它将同一个表的数据按照某种规则分散到多个数据库的多个表中。这种方式能够真正解决单表数据量过大的问题，理论上可以无限扩展。但是，水平分片引入了分布式系统的所有复杂性，包括路由算法、跨库查询、分布式事务等问题
分库分表的最佳时机和标准
判断是否需要分库分表的标准是多维度的。数据量是最直观的指标，当数据量达到1000万行以上时，查询性能通常会显著下降。但仅仅看数据量是不够的还要考虑当前的数据增长速率，如果业务处于快速发展的时期，即使当前数据量不大，也应该提前规划分库分表，避免后期迁移痛苦。
性能指标是另一个重要的判断标准。当数据库的QPS/TPS接近硬件极限，响应时间明显增加，特别是在高并发的场景下，即使优化了索引和查询，单机数据库的处理能力终究是有限的。
业务特性业影响分库分表的时机选择.对于读多写少的业务，可以优先考虑读写分离。对于写密集场景，分库分表大大增加了系统的复杂度，需要团队具备相应的技术储备。
常见的分片算法和路由规则
取模分片是最简单的水平分片算法，通过对分片键进行取模运算来确定数据存储的库表。这种方法实现简单，数据分布相对均匀，但扩容时需要进行数据迁移。范围分片按照分片键的值范围进行分片，比如按时间范围或 ID 范围分片。这种方法便于范围查询，但可能导致数据分布不均匀，出现热点问题。
哈希分片通过哈希函数将分片键映射到不同的分片，相比简单取模具有更好的分布均匀性。一致性哈希是哈希分片的改进版本，它能够在节点增减时最小化数据迁移量，特别适合需要动态扩容的场景。
在实际应用中，往往会结合多种算法形成复合分片策略。比如先按业务类型进行垂直分库，再在每个库内按用户 ID 进行水平分表。这种分层分片的方式能够更好地平衡性能和复杂度。