SpeedTest-Tracker 数据库清理功能失效问题分析与解决方案

问题背景

SpeedTest-Tracker 是一款优秀的网络测速结果追踪工具，它内置了一个数据库清理功能，可以通过 PRUNE_RESULTS_OLDER_THAN 环境变量设置保留测速结果的天数。然而，在实际使用中发现，修改这个参数值后，系统并未按预期清理旧数据。

问题现象

用户报告当将 PRUNE_RESULTS_OLDER_THAN 从180天调整为90天后，系统并没有自动清理超过90天的测速记录。进一步检查发现，即使使用默认的180天设置，系统也没有执行自动清理功能。

技术分析

1. 环境变量处理问题

最初的问题根源在于环境变量值的类型处理不当。当系统尝试将环境变量值转换为时间间隔时，出现了"非数值类型"的错误。这是因为环境变量虽然以数字形式配置，但在代码处理过程中被当作字符串处理，导致时间计算失败。

2. 定时任务执行机制

SpeedTest-Tracker 使用 Laravel 的任务调度系统，理论上应该每天午夜执行数据清理任务。但实际观察发现，这个定时任务并没有如期执行。可能的原因包括：

• 容器时区配置不正确
• Laravel 任务调度器未正确初始化
• 权限问题导致任务无法执行

3. 数据库连接问题

使用外部数据库（如用户案例中的 MariaDB）时，可能存在连接稳定性问题，导致长时间运行的任务中断。

解决方案

1. 代码修复

项目维护者已经发布了修复补丁（1.2.2版本），确保环境变量值被正确转换为整数类型。用户应升级到最新版本以解决类型转换问题。

2. 手动验证

升级后，可以通过以下命令验证清理功能是否正常工作：

php artisan model:prune --pretend

此命令会模拟执行清理操作，显示将被删除的记录数量，而不会实际删除数据。

3. 定时任务调试

如果自动清理仍然不工作，可以尝试以下调试步骤：

1. 检查容器时区设置是否与主机一致
2. 查看 Laravel 日志中是否有任务调度相关的错误
3. 临时修改任务调度时间为当前时间附近，观察是否执行

4. 备选方案

作为临时解决方案，可以设置一个外部cron任务，定期执行清理命令：

docker exec speedtest-tracker php /app/www/artisan model:prune

最佳实践建议

1. 定期维护：即使自动清理功能正常工作，也建议定期手动检查数据库大小和记录数量。

2. 监控设置：为清理操作设置日志监控，确保任务按预期执行。

3. 备份策略：在执行大规模清理前，确保有完整的数据备份。

4. 性能考量：对于大型数据库，清理操作可能耗时较长，建议在低峰期执行。

总结

SpeedTest-Tracker 的数据清理功能是一个实用的特性，能够有效管理数据库增长。通过版本升级和适当配置，用户可以确保这一功能稳定可靠地工作。对于关键业务环境，建议结合手动验证和监控，构建多层次的数据管理策略。