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"//schemadataNodename="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"heartbeatselect 1/heartbeatwriteHosthost="hostM1"url="localhost:3306"user="root"password="password"//dataHost/mycat:schema3. 数据库代理层使用代理层实现透明分片：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;// 分片后需要应用层处理publicListUserOrderInfogetUserOrders(LongstartUserId,LongendUserId){ListUserOrderInforesult=newArrayList();// 1. 确定涉及的分片SetStringshards=determineShards(startUserId,endUserId);// 2. 分别查询各分片for(Stringshard:shards){ListUserusers=userMapper.selectUsersFromShard(shard,startUserId,endUserId);ListLonguserIds=users.stream().map(User::getUserId).collect(Collectors.toList());ListOrderorders=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.*