为什么歌单管理适合用SQLite
音乐播放器的歌单功能本质上是一个小型关系型数据管理问题：歌曲和歌单之间是多对多关系，一个歌单包含多首歌，一首歌也可以被收藏进多个歌单。这类数据规模通常在几百到几万条之间，既要支持快速查询，又要保证增删改的可靠性，SQLite的嵌入式特性正好匹配这种场景。它不需要独立的服务器进程，数据库就是一个文件，随应用分发，部署成本几乎为零。
相比直接把歌单数据序列化成JSON存本地文件，SQLite的优势在数据量增长后非常明显。JSON方案每次修改都要整读整写，歌曲列表一多就卡顿，而且无法高效地按歌手、专辑、添加时间等维度筛选排序。SQLite支持索引和SQL查询，用一条语句就能完成按播放次数倒序排列的前五十首歌这种操作，同时事务机制保证了数据不会因为中途崩溃而损坏。对于Android应用来说，SQLite更是系统内置的数据库，天然适合移动端音乐类应用。
当然，SQLite也有适用边界。如果你的产品需要多设备实时同步、多用户并发编辑同一个歌单，那么本地SQLite只能作为缓存层，还需要配合云端数据库。但在单机场景下，比如离线播放器、本地音乐管理工具，SQLite几乎是唯一合理的选择。
表结构设计：如何表达多对多关系
歌单管理的核心是三张表：歌曲表、歌单表、歌单歌曲关联表。歌曲表存储歌曲的基础信息，如标题、歌手、专辑、时长、文件路径；歌单表存储歌单名称、创建时间、封面；关联表则记录哪首歌属于哪个歌单，以及这首歌在歌单中的排序位置。关联表通过外键分别指向另外两张表，用联合唯一约束防止同一首歌在同一歌单中重复添加。
CREATE TABLE songs (
id INTEGER PRIMARY KEY AUTOINCREMENT,
title TEXT NOT NULL,
artist TEXT DEFAULT '未知歌手',
album TEXT,
duration INTEGER DEFAULT 0,
file_path TEXT NOT NULL UNIQUE
);
CREATE TABLE playlists (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL UNIQUE,
created_at TEXT DEFAULT (datetime('now', 'localtime'))
);
CREATE TABLE playlist_songs (
playlist_id INTEGER NOT NULL,
song_id INTEGER NOT NULL,
sort_order INTEGER NOT NULL DEFAULT 0,
added_at TEXT DEFAULT (datetime('now', 'localtime')),
PRIMARY KEY (playlist_id, song_id),
FOREIGN KEY (playlist_id) REFERENCES playlists(id) ON DELETE CASCADE,
FOREIGN KEY (song_id) REFERENCES songs(id) ON DELETE CASCADE
);
-- 排序和查询常用的字段建立索引
CREATE INDEX idx_ps_song ON playlist_songs(song_id);
CREATE INDEX idx_songs_artist ON songs(artist);设计时有几个细节值得注意。第一，关联表的联合主键playlist_id加song_id既保证了不重复，又自动创建了索引，按歌单查歌非常快。第二，外键要开启级联删除，删除歌单时自动清理关联记录，避免产生孤儿数据。第三，sort_order字段专门用来记录歌曲在歌单中的顺序，用户拖动调整顺序时只需更新这一列，不用重排整张表。
还有一个容易被忽略的问题：SQLite默认不启用外键约束，建表语句里写了FOREIGN KEY也不会生效。每次打开数据库连接后需要执行PRAGMA foreign_keys=ON，否则删除歌曲后关联表里会留下脏数据，查询歌单时就会出现不存在的歌曲条目。
PRAGMA foreign_keys = ON;
核心功能实现：增删改查与歌单排序
歌单的基础操作包括创建歌单、添加歌曲、移除歌曲、查询歌单内容。查询歌单内容是使用频率最高的操作，需要把关联表和歌曲表联查，返回完整歌曲信息并按sort_order排序。下面是Python环境下的典型实现，Android平台的Java或Kotlin代码逻辑完全一致，只是API不同。
import sqlite3
db = sqlite3.connect("music.db")
db.execute("PRAGMA foreign_keys = ON")
def create_playlist(name):
with db:
db.execute("INSERT INTO playlists(name) VALUES (?)", (name,))
def add_song_to_playlist(playlist_id, song_id):
# sort_order取当前最大值加1，新歌追加到歌单末尾
with db:
row = db.execute(
"SELECT COALESCE(MAX(sort_order), 0) + 1 FROM playlist_songs WHERE playlist_id = ?",
(playlist_id,)
).fetchone()
db.execute(
"INSERT INTO playlist_songs(playlist_id, song_id, sort_order) VALUES (?, ?, ?)",
(playlist_id, song_id, row[0])
)
def get_playlist_songs(playlist_id):
return db.execute("""
SELECT s.id, s.title, s.artist, s.album, s.duration, ps.sort_order
FROM playlist_songs ps
JOIN songs s ON s.id = ps.song_id
WHERE ps.playlist_id = ?
ORDER BY ps.sort_order ASC
""", (playlist_id,)).fetchall()
def remove_song(playlist_id, song_id):
with db:
db.execute(
"DELETE FROM playlist_songs WHERE playlist_id = ? AND song_id = ?",
(playlist_id, song_id)
)拖拽排序是歌单功能的体验重点。用户把第五首歌拖到第一位时，如果逐条更新所有受影响歌曲的sort_order，涉及大量写操作。更优的做法是把歌单内所有歌曲的排序整体重写一遍：先在内存中调整好顺序数组，然后放在一个事务里批量UPDATE。因为SQLite的写操作会锁定整个数据库文件，把多条UPDATE包在同一个事务里，只在提交时写一次盘，速度比逐条自动提交快几个数量级。
def reorder_songs(playlist_id, new_song_id_list):
# new_song_id_list是拖拽后按新顺序排列的歌曲id数组
with db:
for index, song_id in enumerate(new_song_id_list):
db.execute(
"UPDATE playlist_songs SET sort_order = ? WHERE playlist_id = ? AND song_id = ?",
(index + 1, playlist_id, song_id)
)搜索功能也很常用，比如在歌单内按歌名或歌手模糊查找。LIKE配合通配符即可实现，但要注意中文搜索性能，如果歌单歌曲量大，可以考虑额外维护一个去拼音或首字母字段，建立索引后按拼音首字母检索歌单分组，这也是主流音乐App的实现方式。
SELECT s.* FROM playlist_songs ps JOIN songs s ON s.id = ps.song_id WHERE ps.playlist_id = 1 AND (s.title LIKE '%晴天%' OR s.artist LIKE '%杰伦%') ORDER BY ps.sort_order;
性能优化与常见坑点排查
批量导入是第一个性能考验场景。用户首次扫描本地音乐时可能一次性插入几千首歌曲，如果每条INSERT都独立提交，SQLite每秒大概只能完成几十到几百次事务提交，导入过程会明显卡顿。解决办法是把整个导入过程包进一个显式事务，几千条记录一秒内即可完成。此外，配合参数化语句还能复用SQL解析结果，进一步提速。
def batch_import_songs(song_list):
# song_list是包含(title, artist, album, duration, file_path)的元组列表
with db: # with块就是一个事务，异常时自动回滚
db.executemany(
"INSERT OR IGNORE INTO songs(title, artist, album, duration, file_path) "
"VALUES (?, ?, ?, ?, ?)",
song_list
)这里用了INSERT OR IGNORE而不是普通INSERT，配合file_path上的UNIQUE约束，重复扫描时已存在的歌曲会被自动跳过，天然实现了去重。如果希望重复歌曲更新信息而不是跳过，可以改用INSERT OR REPLACE，但要注意REPLACE的语义是先删后插，会改变id值，如果关联表引用了旧id，外键级联删除会把关联关系一起删掉，这是很多人踩过的坑。
第二个常见坑是WAL模式。音乐播放器经常出现边听歌边写数据库的情况，比如实时更新播放次数、记录播放进度。SQLite默认的回滚日志模式在写入时会阻塞读取，可能造成界面查询卡顿。开启WAL模式后，读写可以并发进行，体验明显更流畅。开启方式很简单，只需执行一次PRAGMA journal_mode=WAL，该设置会持久化在数据库文件中。
PRAGMA journal_mode = WAL; PRAGMA synchronous = NORMAL;
第三个坑是数据库版本升级。应用迭代后表结构可能变化，比如给歌曲表新增流派字段。如果没有版本管理机制，老用户升级后程序会因为字段不存在而崩溃。标准做法是用PRAGMA user_version记录数据库版本号，启动时检查版本并依次执行迁移脚本，每一步迁移都用事务包裹，保证升级失败可以回滚。
def migrate(db):
version = db.execute("PRAGMA user_version").fetchone()[0]
if version < 1:
with db:
db.execute("ALTER TABLE songs ADD COLUMN genre TEXT DEFAULT ''")
db.execute("PRAGMA user_version = 1")
# 后续版本依次往下判断，保证老版本逐级升级把这套结构稍作扩展，就能支持收藏夹、最近播放、播放历史等衍生功能，它们本质都是关联表的变体。掌握三表结构和事务、索引、WAL这几个关键点后，歌单管理模块就具备了生产级的稳定性和性能，后续要做的只是在此基础上不断打磨交互体验。