MyBatisPlus分表策略应对海量语音记录存储-平芜编程栈

MyBatisPlus分表策略应对海量语音记录存储

在虚拟主播、有声书和短视频配音等应用爆发的今天，语音合成技术正以前所未有的速度渗透进内容生产链条。以B站开源的IndexTTS 2.0为代表的零样本自回归模型，仅需5秒参考音频即可完成高质量音色克隆与情感控制，极大降低了专业语音生成门槛。但随之而来的，是系统每天产生的百万级甚至千万级语音记录——这些数据不仅包含音频元信息，还涵盖了用户行为、控制参数、生成质量反馈等多个维度。

面对如此庞大的写入压力和复杂的查询需求，传统的单表结构很快就会成为性能瓶颈：索引膨胀导致查询变慢，频繁插入引发锁竞争，备份恢复耗时剧增……这些问题如果不提前解决，轻则影响用户体验，重则威胁系统稳定性。

要破局，关键在于数据分片。而在这个场景下，MyBatisPlus + ShardingSphere-JDBC的组合提供了一套轻量、灵活且易于集成的解决方案。更重要的是，它允许我们根据业务特征设计出真正“贴地飞行”的分表策略，而不是简单粗暴地按ID取模完事。

数据从哪来？先看清楚业务源头

语音合成平台的数据不是凭空产生的，每一条speech_record都对应一次真实的合成请求。而 IndexTTS 2.0 的几项核心能力，恰恰决定了这些数据的形态和分布规律。

毫秒级时长控制：高频小批量写入的源头

这项功能允许开发者精确指定输出音频的播放时长（比如0.75x~1.25x），广泛应用于短视频配音、动画口型同步等对音画对齐要求极高的场景。每次调用都会生成一条带有duration_target_ms、actual_duration_ms、时间戳等字段的日志。

这类操作的特点是：
-频率高：一个视频可能包含数十个片段，每个片段都是一次独立请求；
-数据结构固定：几乎每次都携带相同的元信息；
-强时间序性：天然适合按时间维度组织。

这意味着，如果不做分表，短短几个月内单表就可能积累上亿条记录，查询某天的成功率或平均生成时长都会变得异常缓慢。

音色-情感解耦：带来丰富的标签体系

IndexTTS 2.0 支持将“谁在说话”（音色）和“怎么说话”（情感）分离控制。你可以用A的声音+ B的情绪，甚至通过自然语言描述如“愤怒地质问”来驱动情感生成。这背后会产生大量结构化标签：

private String voiceId; // 音色ID private String emotionType; // 情感类型：happy/angry/calm... private String controlMethod; // 控制方式：prompt/reference/builtin private String promptText; // 用户输入的情感描述

这些字段具有很高的统计分析价值。运营团队常需要回答诸如“最近一周最火的情感类型是什么？”、“哪种控制方式的失败率最高？”等问题。如果所有数据挤在一张表里，这类多维聚合查询会非常吃力。

零样本音色克隆：用户行为追踪的核心来源

只需上传一段5秒音频，系统就能提取音色嵌入向量并用于后续合成。这个过程虽然快，但每一次调用都会留下痕迹：user_id、audio_duration、sample_rate、clone_similarity_score等指标构成了典型的用户行为日志。

问题在于，部分头部用户或热门音色可能会被反复调用，形成热点数据集中的现象。例如某个虚拟偶像的音色被大量创作者使用，相关记录集中在少数几个分区，造成读写倾斜。

多语言支持：引入地理与语言属性

IndexTTS 2.0 支持中、英、日、韩等多种语言，并能处理跨语言混合输入。这意味着每条记录还可以打上language_code（zh/en/ja/ko）和潜在的region标签。

这种特性为数据划分提供了新的维度。例如，我们可以针对不同语言组设置独立的存储策略，既便于本地化运营分析，也符合某些地区的数据合规要求。

分表不是目的，合理路由才是关键

很多团队一开始分表，就是简单地按user_id % N取模。看似均匀，实则隐患重重：一旦某个用户突然爆红，他的请求量激增，对应的数据库实例可能瞬间被打满。

真正的分表设计，必须结合数据增长趋势、访问模式和运维成本综合权衡。以下是我们在实践中总结出的一套分层策略。

主分片策略：按时间维度拆分（Time-based Sharding）

考虑到语音记录具有强烈的时间局部性——绝大多数查询都是查“最近几天”或“本月”的数据——我们采用按月分表的方式：

speech_record_202504 speech_record_202505 speech_record_202506 ...

为什么选“月”而不是“天”？

粒度	优点	缺点
按天	单表更小，查询更快	表数量太多，DDL管理复杂
按月	平衡容量与管理成本	单表可能达数百万行

经过测算，我们的平台日均写入约80万条记录，单月约2400万条。MySQL 在单表千万级以下仍能保持良好性能，因此按月分表是一个合理的折中选择。

如何实现自动路由？

借助ShardingSphere-JDBC，我们只需在配置文件中定义分片规则：

spring: shardingsphere: rules: sharding: tables: speech_record: actual-data-nodes: ds$->{0..1}.speech_record_$->{202501..202512} table-strategy: standard: sharding-column: create_time sharding-algorithm-name: t-record-by-month sharding-algorithms: t-record-by-month: type: INTERVAL props: datetime-lower: "2025-01-01" datetime-upper: "2026-01-01" datetime-interval-amount: 1 datetime-interval-unit: MONTHS sharding-suffix-pattern: yyyyMM

MyBatisPlus 正常 CRUD 操作完全不受影响，框架会自动根据create_time字段计算应写入哪张表。

次分片策略：防止单表过热（Hash-based Sub-sharding）

仅靠时间分片还不够。假设某个月份内，某个热门音色被调用了上百万次，那么该月的表中就会出现严重的数据倾斜——这部分数据的读写压力远高于其他记录。

为此，我们在时间分片的基础上，引入二级分片键：对voice_id做哈希取模，将每月的数据进一步拆分为4个子表：

speech_record_202504_0 speech_record_202504_1 speech_record_202504_2 speech_record_202504_3

最终的路由逻辑如下：

// 伪代码示意 String tableName = "speech_record_" + DateUtils.formatMonth(createTime) + "_" + (Math.abs(voiceId.hashCode()) % 4);

这样即使某个音色特别受欢迎，其数据也会均匀分布在4个物理表中，避免单一表成为I/O瓶颈。

⚠️ 注意：这里不建议直接用voice_id % 4，因为字符串哈希可能存在碰撞。更好的做法是使用一致性哈希或预分配音色桶位。

查询优化：别让分页毁了性能

分表之后，最常见的陷阱就是跨表分页查询。比如运营想看“最近一个月状态为成功的所有记录”，然后 LIMIT 100 OFFSET 10000 —— 这种操作会在每个分片上执行全表扫描，再合并结果排序，性能极差。

正确的做法是：

限定时间范围：明确起止时间，减少扫描表的数量；
使用游标分页：基于create_time + id组合作为游标，避免 OFFSET；
建立宽索引：在各分片表上为常用查询字段建立联合索引。

例如：

-- 推荐索引 CREATE INDEX idx_status_time ON speech_record_YYYYMM_X (status, create_time DESC);

配合游标查询：

SELECT * FROM speech_record_202504_0 WHERE status = 1 AND create_time < '2025-04-30 00:00:00' AND (create_time, id) < ('2025-04-29 10:30:00', 123456) ORDER BY create_time DESC, id DESC LIMIT 100;

这种方式可以高效利用索引，避免全表扫描。

数据归档与冷热分离

语音记录的价值随时间衰减明显。超过6个月的历史数据极少被主动查询，更多用于离线分析或审计备查。继续放在主库不仅浪费资源，还会拖慢备份速度。

我们的做法是：

自动归档机制：每月初触发任务，将上上月的数据迁移到冷库存储（如TokuDB或列式数据库ClickHouse）；
保留元数据指针：主库保留极简记录（request_id, archive_flag, archive_date），方便必要时追溯；
透明访问层封装：对外提供统一查询接口，内部自动判断数据位置并路由。

这样一来，主库始终保持在一个可控的数据规模内，保障在线服务的响应速度。

不只是分表，更是数据治理的起点

很多人把分表当成纯粹的技术手段，其实它背后反映的是对数据生命周期的理解。

当我们决定“按月分”、“按音色模”、“建汇总表”的时候，本质上是在回答三个问题：

哪些数据最重要？→ 最近的数据优先保障性能；
谁在用这些数据？→ 运营查报表、开发查日志、算法做训练；
它们会被怎么用？→ 实时查询 vs 批量分析 vs 合规留存。

正是基于这样的思考，我们才构建出了这套分层架构：

graph TD A[客户端请求] --> B{API网关} B --> C[TTS引擎] C --> D[异步写入语音记录] D --> E[MyBatisPlus + ShardingSphere] E --> F1[speech_record_YYYYMM_X] E --> F2[speech_record_YYYYMM_X] E --> F3[speech_record_YYYYMM_X] E --> F4[speech_record_YYYYMM_X] F1 --> G[实时查询服务] F2 --> G F3 --> H[每日定时任务] F4 --> H H --> I[speech_stats_daily 汇总表] H --> J[冷数据归档至ClickHouse] G --> K[运营后台 / 故障排查] I --> L[BI报表 / 趋势分析] J --> M[离线训练 / 审计追溯]

你看，分表不再是孤立的功能点，而是整个数据治理体系的入口。