音乐流媒体平台的核心数据模型怎么建
直接说结论：不能用单表硬扛「用户—歌单—歌曲—播放记录—版权信息」全链路，必须按读写特征分层建模。重点不是字段多不多，而是「谁在什么时候以什么方式查什么」。
典型错误是把
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_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教做人。
