MyBatisPlus分表策略应对IndexTTS2海量任务数据-平芜编程栈

MyBatisPlus分表策略应对IndexTTS2海量任务数据

在AI语音合成服务进入大规模工业落地的今天，一个看似不起眼的技术细节——数据库表如何承载每天数十万级的任务记录——往往成为系统稳定性的关键瓶颈。以IndexTTS2 V23版本为例，随着情感控制、多音色切换等高级特性的上线，用户请求频率显著上升，后台生成的任务日志呈指数增长。短短几个月内，单张task_info表的数据量就突破了百万行，查询变慢、写入阻塞、归档困难等问题接踵而至。

面对这一挑战，我们没有选择盲目扩容或引入复杂中间件，而是回归数据本质：这些任务具有强烈的时间局部性——绝大多数访问集中在最近几天，历史数据则主要用于审计和统计。基于此特征，结合现有技术栈中的MyBatisPlus与ShardingSphere，我们设计了一套轻量、高效且可扩展的按月分表方案，成功将系统的读写性能拉回毫秒级响应水平。

为什么传统单表撑不住了？

先看一组真实场景下的问题表现：

用户提交任务后，前端“正在排队”提示迟迟不更新；
运维执行一条SELECT * FROM task_info WHERE status = 'pending' ORDER BY create_time DESC LIMIT 10，耗时超过3秒；
每月初手动清理上月数据时，DELETE操作锁表长达数分钟，影响线上服务。

根本原因在于，InnoDB引擎在大数据量下对B+树索引的维护成本急剧上升。即使有(create_time, status)联合索引，当表中存在超过80万条记录时，MySQL仍需遍历大量页节点才能定位目标数据。更糟糕的是，高并发写入时，主键自增机制引发的间隙锁竞争会导致insert性能断崖式下降。

这时候，分表不再是“优化选项”，而是维持系统可用性的必要手段。

分表不是重写代码，而是换一种“路由”方式

很多人一听到“分表”，第一反应是：“那岂不是要改DAO层？每个查询都得手动拼表名？”其实不然。现代持久层框架早已支持运行时动态路由，真正需要改变的，只是SQL执行前的那一层“翻译”逻辑。

MyBatisPlus本身并不提供完整的分库分表能力，但它开放了拦截器机制，允许我们在SQL真正发送给数据库之前，动态替换表名。这就是DynamicTableNameInnerInterceptor的核心价值——它像一个交通指挥员，在每条SQL出发前，根据预设规则为其分配正确的“车道”。

举个最简单的例子：

@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); DynamicTableNameInnerInterceptor dynamicInterceptor = new DynamicTableNameInnerInterceptor(); dynamicInterceptor.setDynamicTableNameHandler((sql, tableName) -> { if ("task_info".equals(tableName)) { return "task_info_" + LocalDate.now().format(DateTimeFormatter.ofPattern("yyyyMM")); } return tableName; }); interceptor.addInnerInterceptor(dynamicInterceptor); return interceptor; }

就这么几行代码，所有对task_info的CRUD操作，都会自动指向当前月份对应的物理表，比如task_info_202503。业务代码完全无感，Mapper接口照常使用：

@Mapper public interface TaskMapper { void insert(TaskInfo task); List<TaskInfo> selectByUserId(@Param("userId") String userId); }

这种方案适合初期尝试分表的团队——零侵入、低成本、见效快。但它的局限也很明显：只能做单一维度的简单映射，无法处理跨月查询，也不支持分片算法的精细化控制。

当需求变复杂：用ShardingSphere接管SQL生命周期

随着业务发展，我们很快遇到了新问题：

用户想查“过去三个月的任务列表”；
运营需要按user_id聚合分析高频使用者；
某些长尾任务跨月仍未完成，状态更新失败。

这时就必须引入更强大的分片引擎——Apache ShardingSphere-JDBC。它不再只是改表名，而是全程参与SQL的解析、改写、路由、执行和结果归并，真正实现了透明化分片。

YAML配置定义分片规则：

spring: shardingsphere: datasource: names: ds0 ds0: type: com.zaxxer.hikari.HikariDataSource jdbc-url: jdbc:mysql://localhost:3306/index_tts?useSSL=false&serverTimezone=UTC username: root password: root rules: sharding: tables: task_info: actual-data-nodes: ds0.task_info_$->{2024..2025}${202401..202512} table-strategy: standard: sharding-column: create_time sharding-algorithm-name: task-by-month sharding-algorithms: task-by-month: type: CLASS_BASED props: algorithm-class-name: com.example.shard.MonthShardingAlgorithm

配套的自定义分片算法：

public class MonthShardingAlgorithm implements StandardShardingAlgorithm<String> { @Override public String doSharding(Collection<String> availableTargetNames, PreciseShardingValue<String> shardingValue) { String rawTime = shardingValue.getValue(); try { LocalDate date = LocalDate.parse(rawTime.substring(0, 10)); String suffix = date.format(DateTimeFormatter.ofPattern("yyyyMM")); String targetTable = "task_info_" + suffix; if (availableTargetNames.contains(targetTable)) { return targetTable; } } catch (Exception e) { throw new IllegalArgumentException("Invalid create_time format: " + rawTime); } throw new IllegalArgumentException("No matching table for date: " + rawTime); } }

这套组合拳带来的好处远不止“自动分表”这么简单：

跨月查询自动合并结果：当你执行WHERE create_time BETWEEN '2025-01-01' AND '2025-03-31'，ShardingSphere会自动路由到task_info_202501、task_info_202502、task_info_202503三张表，并将结果集统一返回；
支持复杂查询条件：即便WHERE中没有分片键，也能通过广播机制保证语义正确（当然建议避免）；
未来可平滑演进：后续若需按user_id二次分片，只需调整策略，无需重构业务逻辑。

实战中的几个关键设计决策

1. 为什么选`create_time`而不是`user_id`作为分片键？

虽然按用户ID分片能实现负载均衡，但在我们的场景中并不适用：

多数查询都是时间范围驱动（如“今日任务”、“本周失败率”）；
少数大客户可能产生极高频请求，形成热点，反而加剧不均衡；
时间维度天然具备归档友好性，删旧数据就是DROP TABLE的事。

因此，时间是最符合业务访问模式的分片维度。

2. 表命名规范必须统一且可解析

我们采用task_info_YYYYMM格式，不仅便于程序识别，也极大简化了运维工作。例如：

-- 查看当前所有任务子表 SHOW TABLES LIKE 'task_info_%'; -- 快速定位某月数据 ANALYZE TABLE task_info_202503;

同时配合自动化脚本，每月初预创建未来6个月的空表，防止首次写入因表不存在而失败。

3. 索引不能少，每张子表都要有联合索引

尽管单表数据量已从百万降至十万级别，但如果缺少有效索引，性能依然堪忧。我们在每张子表上都强制建立了以下索引：

ALTER TABLE task_info_202503 ADD INDEX idx_create_status (create_time DESC, status);

这个组合能高效支撑最常见的两类查询：
- “最近N条待处理任务”
- “某时间段内各状态分布”

实测表明，加上该索引后，LIMIT分页查询速度提升约7倍。

4. 跨月查询要有心理准备：资源消耗会上升

虽然ShardingSphere能自动合并多表结果，但代价是连接数和内存占用增加。对于涉及超过3个月的历史查询，我们做了如下限制：

前端页面默认只展示最近90天；
超出范围的查询跳转至“数据分析平台”，由专用ETL流程处理；
在数据库层面设置max_connections_per_user防止单一请求耗尽资源。

效果验证：从卡顿到流畅的转变

上线分表方案后，关键指标变化如下：

指标	分表前	分表后	提升幅度
平均写入延迟	120ms	45ms	↓62.5%
关键查询P99延迟	3.2s	480ms	↓85%
单表数据量（月均）	~85万	~10万	↓88%
归档操作耗时	数分钟（delete）	<1s（drop）	接近无限

更重要的是，系统稳定性显著增强。过去每月初因归档导致的服务抖动彻底消失，DBA终于可以睡个安稳觉了。

写在最后：分表不是终点，而是数据治理的新起点

通过MyBatisPlus与ShardingSphere的协同，我们以极低的改造成本解决了IndexTTS2面临的存储瓶颈。但这只是一个开始。接下来，我们计划在这一架构基础上进一步演进：

冷热分离：将超过半年的数据迁移到 cheaper storage（如TiDB HTAP 或 OSS + ClickHouse），降低主库压力；
弹性扩表：开发定时Job，根据实际流量预测自动创建未来表，避免人工干预；
监控告警：为每个分片建立独立的QPS、延迟、容量监控，及时发现异常分片。

事实证明，面对AI服务带来的数据洪流，不必一开始就追求极致复杂的分布式架构。找准数据规律，用好现有工具，往往就能四两拨千斤。这套基于时间维度的分表方案，目前已作为标准模板推广至公司内部其他AI推理平台，包括图像生成、文本摘要等异步任务系统，展现出良好的通用性和可复制性。

MyBatisPlus分表策略应对IndexTTS2海量任务数据