MySQL 分库 是一种将一个大的数据库划分成多个独立的数据库实例的技术。分库能够帮助分散单一数据库的压力，提升并发处理能力、扩展存储空间，并在高并发、高数据量的场景中提供更好的性能和可扩展性。
分库通常是指将一个数据库拆分成多个数据库，每个数据库都相对独立，具有自己的表结构和数据。分库后，数据会根据某种规则分布到不同的数据库中，通常使用分片键（Sharding Key）来决定数据存储的具体位置。
与 分表 不同，分表是在一个数据库内将数据分割到多个表中，而 分库 是将数据拆分到不同的数据库实例。
分库的策略有很多种，常见的分库策略包括按 范围、哈希、时间 等维度进行分库。
按范围分库是根据某个字段的值范围，将数据分到不同的数据库实例。例如，可以根据 用户 ID 或 订单 ID 等字段的值范围来划分数据。
示例：
Life is like a journey
users 表，可以按照用户的 user_id 划分到两个数据库：
db1 存储 user_id 在 1 到 1000 的数据db2 存储 user_id 在 1001 到 2000 的数据这种方式适合数据是连续增长的场景，且数据访问常常集中在某个范围内。
按哈希分库是将数据根据某个字段的哈希值分布到不同的数据库中，哈希值决定数据分配到哪个数据库。通常使用哈希函数对分片键进行哈希，哈希值决定数据存储位置。
示例：
users 表，使用 user_id 作为分库字段，可以通过 user_id % 4 来决定将数据分到哪个数据库：
db0 存储 user_id % 4 == 0 的数据db1 存储 user_id % 4 == 1 的数据db2 存储 user_id % 4 == 2 的数据db3 存储 user_id % 4 == 3 的数据哈希分库的优势是数据分布均匀，避免了数据倾斜的问题，适用于数据量较大且需要均匀分布的场景。
按时间分库是根据时间字段（如创建时间、更新时间等）将数据分到不同的数据库中。这个策略常用于日志数据、历史数据等随着时间增长的数据。
示例：
logs 表，可以按 年份 或 月份 来进行分库：
logs_2023 存储 2023 年的数据logs_2024 存储 2024 年的数据logs_2025 存储 2025 年的数据按时间分库的好处是数据会随着时间自然增长，且每个库的数据量相对均匀，适用于以时间为主要访问维度的应用。
按功能或模块分库是将数据根据业务模块进行拆分，不同模块的数据存储在不同的数据库中。常见的应用场景是将不同的业务逻辑或应用的不同功能模块存储在独立的数据库中。
示例：
user_db 存储用户相关数据product_db 存储商品相关数据order_db 存储订单相关数据这种方式适用于多个模块独立访问且数据不频繁联动的情况。
在应用层手动实现分库的逻辑，应用根据某些字段的值（如 user_id、order_id、created_at）来判断数据存储的数据库。具体做法如下：
user_id 进行哈希分库，或者按时间进行分库。手动实现分库时，通常需要在应用层自行处理跨库查询、事务管理等问题，可能增加开发复杂度。
为了简化分库操作，可以使用数据库中间件来管理分库。数据库中间件通常会提供透明的分库和路由功能，将分库的细节隐藏在应用程序之外。常见的分库分表中间件有：
使用数据库中间件时，应用无需关心分库和路由的细节，只需要连接到中间件，后者会根据请求自动将操作路由到正确的数据库。
分布式数据库是为了应对大规模数据和高并发场景而设计的，支持自动的分库分表和数据分片，能够为应用提供透明的扩展性。常见的分布式数据库有：
使用分布式数据库时，数据库本身负责数据的分片、路由和事务处理，应用无需显式处理分库。
MySQL 分库 是一种水平扩展技术，能够帮助系统处理大规模数据和高并发的请求。常见的分库策略包括按范围分库、哈希分库、时间分库和功能分库等。分库通常需要应用层来进行路由操作，也可以借助数据库中间件或分布式数据库来简化实现。分库带来了性能提升的同时，也引入了跨库查询、事务管理和数据迁移等方面的挑战。在实现分库时，需要根据业务需求和数据特点