数据库设计实战为Wan2.1-UMT5平台设计用户与视频管理数据库最近在帮一个做AI视频生成的朋友梳理他们的后台数据架构他们平台叫Wan2.1-UMT5用户量增长挺快原来的数据库有点撑不住了。这让我想起很多刚起步的AI应用都会遇到类似问题前期只想着功能实现数据表随便建等业务跑起来才发现查询慢、扩展难、维护头疼。今天我就以这个视频生成SaaS平台为例子跟你聊聊怎么从零开始设计一套既清晰又扛得住业务增长的数据库。这不是那种纯理论的课程设计而是我结合了实际踩过的坑、业务的需求总结出来的一套可落地方案。我们会重点设计用户、视频任务、资产和积分这几个核心模块并画出ER图聊聊字段和索引怎么选。目标很简单让你看完就能理解思路并且能用到自己的项目里。1. 业务场景与核心需求分析在动手画表、写字段之前我们得先搞清楚这个平台到底是干什么的数据是怎么流转的。Wan2.1-UMT5平台的核心业务是让用户通过文字描述或上传图片快速生成一段短视频。用户需要注册登录消耗积分来发起生成任务平台处理完成后用户可以在个人中心查看、下载和管理这些视频。基于这个业务流程我们可以梳理出几个最关键的数据实体和它们之间的关系用户整个系统的核心一切行为都围绕用户展开。视频生成任务用户每次发起生成请求就会产生一条任务记录它记录了“谁、在什么时候、想生成什么、状态如何”。视频资产任务成功完成后产生的最终成果一个视频文件及其相关信息如存储地址、封面图等。积分流水平台的核心计费或资源消耗单元用户每生成一个视频就会扣除积分充值或活动奖励会增加积分。除了这些核心实体我们还需要考虑一些支撑性的需求性能用户中心查询“我的视频”列表必须快后台统计任务成功率、热门生成风格等也需要高效。扩展性未来可能会增加视频剪辑、模板市场、团队协作等功能表结构不能设计得太死。数据安全与一致性用户积分扣除和任务创建必须是一个完整的事务不能出现扣了积分却没创建任务的情况。理清了这些我们的数据库设计就有了明确的靶心。2. 核心表结构设计与ER图接下来我们进入核心环节定义每张表具体长什么样以及它们如何关联。先上一张总览的ER图帮你建立整体印象。------------- ---------------------- ----------------- | 用户表 | | 视频生成任务表 | | 视频资产表 | | users |----| video_tasks |----| video_assets | ------------- ---------------------- ----------------- | | | | | | | v | | ---------------------- | -------------| 积分流水表 | | | credit_flows | | ---------------------- | | ----------------- | (未来扩展) | | 如标签表、 | | 收藏表、评论表 | -----------------上图展示了四个核心表的关系。简单来说一个用户可以有多个任务一个任务产生一个视频资产同时任务创建会关联一条积分消费流水。下面我们逐一拆解每张表。2.1 用户表用户表是系统的基石设计时要考虑身份验证、基本信息以及未来的扩展。CREATE TABLE users ( id bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 用户唯一ID, username varchar(64) NOT NULL COMMENT 用户名用于登录和显示, email varchar(128) DEFAULT NULL UNIQUE COMMENT 邮箱唯一可用于登录, phone varchar(20) DEFAULT NULL UNIQUE COMMENT 手机号唯一, password_hash varchar(255) NOT NULL COMMENT 加密后的密码, avatar_url varchar(500) DEFAULT NULL COMMENT 头像图片地址, total_credits int(11) NOT NULL DEFAULT 0 COMMENT 当前积分余额, account_status tinyint(4) NOT NULL DEFAULT 1 COMMENT 账户状态1-正常0-禁用, last_login_at timestamp NULL DEFAULT NULL COMMENT 最后登录时间, created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间, updated_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 最后更新时间, PRIMARY KEY (id), UNIQUE KEY uk_username (username), KEY idx_email (email), KEY idx_phone (phone), KEY idx_created_at (created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT平台用户表;设计思路与关键字段解释主键使用独立的、无业务意义的id(BIGINT自增)而不是用手机号或邮箱做主键。这样更灵活即使未来允许用户修改登录邮箱也不会影响外键关联。登录凭证username、email、phone都设计为唯一索引支持多种登录方式。密码存储务必使用password_hash明文存储是重大安全漏洞。积分total_credits字段冗余了用户的当前积分。虽然积分可以通过流水表统计得出但这里冗余存储可以极大提升查询余额的性能是一种典型的“用空间换时间”策略。索引优化uk_username唯一索引保证用户名不重复也加速登录校验。idx_email,idx_phone唯一索引用于登录和查找。idx_created_at普通索引便于后台按注册时间进行用户增长统计。2.2 视频生成任务表这张表记录了每一次视频生成请求的“工单”是业务逻辑最复杂的表之一。CREATE TABLE video_tasks ( task_id varchar(32) NOT NULL COMMENT 任务唯一标识可读性ID如VT202310011200001, user_id bigint(20) UNSIGNED NOT NULL COMMENT 发起任务的用户ID, task_type tinyint(4) NOT NULL COMMENT 任务类型1-文生视频2-图生视频, input_text text COMMENT 文本描述文生视频用, input_image_url varchar(500) DEFAULT NULL COMMENT 输入图片地址图生视频用, style_preset varchar(50) DEFAULT NULL COMMENT 风格预设如卡通、写实、电影感, resolution varchar(20) DEFAULT 720p COMMENT 生成视频分辨率, duration smallint(6) DEFAULT 5 COMMENT 视频时长秒, task_status tinyint(4) NOT NULL DEFAULT 0 COMMENT 任务状态0-排队中1-处理中2-成功3-失败4-已取消, progress tinyint(4) DEFAULT 0 COMMENT 处理进度0-100, error_message text COMMENT 失败时的错误信息, estimated_cost int(11) NOT NULL COMMENT 预估消耗积分, actual_cost int(11) DEFAULT NULL COMMENT 实际扣除积分成功后更新, created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 任务创建时间, updated_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 最后状态更新时间, finished_at timestamp NULL DEFAULT NULL COMMENT 任务完成成功/失败时间, PRIMARY KEY (task_id), KEY idx_user_id_status (user_id, task_status, created_at), KEY idx_status_created (task_status, created_at), KEY idx_created_at (created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT视频生成任务表;设计思路与关键字段解释主键选择没有使用自增ID而是使用了自定义的task_id。这是因为任务ID经常需要暴露给前端用户查看或查询一个具有规则、可读的ID如VT202310011200001比一串无意义的数字更友好。通常可以用“前缀时间戳序列号”来生成。任务详情task_type区分文生视频和图生视频对应的输入字段input_text,input_image_url则分开存储结构更清晰。style_preset,resolution等字段满足了视频生成的参数化需求。状态与进度task_status是核心状态机字段驱动着前端展示和后台逻辑。progress字段用于给用户实时反馈。error_message用于记录失败原因便于排查问题。积分关联estimated_cost和actual_cost记录了积分的预估和实际消耗与积分流水表关联确保计费准确。索引优化idx_user_id_status复合索引。这是最重要的索引之一专门优化用户个人中心查询“我的视频”列表的场景WHERE user_id ? AND task_status 2 ORDER BY created_at DESC。这个索引能完美覆盖这个高频查询。idx_status_created用于后台系统轮询处理排队中的任务WHERE task_status 0 ORDER BY created_at ASC或者监控各状态任务的数量。idx_created_at用于按时间维度进行数据统计和分析。2.3 视频资产表任务成功后的产出物独立成表有利于资产的管理和复用。CREATE TABLE video_assets ( asset_id varchar(32) NOT NULL COMMENT 资产唯一ID可与task_id关联或新生成, task_id varchar(32) NOT NULL UNIQUE COMMENT 关联的任务ID, user_id bigint(20) UNSIGNED NOT NULL COMMENT 所属用户ID, video_url varchar(500) NOT NULL COMMENT 视频文件存储地址如OSS URL, cover_url varchar(500) DEFAULT NULL COMMENT 视频封面图地址, video_meta json DEFAULT NULL COMMENT 视频元数据JSON格式如时长、大小、编码格式、分辨率, title varchar(200) DEFAULT NULL COMMENT 用户自定义标题, description text DEFAULT NULL COMMENT 视频描述, view_count int(11) NOT NULL DEFAULT 0 COMMENT 播放次数, is_public tinyint(1) NOT NULL DEFAULT 0 COMMENT 是否公开0-私有1-公开, created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, updated_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (asset_id), KEY idx_user_id (user_id), KEY idx_task_id (task_id), KEY idx_public_created (is_public, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT视频资产表;设计思路与关键字段解释与任务表关系通过task_id与video_tasks表进行一对一关联UNIQUE约束。user_id在这里是冗余字段但可以避免在查询用户所有视频时进行表连接提升查询效率。资产信息video_url是核心指向对象存储中的文件。cover_url存储封面图。video_meta使用JSON类型存储灵活的元数据未来增加新的视频属性如帧率、水印信息也无需频繁修改表结构。业务字段title,description,view_count,is_public等字段支持视频的基本内容管理功能为未来可能出现的“作品广场”、“热门视频”等社区化功能预留了可能性。索引优化idx_user_id快速查找用户的所有视频资产。idx_task_id通过任务ID快速定位资产虽然主键也是它但作为唯一索引明确其关系。idx_public_created复合索引为未来查询公开视频并按时间排序的场景做准备。2.4 积分流水表记录每一笔积分的来龙去脉是保证财务数据准确性的关键。CREATE TABLE credit_flows ( flow_id bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 流水ID, user_id bigint(20) UNSIGNED NOT NULL COMMENT 用户ID, change_type tinyint(4) NOT NULL COMMENT 变更类型1-任务消费2-充值购买3-活动赠送4-管理员调整, change_amount int(11) NOT NULL COMMENT 变更数量正数为增加负数为消费, current_balance int(11) NOT NULL COMMENT 变更后的实时余额, related_id varchar(64) DEFAULT NULL COMMENT 关联业务ID如task_id、order_id, remark varchar(255) DEFAULT NULL COMMENT 备注, created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (flow_id), KEY idx_user_id_created (user_id, created_at), KEY idx_related_id (related_id(32)) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT积分流水表;设计思路与关键字段解释流水性质这是一张典型的“流水表”或“日志表”只追加不修改。所有积分变动都必须通过插入一条记录来完成这是审计和排查问题的依据。关键字段change_type和change_amount共同定义了这笔流水的性质和数值。current_balance是冗余但极其重要的字段。它记录了该笔流水发生后用户的实时余额。这样要查询用户历史上任意时间点的余额或者对账时就无需从第一笔流水开始累加可以直接定位大大提升了效率和数据可靠性。related_id关联到具体的业务实体比如消费关联task_id充值关联order_id方便追溯。事务一致性创建视频任务时需要在同一个数据库事务中完成1. 插入任务记录2. 插入一条积分消费流水3. 更新用户表的total_credits字段。这确保了业务和积分数据的一致性。索引优化idx_user_id_created复合索引用于快速查询某个用户的积分明细账单通常按时间倒序展示。idx_related_id前缀索引用于通过业务ID快速查找相关流水。3. 关键设计要点与实战建议把表建起来只是第一步要让这套数据库设计真正经得起考验还需要注意下面这些实战要点。3.1 索引策略不是越多越好我们前面为每张表都设计了索引但索引是一把双刃剑能加速查询也会降低写入速度、占用更多空间。在设计时要遵循一些原则为高频查询场景设计比如video_tasks表的idx_user_id_status就是专门为“我的任务列表”这个最高频的页面服务的。利用复合索引复合索引的顺序至关重要。规则是“最左前缀匹配”。我们的idx_user_id_status (user_id, task_status, created_at)索引可以高效支持以下查询WHERE user_id ?WHERE user_id ? AND task_status ?WHERE user_id ? AND task_status ? ORDER BY created_at DESC但无法支持WHERE task_status ?这样的查询因为task_status不是索引的最左列。避免过度索引不要为每个字段都建索引。像users表中的account_status这种区分度很低的字段大部分都是“正常”状态单独建索引效果很差。3.2 字段类型与扩展性思考JSON字段的妙用在video_assets表中我们使用json类型存储video_meta。AI视频生成的技术参数可能会频繁迭代今天需要存储“采样器”明天可能需要“引导系数”。使用JSON字段可以在不修改表结构的情况下灵活地添加这些动态属性。但要注意JSON字段的查询效率通常不如结构化字段且不适合作为查询条件。预留扩展字段可以在核心表中添加1-2个ext_info(JSON或VARCHAR)字段用于存储一些暂时无法确定结构、或变化频繁的附属信息。但核心业务逻辑依赖的数据一定要用明确的字段定义。时间戳统一所有表都使用created_at,updated_at来记录时间并利用MySQL的ON UPDATE CURRENT_TIMESTAMP自动更新updated_at这对于数据追踪和同步非常有用。3.3 应对数据增长与性能随着用户和视频数量的暴涨单表性能必然下降。我们需要提前规划冷热数据分离将6个月前的旧视频任务、流水记录迁移到历史表或归档存储中。主表只保留活跃数据保证核心操作的速度。分库分表当单表数据量达到千万级可以考虑分表。例如video_tasks表可以按user_id哈希取模进行分表将不同用户的数据分布到不同的物理表中。读写分离对于积分查询、视频列表展示等读多写少的场景可以配置从库来分担读压力。引入缓存用户信息、视频的公开信息等不常变化的数据可以放入Redis等缓存中极大减少数据库的访问压力。4. 总结好了以上就是为Wan2.1-UMT5这类AI视频生成平台设计后台数据库的一个完整思路。我们从业务分析入手明确了用户、任务、资产、积分这四大核心模块然后一步步设计了每张表的字段、类型、索引并画出了它们之间的关系。回过头看这套设计的核心思想其实就几点用清晰的ER图理清业务逻辑用合适的字段和类型满足当前需求并预留扩展为最高频的查询场景精心设计索引以及用事务和流水表保证关键数据的一致性。当然实际项目中还会遇到更多细节问题比如如何优雅地生成那个可读的task_id如何设计一个高效的任务状态轮询机制以及当每天生成百万个视频时存储成本如何优化等等。数据库设计没有银弹最好的方案永远是贴合自身业务发展节奏的方案。建议你在实际动手时可以先用这个框架搭起来然后在业务跑起来的过程中持续观察慢查询日志根据真实的数据访问模式来调整和优化。希望这个案例能给你带来一些启发让你在为自己的项目设计数据库时心里更有底。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
数据库设计实战：为Wan2.1-UMT5平台设计用户与视频管理数据库
发布时间：2026/7/10 16:02:20
数据库设计实战为Wan2.1-UMT5平台设计用户与视频管理数据库最近在帮一个做AI视频生成的朋友梳理他们的后台数据架构他们平台叫Wan2.1-UMT5用户量增长挺快原来的数据库有点撑不住了。这让我想起很多刚起步的AI应用都会遇到类似问题前期只想着功能实现数据表随便建等业务跑起来才发现查询慢、扩展难、维护头疼。今天我就以这个视频生成SaaS平台为例子跟你聊聊怎么从零开始设计一套既清晰又扛得住业务增长的数据库。这不是那种纯理论的课程设计而是我结合了实际踩过的坑、业务的需求总结出来的一套可落地方案。我们会重点设计用户、视频任务、资产和积分这几个核心模块并画出ER图聊聊字段和索引怎么选。目标很简单让你看完就能理解思路并且能用到自己的项目里。1. 业务场景与核心需求分析在动手画表、写字段之前我们得先搞清楚这个平台到底是干什么的数据是怎么流转的。Wan2.1-UMT5平台的核心业务是让用户通过文字描述或上传图片快速生成一段短视频。用户需要注册登录消耗积分来发起生成任务平台处理完成后用户可以在个人中心查看、下载和管理这些视频。基于这个业务流程我们可以梳理出几个最关键的数据实体和它们之间的关系用户整个系统的核心一切行为都围绕用户展开。视频生成任务用户每次发起生成请求就会产生一条任务记录它记录了“谁、在什么时候、想生成什么、状态如何”。视频资产任务成功完成后产生的最终成果一个视频文件及其相关信息如存储地址、封面图等。积分流水平台的核心计费或资源消耗单元用户每生成一个视频就会扣除积分充值或活动奖励会增加积分。除了这些核心实体我们还需要考虑一些支撑性的需求性能用户中心查询“我的视频”列表必须快后台统计任务成功率、热门生成风格等也需要高效。扩展性未来可能会增加视频剪辑、模板市场、团队协作等功能表结构不能设计得太死。数据安全与一致性用户积分扣除和任务创建必须是一个完整的事务不能出现扣了积分却没创建任务的情况。理清了这些我们的数据库设计就有了明确的靶心。2. 核心表结构设计与ER图接下来我们进入核心环节定义每张表具体长什么样以及它们如何关联。先上一张总览的ER图帮你建立整体印象。------------- ---------------------- ----------------- | 用户表 | | 视频生成任务表 | | 视频资产表 | | users |----| video_tasks |----| video_assets | ------------- ---------------------- ----------------- | | | | | | | v | | ---------------------- | -------------| 积分流水表 | | | credit_flows | | ---------------------- | | ----------------- | (未来扩展) | | 如标签表、 | | 收藏表、评论表 | -----------------上图展示了四个核心表的关系。简单来说一个用户可以有多个任务一个任务产生一个视频资产同时任务创建会关联一条积分消费流水。下面我们逐一拆解每张表。2.1 用户表用户表是系统的基石设计时要考虑身份验证、基本信息以及未来的扩展。CREATE TABLE users ( id bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 用户唯一ID, username varchar(64) NOT NULL COMMENT 用户名用于登录和显示, email varchar(128) DEFAULT NULL UNIQUE COMMENT 邮箱唯一可用于登录, phone varchar(20) DEFAULT NULL UNIQUE COMMENT 手机号唯一, password_hash varchar(255) NOT NULL COMMENT 加密后的密码, avatar_url varchar(500) DEFAULT NULL COMMENT 头像图片地址, total_credits int(11) NOT NULL DEFAULT 0 COMMENT 当前积分余额, account_status tinyint(4) NOT NULL DEFAULT 1 COMMENT 账户状态1-正常0-禁用, last_login_at timestamp NULL DEFAULT NULL COMMENT 最后登录时间, created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间, updated_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 最后更新时间, PRIMARY KEY (id), UNIQUE KEY uk_username (username), KEY idx_email (email), KEY idx_phone (phone), KEY idx_created_at (created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT平台用户表;设计思路与关键字段解释主键使用独立的、无业务意义的id(BIGINT自增)而不是用手机号或邮箱做主键。这样更灵活即使未来允许用户修改登录邮箱也不会影响外键关联。登录凭证username、email、phone都设计为唯一索引支持多种登录方式。密码存储务必使用password_hash明文存储是重大安全漏洞。积分total_credits字段冗余了用户的当前积分。虽然积分可以通过流水表统计得出但这里冗余存储可以极大提升查询余额的性能是一种典型的“用空间换时间”策略。索引优化uk_username唯一索引保证用户名不重复也加速登录校验。idx_email,idx_phone唯一索引用于登录和查找。idx_created_at普通索引便于后台按注册时间进行用户增长统计。2.2 视频生成任务表这张表记录了每一次视频生成请求的“工单”是业务逻辑最复杂的表之一。CREATE TABLE video_tasks ( task_id varchar(32) NOT NULL COMMENT 任务唯一标识可读性ID如VT202310011200001, user_id bigint(20) UNSIGNED NOT NULL COMMENT 发起任务的用户ID, task_type tinyint(4) NOT NULL COMMENT 任务类型1-文生视频2-图生视频, input_text text COMMENT 文本描述文生视频用, input_image_url varchar(500) DEFAULT NULL COMMENT 输入图片地址图生视频用, style_preset varchar(50) DEFAULT NULL COMMENT 风格预设如卡通、写实、电影感, resolution varchar(20) DEFAULT 720p COMMENT 生成视频分辨率, duration smallint(6) DEFAULT 5 COMMENT 视频时长秒, task_status tinyint(4) NOT NULL DEFAULT 0 COMMENT 任务状态0-排队中1-处理中2-成功3-失败4-已取消, progress tinyint(4) DEFAULT 0 COMMENT 处理进度0-100, error_message text COMMENT 失败时的错误信息, estimated_cost int(11) NOT NULL COMMENT 预估消耗积分, actual_cost int(11) DEFAULT NULL COMMENT 实际扣除积分成功后更新, created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 任务创建时间, updated_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 最后状态更新时间, finished_at timestamp NULL DEFAULT NULL COMMENT 任务完成成功/失败时间, PRIMARY KEY (task_id), KEY idx_user_id_status (user_id, task_status, created_at), KEY idx_status_created (task_status, created_at), KEY idx_created_at (created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT视频生成任务表;设计思路与关键字段解释主键选择没有使用自增ID而是使用了自定义的task_id。这是因为任务ID经常需要暴露给前端用户查看或查询一个具有规则、可读的ID如VT202310011200001比一串无意义的数字更友好。通常可以用“前缀时间戳序列号”来生成。任务详情task_type区分文生视频和图生视频对应的输入字段input_text,input_image_url则分开存储结构更清晰。style_preset,resolution等字段满足了视频生成的参数化需求。状态与进度task_status是核心状态机字段驱动着前端展示和后台逻辑。progress字段用于给用户实时反馈。error_message用于记录失败原因便于排查问题。积分关联estimated_cost和actual_cost记录了积分的预估和实际消耗与积分流水表关联确保计费准确。索引优化idx_user_id_status复合索引。这是最重要的索引之一专门优化用户个人中心查询“我的视频”列表的场景WHERE user_id ? AND task_status 2 ORDER BY created_at DESC。这个索引能完美覆盖这个高频查询。idx_status_created用于后台系统轮询处理排队中的任务WHERE task_status 0 ORDER BY created_at ASC或者监控各状态任务的数量。idx_created_at用于按时间维度进行数据统计和分析。2.3 视频资产表任务成功后的产出物独立成表有利于资产的管理和复用。CREATE TABLE video_assets ( asset_id varchar(32) NOT NULL COMMENT 资产唯一ID可与task_id关联或新生成, task_id varchar(32) NOT NULL UNIQUE COMMENT 关联的任务ID, user_id bigint(20) UNSIGNED NOT NULL COMMENT 所属用户ID, video_url varchar(500) NOT NULL COMMENT 视频文件存储地址如OSS URL, cover_url varchar(500) DEFAULT NULL COMMENT 视频封面图地址, video_meta json DEFAULT NULL COMMENT 视频元数据JSON格式如时长、大小、编码格式、分辨率, title varchar(200) DEFAULT NULL COMMENT 用户自定义标题, description text DEFAULT NULL COMMENT 视频描述, view_count int(11) NOT NULL DEFAULT 0 COMMENT 播放次数, is_public tinyint(1) NOT NULL DEFAULT 0 COMMENT 是否公开0-私有1-公开, created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, updated_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (asset_id), KEY idx_user_id (user_id), KEY idx_task_id (task_id), KEY idx_public_created (is_public, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT视频资产表;设计思路与关键字段解释与任务表关系通过task_id与video_tasks表进行一对一关联UNIQUE约束。user_id在这里是冗余字段但可以避免在查询用户所有视频时进行表连接提升查询效率。资产信息video_url是核心指向对象存储中的文件。cover_url存储封面图。video_meta使用JSON类型存储灵活的元数据未来增加新的视频属性如帧率、水印信息也无需频繁修改表结构。业务字段title,description,view_count,is_public等字段支持视频的基本内容管理功能为未来可能出现的“作品广场”、“热门视频”等社区化功能预留了可能性。索引优化idx_user_id快速查找用户的所有视频资产。idx_task_id通过任务ID快速定位资产虽然主键也是它但作为唯一索引明确其关系。idx_public_created复合索引为未来查询公开视频并按时间排序的场景做准备。2.4 积分流水表记录每一笔积分的来龙去脉是保证财务数据准确性的关键。CREATE TABLE credit_flows ( flow_id bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 流水ID, user_id bigint(20) UNSIGNED NOT NULL COMMENT 用户ID, change_type tinyint(4) NOT NULL COMMENT 变更类型1-任务消费2-充值购买3-活动赠送4-管理员调整, change_amount int(11) NOT NULL COMMENT 变更数量正数为增加负数为消费, current_balance int(11) NOT NULL COMMENT 变更后的实时余额, related_id varchar(64) DEFAULT NULL COMMENT 关联业务ID如task_id、order_id, remark varchar(255) DEFAULT NULL COMMENT 备注, created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (flow_id), KEY idx_user_id_created (user_id, created_at), KEY idx_related_id (related_id(32)) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT积分流水表;设计思路与关键字段解释流水性质这是一张典型的“流水表”或“日志表”只追加不修改。所有积分变动都必须通过插入一条记录来完成这是审计和排查问题的依据。关键字段change_type和change_amount共同定义了这笔流水的性质和数值。current_balance是冗余但极其重要的字段。它记录了该笔流水发生后用户的实时余额。这样要查询用户历史上任意时间点的余额或者对账时就无需从第一笔流水开始累加可以直接定位大大提升了效率和数据可靠性。related_id关联到具体的业务实体比如消费关联task_id充值关联order_id方便追溯。事务一致性创建视频任务时需要在同一个数据库事务中完成1. 插入任务记录2. 插入一条积分消费流水3. 更新用户表的total_credits字段。这确保了业务和积分数据的一致性。索引优化idx_user_id_created复合索引用于快速查询某个用户的积分明细账单通常按时间倒序展示。idx_related_id前缀索引用于通过业务ID快速查找相关流水。3. 关键设计要点与实战建议把表建起来只是第一步要让这套数据库设计真正经得起考验还需要注意下面这些实战要点。3.1 索引策略不是越多越好我们前面为每张表都设计了索引但索引是一把双刃剑能加速查询也会降低写入速度、占用更多空间。在设计时要遵循一些原则为高频查询场景设计比如video_tasks表的idx_user_id_status就是专门为“我的任务列表”这个最高频的页面服务的。利用复合索引复合索引的顺序至关重要。规则是“最左前缀匹配”。我们的idx_user_id_status (user_id, task_status, created_at)索引可以高效支持以下查询WHERE user_id ?WHERE user_id ? AND task_status ?WHERE user_id ? AND task_status ? ORDER BY created_at DESC但无法支持WHERE task_status ?这样的查询因为task_status不是索引的最左列。避免过度索引不要为每个字段都建索引。像users表中的account_status这种区分度很低的字段大部分都是“正常”状态单独建索引效果很差。3.2 字段类型与扩展性思考JSON字段的妙用在video_assets表中我们使用json类型存储video_meta。AI视频生成的技术参数可能会频繁迭代今天需要存储“采样器”明天可能需要“引导系数”。使用JSON字段可以在不修改表结构的情况下灵活地添加这些动态属性。但要注意JSON字段的查询效率通常不如结构化字段且不适合作为查询条件。预留扩展字段可以在核心表中添加1-2个ext_info(JSON或VARCHAR)字段用于存储一些暂时无法确定结构、或变化频繁的附属信息。但核心业务逻辑依赖的数据一定要用明确的字段定义。时间戳统一所有表都使用created_at,updated_at来记录时间并利用MySQL的ON UPDATE CURRENT_TIMESTAMP自动更新updated_at这对于数据追踪和同步非常有用。3.3 应对数据增长与性能随着用户和视频数量的暴涨单表性能必然下降。我们需要提前规划冷热数据分离将6个月前的旧视频任务、流水记录迁移到历史表或归档存储中。主表只保留活跃数据保证核心操作的速度。分库分表当单表数据量达到千万级可以考虑分表。例如video_tasks表可以按user_id哈希取模进行分表将不同用户的数据分布到不同的物理表中。读写分离对于积分查询、视频列表展示等读多写少的场景可以配置从库来分担读压力。引入缓存用户信息、视频的公开信息等不常变化的数据可以放入Redis等缓存中极大减少数据库的访问压力。4. 总结好了以上就是为Wan2.1-UMT5这类AI视频生成平台设计后台数据库的一个完整思路。我们从业务分析入手明确了用户、任务、资产、积分这四大核心模块然后一步步设计了每张表的字段、类型、索引并画出了它们之间的关系。回过头看这套设计的核心思想其实就几点用清晰的ER图理清业务逻辑用合适的字段和类型满足当前需求并预留扩展为最高频的查询场景精心设计索引以及用事务和流水表保证关键数据的一致性。当然实际项目中还会遇到更多细节问题比如如何优雅地生成那个可读的task_id如何设计一个高效的任务状态轮询机制以及当每天生成百万个视频时存储成本如何优化等等。数据库设计没有银弹最好的方案永远是贴合自身业务发展节奏的方案。建议你在实际动手时可以先用这个框架搭起来然后在业务跑起来的过程中持续观察慢查询日志根据真实的数据访问模式来调整和优化。希望这个案例能给你带来一些启发让你在为自己的项目设计数据库时心里更有底。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
