数据库分库分表策略与实践 题目描述 分库分表是解决数据库性能瓶颈的重要技术，当单表数据量过大或并发访问压力过大时，通过数据拆分来提升系统性能。请你详细解释分库分表的常见策略、适用场景以及实践中的关键问题。 知识点详解 1. 为什么需要分库分表？ 单库瓶颈 ：当数据量达到千万级甚至更大时，单表索引膨胀，查询性能急剧下降。 单机资源限制 ：磁盘IO、CPU、内存等资源成为瓶颈，影响并发处理能力。 高并发压力 ：大量请求集中在一个数据库实例，连接数可能成为瓶颈。 2. 分库分表的核心策略 分库分表分为垂直拆分和水平拆分两种方向： 2.1 垂直拆分（按业务维度） 垂直分库 ：将不同业务模块的表拆分到不同数据库实例（如用户库、订单库）。 垂直分表 ：将一张表的列按访问频率拆分（如将常用字段放主表，大字段或冷字段放扩展表）。 示例 ：用户表拆分为 user_base （基础信息）和 user_profile （详情信息）。 2.2 水平拆分（按数据维度） 水平分库 ：将同一表的数据按规则分布到不同数据库（如按用户ID取模分到DB1、DB2）。 水平分表 ：将单表数据按规则拆分到多个子表（如按时间月份分表 order_202401 、 order_202402 ）。 常用分片键 ：用户ID、订单ID、地理位置等具有业务关联性的字段。 3. 分片路由策略详解 3.1 范围分片 按分片键的连续范围划分（如ID 1-1000在分片1，1001-2000在分片2）。 优点 ：适合范围查询，扩容简单。 缺点 ：可能产生数据热点（新数据集中到最后分片）。 3.2 哈希分片 对分片键取哈希值后按分片数取模（如 分片编号 = hash(user_id) % 4 ）。 优点 ：数据分布均匀，避免热点。 缺点 ：扩容需重新哈希，范围查询需跨分片扫描。 3.3 一致性哈希 使用虚拟节点环减少扩容时的数据迁移量（仅影响相邻分片）。 示例 ：扩容从4分片到5分片时，仅需迁移约20%的数据。 4. 实践中的关键问题 4.1 全局ID生成 数据库自增ID问题 ：分库后可能重复。 解决方案 ： 雪花算法 ：生成64位ID（时间戳+机器ID+序列号）。 号段模式 ：从数据库批量获取ID段（如一次分配1000个ID）。 4.2 跨分片查询 查询条件无分片键 ：需向所有分片发送查询后聚合结果（性能差）。 解决方案 ：建立异构索引表（如按非分片键建立映射表），或使用搜索引擎（如Elasticsearch）。 4.3 分布式事务 场景 ：跨分片的更新操作（如转账涉及两个用户在不同分片）。 解决方案 ：使用XA协议、TCC模式或基于消息队列的最终一致性。 5. 分库分表中间件 代理模式 ：在应用与数据库间加代理层（如MyCat、ShardingSphere-Proxy），对应用透明。 客户端模式 ：在应用层集成SDK（如Sharding-JDBC），性能更高但需代码改造。 总结建议 优先优化SQL和索引，单表数据量超千万再考虑分片。 分片键选择需兼顾数据分布和查询模式。 扩容方案要提前设计，避免停机迁移。