17370845950

音乐流媒体平台需分层建模：song表仅存不可变属性，可变元数据、多对多关系、高频查询结果、播放日志、地域版权状态均拆分独立表，结合预计算、分区、写分离与异步更新保障性能。

音乐流媒体平台的核心数据模型怎么建

直接说结论：不能用单表硬扛「用户—歌单—歌曲—播放记录—版权信息」全链路，必须按读写特征分层建模。重点不是字段多不多，而是「谁在什么时候以什么方式查什么」。

典型错误是把 song 表设计成大宽表，塞进歌手、专辑、时长、码率、歌词、封面URL、版权方ID……结果每次更新封面或版权信息都要锁整行，播放日志写入延迟飙升。

• song 表只保留不可变基础属性：id、title、duration_ms、is_explicit、created_at
• 可变元数据（如封面、歌词、版权状态）拆到 song_metadata 表，用 song_id + version 作联合主键，支持历史追溯
• 歌手、专辑、流派等用多对多关联表（song_artist、album_song），不冗余存储名称——名称变更只需改 artist 表单条记录

高频查询场景下如何避免 JOIN 爆炸

用户打开「我的推荐」页，后端要查：最近听过的 5 个歌手 → 每个歌手的 3 首新歌 → 每首歌是否已收藏。如果真按关系模型实时 JOIN，一次请求扫十几张表，MySQL 连接池很快被打满。

解法不是加索引，而是预计算 + 冗余：

• 为「用户-歌手-新鲜度」建物化视图表 user_artist_freshness，每天凌晨用 INSERT ... SELECT 批量更新，字段含 user_id、artist_id、last_played_at、new_release_count_7d
• user_song_status 表缓存「是否收藏」「是否下载」「最后播放时间」，用应用层双写（或 Canal 监听 binlog 同步），避免每次查播放页都 JOIN favorites 和 play_history
• 所有带「排序+分页」的列表接口（如排行榜、搜索结果），强制要求前端传 cursor（如 last_played_at=1712345678），禁用 OFFSET —— 超过 10 万行后 LIMIT 100000, 20 会全表扫描

播放日志这种海量写入数据怎么存不拖垮主库

play_history 表每秒写入轻松破万，放主库等于给 MySQL 心脏装砂纸。别信“加个 SSD 就能顶住”，真实瓶颈是事务日志刷盘和二级索引维护开销。

正确做法是写分离 + 分区降级：

• 用 CREATE TABLE play_history_202504 (..., KEY idx_user_time (user_id, played_at)) ENGINE=ROCKSDB —— MySQL 8.0+ 支持 RocksDB 引擎，对高并发小写入更友好，但注意它不支持全文索引和部分函数索引
• 按天分区：PARTITION BY RANGE (TO_DAYS(played_at))，旧分区（如 90 天前）直接 DROP PARTITION，比 DELETE 快十倍且不锁表
• 实时分析需求（如“当前在线听周杰伦的用户数”）不查这张表，走 Kafka + Flink 实时聚合，MySQL 只承载「用户回溯自己播放记录」这类低频精准查询

版权与地域限制带来的数据一致性难题

一首歌在德国可播，在法国因版权到期下架，但用户缓存了封面和标题——这时候不能简单删 song 记录，否则播放历史里显示“未知歌曲”。也不能只改状态字段，因为不同地区状态可能冲突。

关键设计点在于把「可用性」从主数据中剥离：

• 新建 song_availability 表，字段为 song_id、region_code（ISO 3166-1 alpha-2）、status（'available'/'unavailable'/'pending'）、effective_from
• 查询某用户能听什么歌时，JOIN 此表并带上 WHERE region_code = ? AND status = 'available'，而不是在 song 表里加 is_available_in_fr 这种字段
• 版权变更事件通过消息队列触发异步更新，避免事务内调用外部 API 导致超时；同时对 song_availability 加唯一索引 (song_id, region_code)，防止重复写入覆盖

真正难的不是建多少张表，而是每次加字段前问一句：这个值变化频率高不高？多个业务方是否同时读写？有没有地域/时间维度的正交约束？没想清楚就加索引，迟早被 SHOW PROCESSLIST 里那堆 Waiting for table metadata lock 教做人。