设计目标与总体架构
性能目标与访问模式
在面向视频播放的场景中，目标是实现高并发、低延迟的读取路径，并确保吞吐稳定，同时结合CDN与对象存储提升全球访问的稳定性。本文聚焦于打造高效的 MySQL 表结构来支撑视频播放功能，强调从存储到索引的全面优化，覆盖存储层到查询层的设计要点。为达到这些目标，需要深入分析访问模式、数据依赖关系以及分层缓存策略。
在实际落地中，通常将视频文件放置在对象存储，而将元数据、索引与分段信息保存在 MySQL 中，以实现快速定位分段、快速校验完整性，并通过分段访问提升播放的连续性与可预测性。
存储与计算分离的总体架构
为实现可扩展性，应设计存储与计算分离的架构：视频文件落在对象存储/分布式存储，元数据与索引落在MySQL/InnoDB之上，同时通过URL 化的存储引用实现播放路径的解码。该架构使得元数据更新与视频文件变更的隔离成为可能，降低了系统耦合度。
此外，应该结合CDN 缓存策略与预取机制，将热点分段和元数据结果缓存到就近节点，提升客户端的启动时间与缓冲稳定性，从而实现更平滑的播放体验。在设计初期，就需要将数据一致性策略、权限控制与错误回退策略纳入体系。
存储层设计：视频数据与元数据的分离
视频文件的外部存储设计
视频文件与其分段数据通常应存放在对象存储（如 S3、OSS、阿里云COS 等），数据库只记录引用字段（如 storage_uri），以实现分离式管理和更高效的扩展性。通过预签名链接/临时访问凭证，可以安全地将视频流直接引导至客户端。
在元数据层，需要设计一个稳定的引用模型，确保存储 URI 的一致性，并通过 版本化/签名 保障数据不可变性与回滚能力。这样，对象存储的容量扩展和数据保护将不再强耦合到关系型数据库的容量上。
以下给出一个示例字段，帮助明确两个层之间的边界关系：storage_uri 代表对象存储中的对象位置，storage_etag 作为版本标识，帮助客户端和服务端校验一致性。
CREATE TABLE videos (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
title VARCHAR(255) NOT NULL,
duration_seconds INT UNSIGNED NOT NULL,
mime_type VARCHAR(32) NOT NULL,
size_bytes BIGINT UNSIGNED NOT NULL,
storage_uri VARCHAR(1024) NOT NULL,
storage_etag VARCHAR(64),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
bitrate INT UNSIGNED,
width INT,
height INT,
Codec VARCHAR(32),
status ENUM('available','processing','failed') NOT NULL DEFAULT 'processing',
PRIMARY KEY (id),
UNIQUE KEY uniq_title_duration (title, duration_seconds)
) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;
元数据表与文件表的关系
元数据表应作为核心查询对象，与具体视频文件的分段信息、字幕、封面等多种资源表建立清晰的引用关系。通过外键约束与事务边界，确保数据的一致性与完整性，避免分布式写入时产生脏数据。
在实际应用中，元数据与分段信息通常分布在多张表中，以便实现垂直解耦、提高写入吞吐量和查询的缓存命中率。通过合理的事务粒度，可以在更新视频元数据、添加新分段或字幕时保持原子性。
核心表的关系与数据模型概览
设计时应明确以下关系：videos 表记录视频的基本信息及存储位置，video_segments 表存放分段元数据，video_subtitles 表管理语言与链接，video_thumbnails 表存放封面图片路径。通过这些表的组合，可以快速组装出一个完整的视频播放路径。
下面给出一个常用的分段和字幕表结构示例，帮助理解关系与查询入口。
CREATE TABLE video_segments (
video_id BIGINT UNSIGNED NOT NULL,
segment_number INT UNSIGNED NOT NULL,
start_byte BIGINT UNSIGNED NOT NULL,
end_byte BIGINT UNSIGNED NOT NULL,
duration_seconds INT UNSIGNED,
PRIMARY KEY (video_id, segment_number),
KEY idx_video_start (video_id, start_byte)
) ENGINE=InnoDB;
CREATE TABLE video_subtitles (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
video_id BIGINT UNSIGNED NOT NULL,
language_code CHAR(2) NOT NULL,
url VARCHAR(512) NOT NULL,
kind ENUM('subtitle','caption') NOT NULL DEFAULT 'subtitle',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (id),
KEY idx_video_lang (video_id, language_code)
) ENGINE=InnoDB;
表结构设计：核心表与字段
核心表：videos
核心表 videos 作为所有视频资源的枢纽，字段设计应覆盖基本信息、格式参数、存储定位与状态，以支撑快速检索与播放路由。合理的字段设计能够提升覆盖索引的利用率，从而降低查询成本。
在实际落地中，建议将 id、created_at、status 等作为查询的关键点，通过主键与唯一约束实现快速定位与去重复。
CREATE TABLE videos (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
title VARCHAR(255) NOT NULL,
duration_seconds INT UNSIGNED NOT NULL,
mime_type VARCHAR(32) NOT NULL,
size_bytes BIGINT UNSIGNED NOT NULL,
storage_uri VARCHAR(1024) NOT NULL,
storage_etag VARCHAR(64),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
bitrate INT UNSIGNED,
width INT,
height INT,
codec VARCHAR(32),
status ENUM('available','processing','failed') NOT NULL DEFAULT 'processing',
PRIMARY KEY (id),
UNIQUE KEY uniq_title_duration (title, duration_seconds)
) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;
分段数据：video_segments
对于视频播放的核心需求，分段数据是实现平滑排序与快速定位的关键。按 segment_number 进行排序，可以实现按段拉取并组合成连续的播放流。
设计分段表时要兼顾写入吞吐量与读取效率，并确保对 video_id 的查询具有良好的聚集性。
字幕与缩略图
字幕与缩略图等辅助资源应以独立表进行管理，便于跨语言检索与缓存命中。通过外键与索引，可以在不影响视频核心元数据的情况下，快速获取所需的字幕/封面内容。
CREATE TABLE video_thumbnails (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
video_id BIGINT UNSIGNED NOT NULL,
timestamp_seconds INT UNSIGNED NOT NULL,
url VARCHAR(512) NOT NULL,
PRIMARY KEY (id),
KEY idx_video_time (video_id, timestamp_seconds)
) ENGINE=InnoDB;
索引策略与查询优化
覆盖索引与主键设计
在视频播放查询中，常见的模式是按 video_id 拉取分段信息、按 video_id + segment_number 读取某一段的元数据、以及按语言检索字幕。通过 主键 与 覆盖索引，可以让查询直接命中索引覆盖的字段，避免回表和额外扫描，从而获得更低的延迟。
此外，合理安排索引的顺序与列类型，能够提升 InnoDB 的聚簇存储效率，减少 I/O 开销，提升读取路径的稳定性。在设计阶段，应优先考虑最常用的查询模式来确定复合索引。
查询示例与解释计划
下面给出一个常见的查询示例：按视频维度获取分段信息，按 segment_number 排序，用于组装播放流。
SELECT vs.segment_number, vs.start_byte, vs.end_byte, vs.duration_seconds
FROM video_segments AS vs
WHERE vs.video_id = :video_id
ORDER BY vs.segment_number ASC
LIMIT 100;
通过 EXPLAIN 可以查看执行计划，确保查询命中覆盖索引、避免额外的回表操作，从而达到低延迟的分段加载效果。
EXPLAIN
SELECT vs.segment_number, vs.start_byte, vs.end_byte, vs.duration_seconds
FROM video_segments AS vs
WHERE vs.video_id = 12345
ORDER BY vs.segment_number ASC
LIMIT 100;
分区与分片：大规模库的可扩展性
基于日期的分区
对于海量视频的场景，分区可以显著提升查询性能与维护效率，尤其是对最近新增内容的热点查询。将 videos、video_subtitles、以及 video_segments 等表按 创建日期 或 视频上传日期进行分区，可以让最近数据的查询走分区路径，减少扫描范围。
分区策略应兼顾写入分布与查询模式，避免产生过多分区导致的管理成本，同时要对跨分区的统计与汇总任务设计专门的处理流程。
CREATE TABLE videos (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
title VARCHAR(255) NOT NULL,
created_at DATE NOT NULL,
duration_seconds INT UNSIGNED NOT NULL,
-- 其他字段省略 --
PRIMARY KEY (id)
) ENGINE=InnoDB
PARTITION BY RANGE (TO_DAYS(created_at)) (
PARTITION p202301 VALUES LESS THAN (TO_DAYS('2023-02-01')),
PARTITION p202302 VALUES LESS THAN (TO_DAYS('2023-03-01')),
PARTITION pMAX VALUES LESS THAN MAXVALUE
);
跨分区查询与维护
对跨分区查询，应借助分区剪裁来缩小扫描范围；对老旧分区应定期执行 归档与合并，以控制表的分区数量与运行成本。对于维护，建议采用 在线 DDL 与 无锁添加索引 等特性，确保在高并发场景下不影响正在进行的播放请求。
分区设计还应与备份策略结合，确保分区级别的备份与还原能力，以实现对单个时期的新数据快速恢复。
与对象存储和 CDN 的协同
存储 URI 与缓存策略
存储 URI 的设计应与对象存储结构保持一致，并结合缓存策略提升命中率。通过 预签名 URL、TTL 控制等技术，可以在保持安全性的前提下实现高效的媒体下载。此处的 缓存层次包括本地应用缓存、数据库级缓存、以及 CDN 层缓存三级结构。
在设计中应明确：存储 URI 的稳定性、缓存失效策略、以及过期清理机制，以避免视频播放过程中断或缓存穿透。
分段访问与缓存前置
为了实现更快的启动和连续播放，应将 首屏分段和热段分段优先缓存到就近节点，同时对分段元数据进行预取与预加载，减少客户端请求时延。通过结合 CDN 能力，可以将高热度分段快速分发到全球节点。
数据一致性、备份与灾备
事务边界与原子性
在视频上传、元数据更新和分段写入的场景中，应将核心写入操作包裹在单一事务中，以确保数据的一致性与可回滚性。对于分布式写入，应设计幂等性处理、冲突检测与错误重试策略，以降低重复写入导致的错误。
同时，应对热数据使用内存缓存与异步写入，减少对持久化层的直接压力，提升播放请求的响应时间。
备份与还原策略
备份策略应覆盖核心元数据表、分段信息表、字幕表等，并结合增量备份与全量备份，以实现快速恢复。灾备设计应包含跨区域复制、快速切换以及定期的演练，确保在单点故障时的可用性与数据完整性。
通过周期性运行的备份校验、恢复演练和一致性检查，可以确保在灾难发生时最小化业务中断，并在最短时间内把视频播放能力恢复到正常水平。
