单表数据量达到千万级时分库分表是最终方案。ShardingSphere 是目前最主流的中间件。一、什么时候需要分库分表单表 1000万行 → 索引深度增加B树变高 单库 QPS 5000 → 连接池不够 单库 500GB → 备份和恢复时间长 分库分表也要付出代价 跨库事务 → 分布式事务性能下降 跨库查询 → 需要汇总结果 分页排序 → 需要在应用层做二、分片策略-- 按用户 ID 取模-- user_id % 4 → 4 个库-- 优点数据均匀-- 缺点扩容需要迁移-- 按时间范围-- orders_202601, orders_202602...-- 优点便于归档-- 缺点当前月份是热点-- 按业务类型-- user_db, order_db, product_db-- 优点天然隔离-- 缺点跨库查询麻烦三、ShardingSphere 配置spring:shardingsphere:datasource:names:ds0,ds1ds0:url:jdbc:mysql://localhost:3306/seckill_0ds1:url:jdbc:mysql://localhost:3306/seckill_1rules:sharding:tables:seckill_order:actual-data-nodes:ds$-{0..1}.seckill_order_$-{0..1}database-strategy:standard:sharding-column:user_idsharding-algorithm-name:db_modtable-strategy:standard:sharding-column:order_idsharding-algorithm-name:table_modsharding-algorithms:db_mod:type:MODprops:sharding-count:2table_mod:type:MODprops:sharding-count:2// 插入时自动路由// user_id1001 → ds0, order_id2001 → _0// user_id1002 → ds1, order_id2002 → _1// 应用层完全无感知orderMapper.insert(order);四、分库后的查询// 带分片键查询 → 直接路由到一个库orderMapper.selectByUserId(1001L);// ✅// 不带分片键的查询 → 广播到所有库汇总结果orderMapper.selectAll();// ⚠️ 扫全库 觉得有用的话点赞 关注【张老师技术栈】吧每周更新 Java/Python/MySQL 实战干货不让你白来。