Fun-ASR数据库太大？history.db清理方法来了
你是不是也遇到过这样的情况：用Fun-ASR WebUI处理了几十段会议录音、上百条客服语音后，突然发现系统变慢了，启动时间变长，甚至浏览器打开“识别历史”页面都要卡顿几秒？点开webui/data/目录一看——那个不起眼的history.db文件，已经悄悄膨胀到800MB、1.2GB，甚至更大。
别慌。这不是模型出错，也不是硬盘坏了，而是Fun-ASR忠实记录了每一次识别的完整元数据：音频路径、原始文本、ITN规整结果、热词列表、语言设置、时间戳……日积月累，SQLite数据库自然“发福”。
更关键的是：这个数据库不会自动清理，也不会按需压缩，它只增不减。而绝大多数用户，其实只需要最近一周或一个月的历史记录；那些三个月前的测试音频、格式错误的MP3、误点的批量任务，早该被归档或丢弃。
今天这篇实操指南，就带你彻底搞懂history.db的存储逻辑、安全清理路径和长效管理策略——不删模型、不重装系统、不丢失关键数据，三步完成轻量化瘦身。
1. 先搞清：history.db里到底存了什么？
Fun-ASR WebUI使用SQLite作为本地历史记录数据库，路径固定为webui/data/history.db。它不是简单的日志文件，而是一个结构清晰的关系型数据库，核心表只有1张：recognition_history。
我们先用命令行快速探查它的实际结构（无需安装额外工具）：
# 进入WebUI根目录 cd /path/to/funasr-webui # 查看数据库基本信息（需要sqlite3命令） sqlite3 webui/data/history.db ".stats"你会看到类似输出：
Memory Used: 0 bytes Number of Schemas: 1 Pages in Heap: 12456 Automatically Vacuum: no页数（Pages）超过1万，基本就说明数据库已明显臃肿。再看表结构：
sqlite3 webui/data/history.db ".schema recognition_history"输出精简后如下：
CREATE TABLE recognition_history ( id INTEGER PRIMARY KEY AUTOINCREMENT, timestamp TEXT NOT NULL, filename TEXT NOT NULL, filepath TEXT, language TEXT DEFAULT 'zh', raw_text TEXT, itn_text TEXT, hotwords TEXT, itn_enabled BOOLEAN DEFAULT 1, duration REAL, model_name TEXT DEFAULT 'funasr-nano-2512' );重点字段解读：
id：自增主键，每次识别+1，永不重复、永不重置timestamp：ISO格式时间（如2025-03-15T14:22:08.342Z），是排序和筛选依据filename&filepath：原始音频文件名与完整路径（注意：路径可能包含本地绝对路径，敏感信息需留意）raw_text/itn_text：这是最占空间的部分，尤其当识别结果很长（如1小时会议转写），单条记录可达数万字符hotwords：纯文本存储，体积小但可辅助定位特定任务duration：音频时长（秒），用于统计分析
关键认知：
history.db的膨胀，90%以上来自raw_text和itn_text字段的累积。一条5分钟会议录音的识别结果，文本量轻松破万字；100条就是百万级字符——SQLite虽高效，但纯文本堆叠仍会显著拖慢查询速度。
2. 安全清理：三种方法，按需选择
清理≠删除全部。我们提供渐进式、可回滚、零风险的三档方案，从最保守到最彻底，你可根据当前需求自由选择。
2.1 方案一：WebUI界面一键清空（适合新手，操作最简单）
这是官方支持的最安全方式，全程在浏览器内完成，无需接触命令行。
操作路径：识别历史→ 滚动到底部 → 点击【清空所有记录】按钮 → 弹窗确认 → 输入验证码（如有）→ 确认
优点：
- 无技术门槛，点击即生效
- 自动触发SQLite VACUUM（数据库压缩），释放磁盘空间
- 不影响模型、配置、其他功能模块
注意：
- 此操作不可撤销，请确保已导出重要记录（见2.3节）
- 清空后，
id计数器不会重置，下一条记录ID仍是原最大值+1（不影响使用） - 若数据库已严重损坏（如页面打不开），此方法可能失效，需降级使用方案二
执行完成后，可立即验证效果：
# 查看文件大小变化（单位：KB） ls -lh webui/data/history.db # 清空前：1.2G → 清空后：12K（典型值）2.2 方案二：SQL命令精准删除（适合有基础用户，灵活可控）
当你只想删除某段时间、某个关键词或某类文件的历史，而非全部清空时，命令行+SQL是唯一高效解法。
前提准备：
确保系统已安装sqlite3（Ubuntu/Debian：sudo apt install sqlite3；CentOS/RHEL：sudo yum install sqlite3；Mac：brew install sqlite3）
2.2.1 删除指定时间范围前的记录（推荐日常维护）
例如：只保留最近30天的记录，删除更早的全部数据：
# 进入数据库并执行删除（替换 YOUR_PATH 为实际路径） sqlite3 /path/to/funasr-webui/webui/data/history.db \ "DELETE FROM recognition_history WHERE timestamp < datetime('now', '-30 days');" # 强制压缩数据库，真正释放磁盘空间 sqlite3 /path/to/funasr-webui/webui/data/history.db "VACUUM;"时间格式说明：SQLite的datetime()函数支持'-30 days'、'-7 days'、'-1 month'等，精确到天。若需精确到小时，可用'-72 hours'。
2.2.2 删除包含特定关键词的记录（如测试文件、错误格式）
比如所有文件名含test_或error的记录：
sqlite3 /path/to/funasr-webui/webui/data/history.db \ "DELETE FROM recognition_history WHERE filename LIKE '%test_%' OR filename LIKE '%error%';" sqlite3 /path/to/funasr-webui/webui/data/history.db "VACUUM;"2.2.3 删除超长文本记录（针对大文件导致的单条巨量存储）
识别一段2小时音频，raw_text可能达20万字，远超普通记录。可按文本长度过滤：
# 删除 raw_text 字符数 > 50000 的记录（约对应1小时以上音频） sqlite3 /path/to/funasr-webui/webui/data/history.db \ "DELETE FROM recognition_history WHERE length(raw_text) > 50000;" sqlite3 /path/to/funasr-webui/webui/data/history.db "VACUUM;"安全提示：执行任何
DELETE前，务必先备份！cp webui/data/history.db webui/data/history.db.backup_$(date +%Y%m%d)
2.3 方案三：导出+重建（适合重度用户，彻底焕新）
当数据库已出现索引损坏、查询异常，或你想完全重置ID序列、清理碎片时，这是终极方案。
步骤分解：
导出有效数据为CSV（保留你需要的记录）
# 导出最近7天的记录（含所有字段） sqlite3 -header -csv /path/to/funasr-webui/webui/data/history.db \ "SELECT * FROM recognition_history WHERE timestamp >= datetime('now', '-7 days');" \ > history_recent.csv备份原库并删除
mv webui/data/history.db webui/data/history.db.old初始化全新空库
sqlite3 webui/data/history.db << 'EOF' CREATE TABLE recognition_history ( id INTEGER PRIMARY KEY AUTOINCREMENT, timestamp TEXT NOT NULL, filename TEXT NOT NULL, filepath TEXT, language TEXT DEFAULT 'zh', raw_text TEXT, itn_text TEXT, hotwords TEXT, itn_enabled BOOLEAN DEFAULT 1, duration REAL, model_name TEXT DEFAULT 'funasr-nano-2512' ); EOF导入CSV数据（可选）
# 需先安装 csvsql 或使用 Python 脚本导入，此处略（如需可提供脚本） # 更推荐：将CSV作为独立归档，新库从零开始
效果：新库体积<100KB，查询响应毫秒级，ID从1重新计数。
代价：历史记录ID连续性中断，但对功能无任何影响。
3. 长效管理：让history.db不再“发福”
清理只是治标，建立可持续的管理机制才是治本。以下三条实践建议，来自真实生产环境验证：
3.1 设置自动清理周期（推荐：每周一次）
将方案二中的SQL命令写成定时任务，让系统自己干活。
以Linux为例，添加crontab：
# 编辑当前用户定时任务 crontab -e # 添加一行（每周日凌晨2点执行，保留30天） 0 2 * * 0 cd /path/to/funasr-webui && sqlite3 webui/data/history.db "DELETE FROM recognition_history WHERE timestamp < datetime('now', '-30 days');" && sqlite3 webui/data/history.db "VACUUM;"为什么选30天？
- 覆盖绝大多数业务场景的追溯需求（项目复盘、问题回溯）
- 数据库体积稳定在50~200MB区间，性能无压力
- 避免因遗忘导致再次膨胀
3.2 批量处理时关闭历史记录（针对高吞吐场景）
如果你主要用Fun-ASR做后台批量转写（如每天处理100+客服录音），每条都存历史纯属冗余。
修改WebUI源码（仅需1行）：
打开app.py（或webui/app.py），找到保存历史的逻辑块，通常形如：
# 伪代码示意 def save_to_history(...): conn.execute("INSERT INTO recognition_history (...) VALUES (...)")在调用前加判断：
# 新增：环境变量控制是否记录 import os if os.getenv("FUNASR_DISABLE_HISTORY", "0") == "1": return # 直接跳过保存启动时加参数：
FUNASR_DISABLE_HISTORY=1 bash start_app.sh效果：批量任务极速完成，history.db零增长，磁盘压力归零。
3.3 历史数据分级存储（专业级建议）
将history.db视为“热数据”，另建“冷数据”归档体系：
| 数据类型 | 存储位置 | 保留策略 | 访问方式 |
|---|---|---|---|
| 最近7天 | history.db（热库） | 自动清理 | WebUI直接查看 |
| 7~90天 | history_archive.db（冷库） | 每季度压缩归档 | 专用查询脚本 |
| 90天以上 | history_backup_2025Q1.zip | 永久离线存储 | 解压后用DB Browser查看 |
实现只需一个归档脚本（可提供），核心逻辑：
- 每月初将热库中
timestamp < datetime('now', '-7 days')的数据导出 - 插入冷库表（结构相同）
- 从热库中删除已归档记录
- 压缩冷库为ZIP并移至NAS/对象存储
这样既保障高频访问性能，又满足长期审计要求，是企业级部署的标准实践。
4. 进阶技巧：用好history.db的隐藏价值
别只把它当“垃圾场”，这个数据库其实藏着不少实用宝藏：
4.1 快速统计你的ASR使用画像
想知道过去一个月，你最常识别什么语言？处理了多少总时长？哪些文件名出现最多？
# 统计各语言使用次数 sqlite3 webui/data/history.db "SELECT language, COUNT(*) FROM recognition_history GROUP BY language;" # 计算总处理时长（小时） sqlite3 webui/data/history.db "SELECT ROUND(SUM(duration)/3600, 2) FROM recognition_history;" # 查看TOP5高频文件名（去后缀） sqlite3 webui/data/history.db "SELECT SUBSTR(filename, 1, INSTR(filename, '.')-1), COUNT(*) FROM recognition_history GROUP BY 1 ORDER BY 2 DESC LIMIT 5;"这些数据能帮你优化工作流：比如发现80%是中文，可默认关闭英文模型加载；发现大量meeting_*.mp3，可预设热词模板。
4.2 修复损坏的历史记录（当WebUI显示乱码或空白）
偶尔因异常退出，raw_text字段可能存入非法UTF-8字符，导致页面渲染失败。
用SQL安全修复：
# 将所有raw_text中非UTF-8字符替换为空（保留可读部分） sqlite3 webui/data/history.db \ "UPDATE recognition_history SET raw_text = CAST(raw_text AS TEXT) WHERE typeof(raw_text) != 'text';"4.3 导出为Excel供业务分析
一线同事不需要看数据库，但需要把识别结果导入Excel做质检。用Python一行搞定：
import pandas as pd import sqlite3 conn = sqlite3.connect("webui/data/history.db") df = pd.read_sql_query("SELECT timestamp, filename, itn_text as result FROM recognition_history WHERE timestamp >= datetime('now', '-7 days');", conn) df.to_excel("asr_weekly_report.xlsx", index=False) print("导出完成：asr_weekly_report.xlsx")5. 总结：让Fun-ASR轻装上阵，专注语音本质
回顾全文，我们解决了三个层次的问题：
- 认知层：明白
history.db不是黑盒，而是结构清晰、可读可写的SQLite数据库，膨胀主因是文本累积； - 操作层：掌握从界面清空、SQL精准删除到导出重建的三级清理方案，兼顾安全与效率；
- 治理层：建立自动清理、分级存储、数据洞察的长效机制，让系统越用越顺，而非越用越卡。
最后强调一个原则：不要等到数据库突破1GB才行动。当它超过300MB时，就该启动首次清理；超过500MB，性能下降已肉眼可见。定期维护5分钟，胜过故障排查两小时。
现在，就打开终端，运行那条VACUUM命令吧——看着history.db从几百MB缩回几十KB，那种清爽感，正是本地AI部署独有的掌控之美。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
