音乐流媒体平台需分层建模：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 同步），避免每次查播放页都 JOINfavorites和play_history - 所有带「排序+分页」的列表接口（如排行榜、搜索结果），强制要求前端传
cursor（如last_played_at=1712345678），禁用OFFSET—— 超过 10 万行后LIMIT 100000, 20会全表扫描
播放日志这种海量写入数据怎么存不拖垮主库
play_history 表每秒写入轻松破万，放主库等于给 MySQL 心脏装砂纸。别信“加个 SSD 就能顶住”，真实瓶颈是事务日志刷盘和二级索引维护开销。
正确做法是写分离 + 分区降级：
- 用
CREATE table play_history_202404 (..., 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 教做人。