MySQL优化在Qwen3智能字幕系统中的应用

1. 项目背景与挑战

我们最近在开发一个智能字幕生成系统，用的是Qwen3大模型来处理音视频内容。这个系统需要处理大量的媒体文件，每个文件都要经过语音识别、文本处理、时间轴对齐等多个步骤，最后生成高质量的字幕文件。

随着用户量增长，数据库压力越来越大。每天要处理几十万条字幕记录，查询速度明显变慢，有时候用户点开一个字幕文件要等好几秒才能加载出来。这显然影响了用户体验，也让我们开始认真审视数据库的性能问题。

MySQL作为我们系统的主要数据存储，承载着用户信息、媒体文件元数据、字幕内容、处理状态等关键数据。当数据量达到百万级别时，最初的数据库设计就显得有些力不从心了。

2. 数据库架构优化

2.1 表结构重新设计

我们首先分析了现有的表结构，发现有些表的设计不够合理。比如最初的字幕表把所有信息都放在一个大表里，包含了原始音频信息、处理状态、最终字幕内容等各种字段。这样不仅查询效率低，更新时也容易产生锁表问题。

我们重新设计了表结构，按照业务模块进行了垂直拆分。把用户信息、媒体文件元数据、字幕内容、处理日志等分到不同的表中，每个表只关注自己的核心数据。这样减少了单表的数据量，也降低了表之间的耦合度。

-- 优化前的表结构
CREATE TABLE subtitles (
    id INT PRIMARY KEY,
    user_id INT,
    video_name VARCHAR(255),
    video_size BIGINT,
    duration INT,
    status ENUM('pending', 'processing', 'completed', 'failed'),
    original_text TEXT,
    processed_text TEXT,
    created_at TIMESTAMP,
    updated_at TIMESTAMP
);

-- 优化后的表结构
CREATE TABLE videos (
    id INT PRIMARY KEY,
    user_id INT,
    name VARCHAR(255),
    size BIGINT,
    duration INT,
    created_at TIMESTAMP
);

CREATE TABLE subtitle_jobs (
    id INT PRIMARY KEY,
    video_id INT,
    status ENUM('pending', 'processing', 'completed', 'failed'),
    created_at TIMESTAMP,
    updated_at TIMESTAMP
);

CREATE TABLE subtitle_contents (
    id INT PRIMARY KEY,
    job_id INT,
    original_text TEXT,
    processed_text TEXT
);

2.2 索引优化策略

索引是数据库性能的关键。我们分析了慢查询日志，发现有些常用查询没有合适的索引支持。比如用户经常按照状态查询任务，按照创建时间排序查看历史记录，这些操作在没有索引的情况下都是全表扫描。

我们为常用的查询条件添加了复合索引，比如为(status, created_at)创建联合索引，这样在按状态筛选的同时还能利用索引排序。对于文本内容，我们使用了前缀索引来平衡索引大小和查询效率。

-- 添加合适的索引
ALTER TABLE subtitle_jobs ADD INDEX idx_status_created (status, created_at);
ALTER TABLE videos ADD INDEX idx_user_created (user_id, created_at);
ALTER TABLE subtitle_contents ADD INDEX idx_job_id (job_id);

-- 对于文本字段使用前缀索引
ALTER TABLE videos ADD INDEX idx_video_name (video_name(100));

3. 查询性能优化

3.1 避免全表扫描

通过EXPLAIN分析查询语句，我们发现有些查询还在进行全表扫描。特别是那些使用了OR条件或者LIKE模糊查询的语句。我们重写了这些查询，尽量使用索引覆盖查询。

比如原来查询用户某个时间段内的字幕任务：

-- 优化前的写法
SELECT * FROM subtitle_jobs 
WHERE user_id = 123 
AND (status = 'completed' OR status = 'failed')
AND created_at BETWEEN '2024-01-01' AND '2024-01-31';

-- 优化后的写法
SELECT * FROM subtitle_jobs 
WHERE user_id = 123 
AND status IN ('completed', 'failed')
AND created_at >= '2024-01-01' 
AND created_at <= '2024-01-31 23:59:59';

3.2 分页查询优化

列表页的分页查询是个常见性能瓶颈。当使用LIMIT offset, size进行深分页时，offset越大性能越差。我们改用基于游标的分页方式，利用索引的有序性来提升性能。

-- 传统分页（性能差）
SELECT * FROM subtitle_jobs 
WHERE user_id = 123 
ORDER BY created_at DESC 
LIMIT 10000, 20;

-- 优化后的分页（基于游标）
SELECT * FROM subtitle_jobs 
WHERE user_id = 123 
AND created_at < '2024-01-15 10:00:00'
ORDER BY created_at DESC 
LIMIT 20;

4. 大数据量处理方案

4.1 数据分区策略

对于增长特别快的表，比如处理日志表，我们采用了分区表的方式。按照创建时间进行范围分区，每个月一个分区。这样在查询特定时间段的数据时，MySQL只需要扫描相关分区，大大提升了查询效率。

-- 创建分区表
CREATE TABLE process_logs (
    id INT,
    job_id INT,
    log_level ENUM('info', 'warning', 'error'),
    message TEXT,
    created_at TIMESTAMP
) PARTITION BY RANGE (YEAR(created_at)*100 + MONTH(created_at)) (
    PARTITION p202401 VALUES LESS THAN (202402),
    PARTITION p202402 VALUES LESS THAN (202403),
    PARTITION p202403 VALUES LESS THAN (202404)
);

4.2 读写分离架构

当单台数据库服务器无法承受压力时，我们实施了读写分离。使用MySQL主从复制，写操作走主库，读操作走从库。这样分摊了压力，也提高了系统的可用性。

在应用层，我们使用了中间件来自动路由读写请求。对于实时性要求不高的读操作，比如历史记录查询、统计报表等，都路由到从库执行。

5. 实际效果与经验总结

经过这一系列的优化，系统性能有了明显提升。字幕列表查询的响应时间从原来的2-3秒降低到了200-300毫秒，用户操作流畅了很多。数据库服务器的CPU使用率也从经常性的80%以上降到了30%左右。

在这个过程中，我们总结了一些经验：首先是要重视监控，通过慢查询日志和性能监控工具及时发现瓶颈；其次是要理解业务，知道哪些查询是高频操作，有针对性地优化；最后是要有前瞻性，在系统设计阶段就考虑好数据增长带来的问题。

数据库优化是个持续的过程，需要根据业务发展不断调整。我们现在建立了定期的数据库健康检查机制，确保系统能够持续稳定地运行。

---

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。