2.4 水平扩展实战：支撑亿级数据的分库分表策略
2.4 水平扩展实战：支撑亿级数据的分库分表策略
📚 学习目标
通过本节学习，你将掌握：
- ✅ 分库分表的核心原理和适用场景
- ✅ 不同分片策略（哈希、范围、目录等）的选择
- ✅ 应用层和中间件分库分表的实现方法
- ✅ 分库分表带来的复杂性问题及解决方案
- ✅ 分库分表架构的设计原则和最佳实践
🎯 学习收获
学完本节后，你将能够：
- 架构设计：设计支撑亿级数据的分库分表架构
- 方案选型：根据业务特点选择合适的分片策略
- 问题解决：处理分库分表带来的复杂性问题
- 性能优化：通过分库分表提升系统整体性能
💡 实际场景引入
场景一：单表数据量过大导致性能下降
问题描述：某电商平台的订单表数据量达到5亿条，单表查询和写入性能急剧下降。即使添加了索引，查询时间仍然超过10秒，严重影响用户体验。
你的任务：如何通过分库分表解决单表性能问题？
场景二：跨库查询的性能挑战
问题描述：某系统实施了分库分表后，发现跨库查询（如统计报表）性能很差，需要聚合多个库的数据，查询时间超过1分钟。
你的任务：如何优化跨库查询性能？
随着业务的快速发展，单个MySQL实例已经无法满足日益增长的数据存储和访问需求。当数据量达到亿级甚至更高时，传统的垂直扩展方式成本高昂且存在瓶颈，水平扩展成为必然选择。分库分表作为最常见的水平扩展方案，能够有效分散数据存储压力和查询负载，提升系统整体性能。本节将深入探讨MySQL水平扩展的各种方案，分析其瓶颈和适用场景，并提供详细的实施指导。
目前业界数据库水平扩展方案介绍
1. 应用层分库分表
在应用层实现数据分片是最直接的方式：
// Sharding策略示例publicclassUserShardingStrategy{privatestaticfinalintSHARDING_COUNT=16;publicStringdetermineDatabase(LonguserId){intindex=(int)(userId%SHARDING_COUNT);return"user_db_"+index;}publicStringdetermineTable(LonguserId){intindex=(int)((userId/SHARDING_COUNT)%SHARDING_COUNT);return"user_table_"+index;}}// MyBatis集成分片@Select("SELECT * FROM user_table_${tableIndex} WHERE user_id = #{userId}")UserfindUser(@Param("tableIndex")inttableIndex,@Param("userId")LonguserId);2. 中间件分库分表
使用专业的分库分表中间件：
ShardingSphere
# ShardingSphere配置示例dataSources:ds0:url:jdbc:mysql://localhost:3306/ds0username:rootpassword:passwordds1:url:jdbc:mysql://localhost:3306/ds1username:rootpassword:passwordrules:-!SHARDINGtables:user:actualDataNodes:ds${0..1}.user_${0..3}tableStrategy:standard:shardingColumn:user_idshardingAlgorithmName:user-table-inlinedatabaseStrategy:standard:shardingColumn:user_idshardingAlgorithmName:user-database-inlineshardingAlgorithms:user-table-inline:type:INLINEprops:algorithm-expression:user_${user_id % 4}user-database-inline:type:INLINEprops:algorithm-expression:ds${user_id % 2}MyCAT
<!-- MyCAT配置示例 --><?xml version="1.0"?><!DOCTYPEmycat:schemaSYSTEM"schema.dtd"><mycat:schemaxmlns:mycat="http://io.mycat/"><schemaname="TESTDB"checkSQLschema="false"sqlMaxLimit="100"><tablename="user"dataNode="dn1,dn2,dn3,dn4"rule="sharding-by-mod"/></schema><dataNodename="dn1"dataHost="host1"database="db1"/><dataNodename="dn2"dataHost="host1"database="db2"/><dataNodename="dn3"dataHost="host2"database="db1"/><dataNodename="dn4"dataHost="host2"database="db2"/><dataHostname="host1"maxCon="1000"minCon="10"balance="0"writeType="0"dbType="mysql"dbDriver="native"><heartbeat>select 1</heartbeat><writeHosthost="hostM1"url="localhost:3306"user="root"password="password"/></dataHost></mycat:schema>3. 数据库代理层
使用代理层实现透明分片：
ProxySQL
# ProxySQL配置示例 mysql_servers: ( { hostgroup_id = 1, hostname = "192.168.1.101", port = 3306 }, { hostgroup_id = 1, hostname = "192.168.1.102", port = 3306 }, { hostgroup_id = 2, hostname = "192.168.1.103", port = 3306 }, { hostgroup_id = 2, hostname = "192.168.1.104", port = 3306 } ) mysql_users: ( { username = "app_user", password = "password", default_hostgroup = 1 } ) mysql_query_rules: ( { rule_id = 1, active = 1, match_digest = "^SELECT.*user_id=([0-9]+)", destination_hostgroup = 1, apply = 1 } )4. 新一代分布式数据库
TiDB
-- TiDB兼容MySQL语法，自动处理分片CREATETABLEuser(user_idBIGINTPRIMARYKEYAUTO_RANDOM,nameVARCHAR(100),emailVARCHAR(100),created_atTIMESTAMPDEFAULTCURRENT_TIMESTAMP);-- 查询时无需关心分片细节SELECT*FROMuserWHEREuser_id=123456789;每种水平扩展方案容易碰上的瓶颈
1. 应用层分库分表瓶颈
复杂查询支持有限
// 跨分片JOIN查询复杂// 原始SQL（单库）SELECT u.name,o.order_amount FROM user u JOIN orders o ON u.user_id=o.user_id WHERE u.user_id BETWEEN1000AND2000;// 分片后需要应用层处理publicList<UserOrderInfo>getUserOrders(LongstartUserId,LongendUserId){List<UserOrderInfo>result=newArrayList<>();// 1. 确定涉及的分片Set<String>shards=determineShards(startUserId,endUserId);// 2. 分别查询各分片for(Stringshard:shards){List<User>users=userMapper.selectUsersFromShard(shard,startUserId,endUserId);List<Long>userIds=users.stream().map(User::getUserId).collect(Collectors.toList());List<Order>orders=orderMapper.selectOrdersByUserIds(shard,userIds);// 3. 应用层JOINresult.addAll(mergeUserOrders(users,orders));}returnresult;}事务处理复杂
// 分布式事务处理@ShardingTransactionType(TransactionType.XA)@TransactionalpublicvoidcreateUserAndOrder(Useruser,Orderorder){// 在不同分片上创建用户和订单userService.createUser(user);orderService.createOrder(order);}2. 中间件分库分表瓶颈
性能损耗
-- 中间件解析和路由SQL需要额外时间-- 复杂SQL可能导致中间件成为瓶颈SELECTu.*,o.*