SQLite数据库文件的大小变化往往被忽略，直到磁盘空间不足才被发现。实际上，监控文件大小并不复杂，关键是选对指标和设定合理的预警阈值。数据库文件一旦因为空间不足无法写入，轻则业务报错，重则损坏数据文件，恢复成本极高。因此，建立一套可靠的监控与预警机制，对于依赖SQLite的应用程序来说非常有必要。
一、SQLite文件大小为什么会持续增长
SQLite文件大小增长的原因主要有几个。一是删除或更新数据后，数据库文件并不会立即缩小。SQLite采用页式存储，删除记录只是把对应页标记为可复用，页本身仍保留在文件中。这种机制虽然能提高写入性能，但会导致文件占用空间远大于实际数据量。二是事务日志文件（WAL文件）在写入频繁时可能持续增大。当数据库以WAL模式运行时，所有修改先写入-wal文件，只有checkpoint之后才会合并回主数据库文件。如果checkpoint不及时，WAL文件可能变得很大。三是索引构建和历史数据积累也会导致文件膨胀，尤其是未定期清理过期记录的场景。四是auto_vacuum设置不当，默认情况下SQLite不会自动回收空闲页，必须手动执行VACUUM。
理解这些原因之后，监控就不能只看主数据库文件，还要关注-wal和-shm文件的总占用。同时，单纯看绝对大小还不够，增长速率也是预警的重要依据。比如某个数据库文件每天增长50MB，那么可以提前预测何时会达到磁盘上限。下一节会介绍如何准确获取这些数据。
二、获取SQLite数据库文件大小的几种方法
获取SQLite数据库文件大小有两种常见思路：文件系统视角和数据库内部视角。文件系统视角最简单，直接读取主数据库文件、-wal文件、-shm文件的磁盘占用。以Python为例，可以用os.path.getsize函数。但要注意，SQLite连接打开时，-wal和-shm文件可能被临时修改或删除，因此读取前最好先关闭连接，或者使用数据库连接提供的信息。
数据库内部视角则是通过PRAGMA语句计算逻辑大小。执行PRAGMA page_count获取总页数，PRAGMA page_size获取每页字节数，两者相乘即可得到数据库文件的理论大小。需要注意的是，这个结果不包含WAL文件未合并的数据，因此当数据库为WAL模式时，还应该加上-wal文件的大小。此外，SQLite提供了PRAGMA freelist_count查看空闲页数量，可以了解有多少空间是碎片。通过逻辑大小和文件实际大小对比，可以判断是否需要执行VACUUM。
下面是一段Python示例代码，演示如何同时获取数据库的逻辑大小和磁盘文件大小：
import os
import sqlite3
def get_sqlite_sizes(db_path):
# 获取文件系统上的实际大小
main_size = os.path.getsize(db_path)
wal_size = 0
shm_size = 0
if os.path.exists(db_path + '-wal'):
wal_size = os.path.getsize(db_path + '-wal')
if os.path.exists(db_path + '-shm'):
shm_size = os.path.getsize(db_path + '-shm')
total_disk_size = main_size + wal_size + shm_size
# 获取数据库内部逻辑大小
conn = sqlite3.connect(db_path)
cursor = conn.cursor()
cursor.execute('PRAGMA page_count')
page_count = cursor.fetchone()[0]
cursor.execute('PRAGMA page_size')
page_size = cursor.fetchone()[0]
logical_size = page_count * page_size
conn.close()
return logical_size, total_disk_size
db_path = 'example.db'
logical, disk = get_sqlite_sizes(db_path)
print(f'逻辑大小: {logical} bytes, 磁盘占用: {disk} bytes')
在获取磁盘大小时，如果数据库文件被其他进程占用，读取-wal或-shm文件时可能会遇到权限或文件不存在的异常。建议将这些操作放在try-except块中，避免监控脚本自身崩溃。另外，文件系统大小和逻辑大小的差值可以反映碎片程度，差值越大说明可回收的空间越多。
三、设计监控脚本与自动预警机制
监控脚本的核心逻辑是定时获取数据库大小，与预设阈值比较，如果超过阈值则触发告警。阈值的设定需要结合业务情况：绝对大小阈值，如500MB、1GB；或者增长率阈值，如单日增长超过100MB。也可以两者结合，使用趋势预测提前预警。监控频率一般选择每小时或每分钟一次，具体取决于数据库写入频率和磁盘空间余量。
实现上，可以用操作系统的定时任务（cron或Windows计划任务）调用Python脚本，或者集成到现有监控平台。脚本中需要处理数据库连接可能失败的情况，以及获取大小时可能出现的权限问题。告警方式可以选择邮件、企业微信机器人、钉钉机器人等，只要发送一个HTTP请求或SMTP邮件即可。
下面给出一个完整的监控脚本示例，包含阈值判断和简单告警函数：
import os
import sqlite3
import smtplib
from email.mime.text import MIMEText
DB_PATH = '/data/app.db'
SIZE_THRESHOLD = 500 * 1024 * 1024 # 500MB
SMTP_SERVER = 'smtp.ipipp.com'
SMTP_PORT = 587
SMTP_USER = 'alert@ipipp.com'
SMTP_PASS = 'your_password'
ALERT_EMAIL = 'admin@ipipp.com'
def get_total_size(db_path):
total = os.path.getsize(db_path)
for suffix in ['-wal', '-shm']:
if os.path.exists(db_path + suffix):
total += os.path.getsize(db_path + suffix)
return total
def send_alert(current_size):
msg = MIMEText(f'SQLite数据库 {DB_PATH} 当前大小 {current_size / 1024 / 1024:.2f} MB，已超过阈值 {SIZE_THRESHOLD / 1024 / 1024:.2f} MB，请及时处理。')
msg['Subject'] = 'SQLite数据库大小预警'
msg['From'] = SMTP_USER
msg['To'] = ALERT_EMAIL
with smtplib.SMTP(SMTP_SERVER, SMTP_PORT) as server:
server.starttls()
server.login(SMTP_USER, SMTP_PASS)
server.sendmail(SMTP_USER, [ALERT_EMAIL], msg.as_string())
if __name__ == '__main__':
size = get_total_size(DB_PATH)
print(f'当前数据库总大小: {size / 1024 / 1024:.2f} MB')
if size > SIZE_THRESHOLD:
send_alert(size)
print('已发送告警邮件')
else:
print('大小正常')
告警逻辑中还应当考虑抑制机制，避免数据库大小在阈值附近波动时频繁发送邮件。可以在脚本中记录上一次告警时间，设置一个最小告警间隔（如30分钟），只有超过该间隔才再次发送。对于增长率异常，可以记录历史大小数据，计算滑动窗口内的平均增长率，一旦增长率超过预设值就发出预警，提前介入处理。
四、空间回收与自动维护策略
当数据库大小超过阈值时，除了告警，还需要考虑自动或手动回收空间。最常见的操作是执行VACUUM命令，它会重建数据库文件，释放空闲页，使文件大小接近实际数据大小。但VACUUM需要额外的磁盘空间，因为它在重建过程中会创建临时文件，而且执行期间会锁定数据库，导致其他读写操作阻塞。因此生产环境必须谨慎，最好在业务低峰期执行，并先备份数据。
另一个方法是开启auto_vacuum。通过PRAGMA auto_vacuum = FULL可以在创建数据库时设置自动回收空闲页。但注意，auto_vacuum只能在新数据库创建时指定，对于已有数据库需要先执行VACUUM才能改变该设置。auto_vacuum会略微增加写入开销，但对于频繁删除的场景可以避免文件持续膨胀。此外，如果使用WAL模式，定期执行wal_checkpoint可以控制-wal文件的大小，例如PRAGMA wal_checkpoint(TRUNCATE)会截断WAL文件。这些操作可以整合到监控脚本中，当检测到文件大小超过阈值时，先尝试执行空间回收，如果回收后仍然超限，再发送告警。
需要强调，空间回收不是万能的，如果数据本身就在增长，回收只能缓解一时的空间压力。根本解决方案是制定数据归档和清理策略，比如定期删除过期数据，或者将历史数据迁移到归档数据库。监控数据可以帮助评估这些策略的效果，例如对比VACUUM前后的文件大小，判断碎片比例。通过持续监控和定期维护，SQLite数据库可以在资源受限的环境中稳定运行，避免因磁盘写满导致的业务中断。