.NET 8 分库分表实战：AI 辅助构建高性能订单系统架构

当你的订单表从百万级增长到千万级，查询响应时间从毫秒级飙升到秒级，你是否开始怀疑自己的数据库架构设计？这不仅是性能问题，更是业务增长的“甜蜜烦恼”。传统的单库单表架构在数据洪流面前，就像一条狭窄的单行道，迟早会陷入拥堵。

今天，我们不再空谈“分库分表”的概念，而是聚焦于一个更实际的问题：如何在一个成熟的 .NET WebAPI 项目中，平滑、稳定地引入分库分表架构，并让 AI 成为这个过程中的“架构师助理”，而非一个噱头？

很多人以为分库分表只是技术选型问题，选个中间件就完事了。但真正的挑战在于：数据如何路由？历史数据如何迁移？跨分片的复杂查询如何实现？这些问题处理不当，轻则数据错乱，重则服务宕机。

本文将带你完成一个企业级的综合实战：基于 .NET 8 WebAPI，整合分库分表架构。我们不仅会实现数据分片和路由分发，更会重点解决跨表查询这一经典难题。更重要的是，我们会探讨如何利用 AI 工具（如 Cursor、GitHub Copilot）来辅助我们进行架构设计、代码生成和 SQL 优化，提升整个落地过程的效率与可靠性。

读完本文，你将获得：

1. 一套可立即复用的 .NET 分库分表项目脚手架。
2. 清晰的数据路由、迁移、查询解决方案。
3. 利用 AI 辅助进行架构决策和编码实战的具体方法。
4. 规避企业级落地中常见“深坑”的 checklist。

1. 这篇文章真正要解决的问题：从单点瓶颈到弹性扩展

为什么你的 .NET 应用在数据量大了之后就变慢了？根本原因往往不在代码逻辑，而在数据库 I/O 瓶颈。当所有请求都指向同一个数据库、同一张表时，磁盘 IO、CPU、连接数、锁竞争都会成为性能天花板。

分库分表的核心目标，是通过水平拆分，将数据分散到多个物理节点上，从而实现：

• 性能提升：分散读写压力，降低单点负载。
• 容量扩展：突破单机磁盘和内存的限制。
• 可用性增强：单一数据库故障不影响全部数据。

但是，引入分库分表带来了新的复杂度：

1. 路由问题：一条数据该插入哪个库、哪张表？
2. 查询问题：如何高效地进行跨分片查询（如ORDER BY ... LIMIT）？
3. 事务问题：如何保证跨库事务的一致性？（本文会探讨最终一致性方案）
4. 迁移问题：存量数据如何平滑迁移到新架构？

本文将围绕一个具体的业务场景——电商订单系统——来展开。我们将从零开始，构建一个支持分库分表的 WebAPI 服务，并逐一攻克上述难题。同时，我们会展示如何在与 AI 结对编程的过程中，让它帮助我们思考架构权衡、生成样板代码、优化复杂 SQL，让“AI 赋能”落到实处。

2. 基础概念与核心原理

在开始编码之前，必须厘清几个关键概念，避免后续混淆。

2.1 分库 vs 分表

• 分库：将数据分布到不同的数据库实例中。例如，订单库OrderDB0、OrderDB1。
  • 优点：彻底隔离资源（CPU、内存、IO），提升并发能力和可用性。
  • 缺点：跨库事务复杂，Join 操作几乎不可行。
• 分表：将数据分布到同一个数据库实例的不同表中。例如，订单表order_202401、order_202402。
  • 优点：解决单表数据量过大导致的索引效率下降问题。
  • 缺点：仍在同一数据库实例，无法解决硬件资源瓶颈。

在实际项目中，通常结合使用，即分库分表。例如，2个库，每个库16张表。

2.2 分片键

决定数据如何分布的字段，称为分片键。选择至关重要：

• 常用分片键：用户ID、订单ID、商户ID、地区编号。
• 选择原则：
  1. 数据均匀：保证数据能相对均匀地分布到各个分片，避免数据倾斜。
  2. 查询高频：大部分查询条件都应包含分片键，这样才能直接定位到具体分片，避免全库扫描。 在我们的订单系统中，选择UserId作为分片键是合理的，因为业务查询大多围绕用户展开。

2.3 路由策略

如何根据分片键的值计算出目标库和表？常见策略有：

• 取模：分片序号 = UserId % 分片总数。简单均匀，但扩容时需要迁移大量数据。
• 范围：按UserId的范围划分，如[0, 1000)在分片0。扩容友好，但容易产生数据冷热不均。
• 一致性哈希：扩容时仅需迁移少量数据，是更优的分布式方案。 本文将采用取模策略进行演示，因其原理直观，便于理解。在“最佳实践”章节会讨论一致性哈希的升级方案。

2.4 AI 在其中的角色

AI（如 GitHub Copilot, Cursor）不是来替代架构师，而是作为高级助手：

• 架构脑暴：向 AI 描述业务场景，让它列出多种分片策略及其优缺点。
• 代码生成：根据你的设计，快速生成数据访问层（DAL）的样板代码、实体类、仓储接口。
• SQL 优化：将复杂的跨分片查询逻辑描述给 AI，让它帮你写出优化后的 UNION ALL 查询或建议物化视图方案。
• 异常处理：生成健壮性的重试、降级、熔断代码模板。

3. 环境准备与前置条件

请确保你的开发环境满足以下要求。我们将使用当前主流的 .NET 8 和 Entity Framework Core 8。

• 操作系统：Windows 10/11, macOS, 或 Linux (Ubuntu 20.04+)
• SDK： .NET 8.0 SDK 或更高版本。
• IDE/编辑器：
  • Visual Studio 2022 (17.8+) 或
  • Visual Studio Code + C# 扩展
  • 强烈推荐安装 Cursor 或 GitHub Copilot 扩展，以便体验 AI 辅助编码。
• 数据库：MySQL 8.0 或 PostgreSQL 14+。本文以MySQL为例。
• 数据库管理工具：MySQL Workbench, DBeaver 或命令行客户端。
• 项目模板：我们将使用 ASP.NET Core Web API 模板。

打开终端，创建我们的项目骨架：

# 创建解决方案和WebAPI项目 dotnet new sln -n OrderShardingDemo dotnet new webapi -n OrderShardingDemo.API -f net8.0 dotnet sln add OrderShardingDemo.API/OrderShardingDemo.API.csproj # 创建类库项目用于核心逻辑 dotnet new classlib -n OrderShardingDemo.Core -f net8.0 dotnet new classlib -n OrderShardingDemo.Infrastructure -f net8.0 dotnet sln add OrderShardingDemo.Core/OrderShardingDemo.Core.csproj dotnet sln add OrderShardingDemo.Infrastructure/OrderShardingDemo.Infrastructure.csproj # 添加项目引用 cd OrderShardingDemo.API dotnet add reference ../OrderShardingDemo.Core dotnet add reference ../OrderShardingDemo.Infrastructure cd ../OrderShardingDemo.Infrastructure dotnet add reference ../OrderShardingDemo.Core

4. 核心流程拆解：从设计到查询

整个实战流程可以分解为以下关键步骤，我们将逐一实现：

1. 领域模型设计：定义订单实体。
2. 分片配置管理：如何配置数据库连接和分片规则。
3. 动态数据源路由：实现一个能根据UserId动态选择连接字符串的DbContext。
4. 分表命名与创建：按规则生成物理表名，并确保表结构存在。
5. 数据写入：在插入订单时，自动路由到正确的库和表。
6. 精确查询：根据UserId和OrderId查询单条订单。
7. 跨分片查询：实现不包含分片键的查询（如管理员查询所有订单）。
8. AI 辅助实战：在关键步骤引入 AI 工具提升效率。

5. 完整示例与代码实现

5.1 领域模型与仓储接口 (Core 层)

首先，在OrderShardingDemo.Core项目中定义领域实体和仓储接口。

// 文件：OrderShardingDemo.Core/Entities/Order.cs namespace OrderShardingDemo.Core.Entities; public class Order { public long Id { get; set; } // 订单ID，全局唯一 public string OrderNumber { get; set; } = null!; // 订单号 public long UserId { get; set; } // 分片键 public decimal Amount { get; set; } public int Status { get; set; } // 订单状态 public string? Remark { get; set; } public DateTime CreateTime { get; set; } = DateTime.UtcNow; public DateTime UpdateTime { get; set; } = DateTime.UtcNow; }

// 文件：OrderShardingDemo.Core/Interfaces/IOrderRepository.cs using OrderShardingDemo.Core.Entities; namespace OrderShardingDemo.Core.Interfaces; public interface IOrderRepository { Task<Order?> GetByIdAsync(long orderId, long userId); Task<IEnumerable<Order>> GetByUserIdAsync(long userId, int skip, int take); Task<IEnumerable<Order>> GetAllAsync(int skip, int take); // 跨分片查询 Task<long> AddAsync(Order order); Task<bool> UpdateAsync(Order order); Task<bool> DeleteAsync(long orderId, long userId); }

AI 辅助提示：在 Cursor 中，你可以输入注释// Define an Order entity with sharding key UserId和// Create repository interface for Order with sharding support，AI 能快速生成符合规范的实体和接口代码，你只需调整细节。

5.2 分片配置与路由规则 (Infrastructure 层)

在OrderShardingDemo.Infrastructure项目中，我们实现配置和路由逻辑。

首先，定义分片配置模型：

// 文件：OrderShardingDemo.Infrastructure/Sharding/ShardingOptions.cs namespace OrderShardingDemo.Infrastructure.Sharding; public class ShardingOptions { public List<DatabaseNode> Databases { get; set; } = new(); // 数据库节点列表 public int TablePerDatabase { get; set; } = 4; // 每个库分多少张表 } public class DatabaseNode { public string Name { get; set; } = null!; // 节点名，如 DB0 public string ConnectionString { get; set; } = null!; }

在appsettings.json中配置：

// 文件：OrderShardingDemo.API/appsettings.json { "Sharding": { "TablePerDatabase": 4, "Databases": [ { "Name": "DB0", "ConnectionString": "Server=localhost;Port=3306;Database=OrderDB0;Uid=root;Pwd=your_password;" }, { "Name": "DB1", "ConnectionString": "Server=localhost;Port=3306;Database=OrderDB1;Uid=root;Pwd=your_password;" } ] }, // ... 其他配置 }

核心：实现分片路由计算器。

// 文件：OrderShardingDemo.Infrastructure/Sharding/ShardingRouter.cs using Microsoft.Extensions.Options; namespace OrderShardingDemo.Infrastructure.Sharding; public interface IShardingRouter { (string dbName, string tableName) Route(long userId); } public class ModShardingRouter : IShardingRouter { private readonly ShardingOptions _options; public ModShardingRouter(IOptions<ShardingOptions> options) { _options = options.Value; } public (string dbName, string tableName) Route(long userId) { // 1. 计算数据库索引 int dbCount = _options.Databases.Count; int dbIndex = (int)(userId % dbCount); var targetDb = _options.Databases[dbIndex]; // 2. 计算表索引 int tableIndex = (int)(userId / dbCount % _options.TablePerDatabase); // 3. 生成物理表名，例如 order_0, order_1 ... order_3 string physicalTableName = $"order_{tableIndex}"; return (targetDb.Name, physicalTableName); } }

5.3 动态 DbContext 与表名替换 (Infrastructure 层)

这是最关键的环节，我们需要一个能动态切换连接字符串和表名的DbContext。

// 文件：OrderShardingDemo.Infrastructure/Data/OrderShardingDbContext.cs using Microsoft.EntityFrameworkCore; using OrderShardingDemo.Core.Entities; namespace OrderShardingDemo.Infrastructure.Data; public class OrderShardingDbContext : DbContext { private readonly string _connectionString; private readonly string _tableNameSuffix; // 例如 "_0" public DbSet<Order> Orders { get; set; } public OrderShardingDbContext(string connectionString, string tableNameSuffix) { _connectionString = connectionString; _tableNameSuffix = tableNameSuffix; } protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { // 使用传入的连接字符串 optionsBuilder.UseMySql(_connectionString, ServerVersion.AutoDetect(_connectionString)); } protected override void OnModelCreating(ModelBuilder modelBuilder) { base.OnModelCreating(modelBuilder); // 动态映射实体到物理表名 modelBuilder.Entity<Order>().ToTable($"order{_tableNameSuffix}"); } }

注意：这里为了简化，每次查询都创建新的DbContext实例。在生产环境中，需要考虑DbContext的生命周期管理和连接池优化。

5.4 仓储实现 (Infrastructure 层)

现在实现IOrderRepository。这里会用到路由器和DbContext工厂。

// 文件：OrderShardingDemo.Infrastructure/Repositories/OrderRepository.cs using Microsoft.EntityFrameworkCore; using OrderShardingDemo.Core.Entities; using OrderShardingDemo.Core.Interfaces; using OrderShardingDemo.Infrastructure.Data; using OrderShardingDemo.Infrastructure.Sharding; namespace OrderShardingDemo.Infrastructure.Repositories; public class OrderRepository : IOrderRepository { private readonly IShardingRouter _router; private readonly IOptions<ShardingOptions> _shardingOptions; public OrderRepository(IShardingRouter router, IOptions<ShardingOptions> shardingOptions) { _router = router; _shardingOptions = shardingOptions; } private OrderShardingDbContext CreateDbContext(long userId) { var (dbName, tableName) = _router.Route(userId); // 根据 dbName 找到对应的连接字符串 var targetDb = _shardingOptions.Value.Databases.First(d => d.Name == dbName); // tableName 是类似 "order_0"，我们需要后缀 "_0" var suffix = tableName.Split('_').Last(); // 获取 "_0" 中的 "0" return new OrderShardingDbContext(targetDb.ConnectionString, suffix); } public async Task<Order?> GetByIdAsync(long orderId, long userId) { await using var context = CreateDbContext(userId); return await context.Orders.FirstOrDefaultAsync(o => o.Id == orderId); } public async Task<IEnumerable<Order>> GetByUserIdAsync(long userId, int skip, int take) { await using var context = CreateDbContext(userId); return await context.Orders .Where(o => o.UserId == userId) .OrderByDescending(o => o.CreateTime) .Skip(skip) .Take(take) .AsNoTracking() .ToListAsync(); } public async Task<long> AddAsync(Order order) { await using var context = CreateDbContext(order.UserId); context.Orders.Add(order); await context.SaveChangesAsync(); return order.Id; } // 更新和删除方法类似，需要确保操作正确的分片 // ... 省略 UpdateAsync 和 DeleteAsync 实现 }

5.5 实现跨分片查询

这是分库分表的难点。对于GetAllAsync这种不包含分片键的查询，我们需要查询所有分片，然后在内存中聚合、排序、分页。注意性能损耗。

// 在 OrderRepository 中添加 GetAllAsync 方法 public async Task<IEnumerable<Order>> GetAllAsync(int skip, int take) { var allOrders = new List<Order>(); var tasks = new List<Task<List<Order>>>(); // 并行查询所有数据库的所有表 foreach (var db in _shardingOptions.Value.Databases) { for (int i = 0; i < _shardingOptions.Value.TablePerDatabase; i++) { var suffix = i.ToString(); tasks.Add(QuerySingleTableAsync(db.ConnectionString, suffix, skip, take)); } } var results = await Task.WhenAll(tasks); foreach (var list in results) { allOrders.AddRange(list); } // 内存中排序和分页（仅适用于数据量不大的情况，或结合其他方案如“中间件”或“汇总表”） return allOrders .OrderByDescending(o => o.CreateTime) .Skip(skip) .Take(take) .ToList(); } private async Task<List<Order>> QuerySingleTableAsync(string connectionString, string tableSuffix, int skip, int take) { // 这里简化处理，实际查询可能需要更复杂的分页逻辑 await using var context = new OrderShardingDbContext(connectionString, tableSuffix); return await context.Orders .OrderByDescending(o => o.CreateTime) .Skip(skip) // 注意：这里 skip/take 是针对单表的，逻辑不精确 .Take(take) .AsNoTracking() .ToListAsync(); }

重要说明：上述GetAllAsync实现是简化的，存在逻辑问题（每个表都Skip/Take会导致最终结果不准确）。真正的跨分片分页需要更复杂的方案，如：

1. 二次查询法：先查所有分片拿到ID，再根据ID去各分片取详情。
2. 使用中间件：如 ShardingSphere、MyCat，它们能解析 SQL 并重写。
3. 建立汇总/广播表：将关键信息同步到一个公共库查询。 在“最佳实践”章节我们会深入讨论。

5.6 WebAPI 控制器与依赖注入

最后，在 API 层暴露接口。

// 文件：OrderShardingDemo.API/Controllers/OrdersController.cs using Microsoft.AspNetCore.Mvc; using OrderShardingDemo.Core.Entities; using OrderShardingDemo.Core.Interfaces; namespace OrderShardingDemo.API.Controllers; [ApiController] [Route("api/[controller]")] public class OrdersController : ControllerBase { private readonly IOrderRepository _orderRepository; public OrdersController(IOrderRepository orderRepository) { _orderRepository = orderRepository; } [HttpGet("{userId}/{orderId}")] public async Task<ActionResult<Order>> GetOrder(long userId, long orderId) { var order = await _orderRepository.GetByIdAsync(orderId, userId); if (order == null) return NotFound(); return order; } [HttpGet("user/{userId}")] public async Task<ActionResult<IEnumerable<Order>>> GetOrdersByUser(long userId, [FromQuery] int page = 1, [FromQuery] int size = 20) { var skip = (page - 1) * size; var orders = await _orderRepository.GetByUserIdAsync(userId, skip, size); return Ok(orders); } [HttpPost] public async Task<ActionResult<long>> CreateOrder([FromBody] Order order) { // 简单验证 if (order.UserId <= 0) return BadRequest("UserId is required."); var id = await _orderRepository.AddAsync(order); return CreatedAtAction(nameof(GetOrder), new { userId = order.UserId, orderId = id }, id); } // 管理员接口：跨分片查询（慎用，需加权限控制） [HttpGet("admin/all")] public async Task<ActionResult<IEnumerable<Order>>> GetAllOrders([FromQuery] int page = 1, [FromQuery] int size = 20) { var skip = (page - 1) * size; var orders = await _orderRepository.GetAllAsync(skip, size); return Ok(orders); } }

在Program.cs中注册服务：

// 文件：OrderShardingDemo.API/Program.cs using OrderShardingDemo.Core.Interfaces; using OrderShardingDemo.Infrastructure.Repositories; using OrderShardingDemo.Infrastructure.Sharding; var builder = WebApplication.CreateBuilder(args); // 添加服务到容器。 builder.Services.AddControllers(); builder.Services.AddEndpointsApiExplorer(); builder.Services.AddSwaggerGen(); // 配置分片选项 builder.Services.Configure<ShardingOptions>(builder.Configuration.GetSection("Sharding")); // 注册分片路由器和仓储 builder.Services.AddSingleton<IShardingRouter, ModShardingRouter>(); builder.Services.AddScoped<IOrderRepository, OrderRepository>(); var app = builder.Build(); // 配置 HTTP 请求管道。 if (app.Environment.IsDevelopment()) { app.UseSwagger(); app.UseSwaggerUI(); } app.UseHttpsRedirection(); app.UseAuthorization(); app.MapControllers(); app.Run();

6. 运行结果与效果验证

6.1 数据库准备

在 MySQL 中创建两个数据库，并在每个库中创建 4 张订单表。

-- 在 DB0 和 DB1 中分别执行 CREATE DATABASE IF NOT EXISTS OrderDB0; USE OrderDB0; CREATE TABLE order_0 ( Id BIGINT PRIMARY KEY AUTO_INCREMENT, OrderNumber VARCHAR(50) NOT NULL, UserId BIGINT NOT NULL, Amount DECIMAL(18,2) NOT NULL, Status INT NOT NULL, Remark TEXT, CreateTime DATETIME NOT NULL, UpdateTime DATETIME NOT NULL, INDEX idx_user_id (UserId), INDEX idx_create_time (CreateTime) ); -- 创建 order_1, order_2, order_3 表（结构相同） CREATE TABLE order_1 LIKE order_0; CREATE TABLE order_2 LIKE order_0; CREATE TABLE order_3 LIKE order_0;

6.2 启动与测试

1. 在appsettings.json中配置正确的 MySQL 连接字符串。
2. 在终端运行：

   cd OrderShardingDemo.API dotnet run

3. 打开 Swagger UI（通常是https://localhost:PORT/swagger）。
4. 测试接口：
   • POST /api/orders：创建订单。使用UserId为 1001 和 1002 分别创建订单。根据我们的取模规则（2个库），1001 % 2 = 1，应插入DB1；1002 % 2 = 0，应插入DB0。你可以通过查看不同数据库的表来验证数据是否被正确路由。
   • GET /api/orders/user/{userId}：根据用户ID查询。此查询会直接定位到特定分片，速度很快。
   • GET /api/orders/admin/all：查询所有订单。观察控制台 SQL 日志，会发现它向所有 8 张表（2库 x 4表）发出了查询。这是性能瓶颈的直观体现。

7. 常见问题与排查思路

8. 最佳实践与工程建议

8.1 分片键选择与设计

• 业务相关性：分片键必须是高频查询条件。我们的订单系统以UserId查询为主，所以它是好选择。如果系统主要按OrderNumber查询，则应考虑将其作为分片键或建立映射关系。
• 避免热点：避免使用单调递增的 ID 作为唯一分片键（如自增主键），这会导致数据全写到一个分片。可以采用“组合分片键”（如UserId+ 时间）或“散列分片键”（对UserId取哈希）。
• 不可变性：分片键一旦确定，不应修改。业务设计时需考虑此约束。

8.2 解决跨分片查询的工程方案

对于无法避免的跨分片查询，有以下几种方案：

1. 汇总表/物化视图：定期将各分片的关键字段（如订单ID、状态、时间）同步到一个中心库的单表中，用于复杂查询。这是最常用且有效的方案。
2. 搜索引擎：将数据同步到 Elasticsearch 或 Solr 中，利用其强大的分布式检索能力。
3. 使用专业中间件：如 Apache ShardingSphere（支持 .NET 的 ShardingSphere-Proxy 或客户端模式），它可以透明地解析 SQL，将跨分片查询重写为对多个数据库的执行，并在内存中合并结果。
4. 业务妥协：与产品经理沟通，限制查询条件，例如必须选择时间范围、用户范围等，从而缩小分片搜索范围。

8.3 数据迁移与扩容方案

• 规划先行：设计之初就应预估未来 3-5 年的数据量，预留足够的分片数（例如，一开始就创建 16 个逻辑分片，但只部署 2 个物理库，每个库承载 8 个逻辑分片）。未来扩容时，只需将逻辑分片迁移到新的物理库即可。
• 一致性哈希：将取模策略升级为一致性哈希环，可以在扩容时仅迁移1/N的数据（N 为新节点数），大幅减少影响。
• 双写与灰度：迁移期间，新旧集群同时写入，通过定时任务同步差异数据，并逐步将读流量切至新集群。

8.4 利用 AI 提升架构与编码效率

在整个过程中，AI 可以成为得力助手：

• 设计评审：将你的分片方案描述给 Cursor，让它帮你分析潜在的数据倾斜风险、事务问题。
• 代码生成：让 AI 根据你的实体和接口定义，生成完整的仓储实现、DTO、甚至单元测试骨架。
• SQL 优化：将慢查询日志中的 SQL 发给 AI，让它给出索引建议、查询重写方案。
• 异常处理：提示 AI：“为这个分片查询方法添加 Polly 策略，实现数据库访问失败后的重试和熔断。” AI 能生成高质量的弹性代码。
• 文档生成：让 AI 根据代码注释，生成 API 文档或架构设计文档。

关键提示：AI 生成的代码和方案必须经过你的严格审查和测试，不能直接用于生产。

8.5 监控与运维

• 关键指标监控：每个分片数据库的连接数、QPS、慢查询、磁盘 IO。
• 业务指标监控：各分片的数据量分布，确保没有严重倾斜。
• 链路追踪：在日志中记录每次数据库操作的目标分片信息，便于问题排查。

9. 总结与后续学习方向

通过这个完整的实战项目，我们不仅实现了一个基础的 .NET 分库分表 WebAPI，更重要的是，我们触及了企业级落地中的核心挑战：路由、跨片查询、扩容。分库分表不是简单的“拆数据”，而是一套以数据分布为核心的系统性架构设计。

本文的核心价值在于提供了一个可运行的、结构清晰的起点。你可以在此基础上：

1. 引入更优的路由策略：将ModShardingRouter替换为ConsistentHashShardingRouter。
2. 集成专业中间件：研究并集成 ShardingSphere-Proxy，将复杂的 SQL 解析与路由交给专业组件。
3. 实现读写分离：在每个分片数据库的主从架构上，让仓储层支持读从库、写主库。
4. 完善事务方案：对于跨分片事务，研究基于消息队列的最终一致性方案（如发券、扣库存）。
5. 构建管理平台：开发一个简单的管理界面，用于监控分片状态、执行数据迁移任务。

分库分表是后端工程师迈向架构师的必修课。它没有银弹，需要你深刻理解业务，在数据一致性、性能、复杂度之间做出权衡。希望这个项目能成为你探索分布式数据架构的一块坚实垫脚石。建议你将代码收藏，在需要时随时参考、修改和扩展。