当前位置：首页 > 问答 > 正文

FMDB数据库升级那些事儿，遇到问题到底咋整才靠谱？

瞿欣合
问答
2025-12-23 21:49:06
2

说到用FMDB这个库在iOS应用里处理数据库,最让人头疼的恐怕就是应用版本更新时，数据库也要跟着升级这件事了，你想想，用户手机上装着你的App版本是1.0，里面有个数据库，等你发布了1.1版本，新增了几个功能，需要在数据库里加一张新表，或者给原来的表增加几个字段，这时候，老用户直接更新App，一打开，如果代码里没处理好，妥妥的闪退，因为新版App去操作一个不存在的表或字段，数据库直接就报错了。

数据库升级不是可选项,是必须好好处理的，那到底咋整才靠谱呢？核心思想就一句话：让数据库的版本号和你App的版本号同步起来，每次升级都明确知道要执行哪些操作。

第一步：搞清楚当前版本和目标版本

FMDB本身提供了一个简单的版本管理机制,就是通过userVersion这个属性，你可以把它理解成数据库自己的“内部版本号”，当你的App第一次安装时，创建完数据库结构，就应该把这个userVersion设为一个初始值，比如1。

每次App更新,如果数据库结构需要变动，你就在代码里检查当前的userVersion是多少，然后一步一步地把它升级到最新的版本。

第二步：制定靠谱的升级策略

最靠谱、最常用的方法就是渐进式升级，别想着一步到位，而是像上楼梯一样，一步一步来。

具体做法是,在你的数据库管理类里，写一个专门的方法，比如叫upgradeDatabase，在这个方法里，你获取当前的数据库版本号，然后用一个循环或者一系列的if-else判断，从当前版本开始，一个版本一个版本地执行升级SQL。

举个例子：假设你最开始数据库版本是1，现在要发布1.1版，需要加一张新表，那么升级到版本2，再下次发布1.2版，需要给某张老表加个字段，那么升级到版本3。

你的升级代码大概长这样：

// 获取当前数据库版本
int currentVersion = [db userVersion];
int targetVersion = 3; // 这是本次App更新希望达到的数据库版本
// 如果当前版本已经是最新，啥也不做
if (currentVersion == targetVersion) {
    return;
}
// 开启事务，保证升级操作的原子性，要么全成功，要么全失败
[db beginTransaction];
BOOL success = YES;
@try {
    // 从当前版本开始，逐步升级
    if (currentVersion < 2) {
        // 执行从版本1升级到版本2的SQL，比如创建新表
        success = [db executeUpdate:@"CREATE TABLE ..."];
        if (!success) break;
        currentVersion = 2; // 升级成功，设置当前版本为2
    }
    if (currentVersion < 3) {
        // 执行从版本2升级到版本3的SQL，比如给老表增加字段
        success = [db executeUpdate:@"ALTER TABLE ... ADD COLUMN ..."];
        if (!success) break;
        currentVersion = 3; // 升级成功，设置当前版本为3
    }
    // ... 以此类推，可以一直写下去
    // 所有升级步骤成功，设置数据库最终版本号
    if (success) {
        [db setUserVersion:targetVersion];
    }
}
@catch (NSException *exception) {
    success = NO;
    // 记录异常日志
}
@finally {
    if (success) {
        [db commit]; // 提交事务
    } else {
        [db rollback]; // 回滚事务，数据库恢复到升级前的状态
        // 这里处理升级失败的情况，可能需要更严重的错误提示甚至删除重建数据库
    }
}

这种方法的好处非常明显：

覆盖所有情况：无论用户是从非常老的版本升级上来（比如从版本1直接升到版本5），还是逐个版本升级，这个逻辑都能正确执行所有必要的升级步骤。
清晰可控：每个版本的变更都写在对应的if块里，一目了然，以后维护起来也方便。

第三步：处理升级中的“坑”

光有策略还不够,实际操作中会遇到很多具体问题：

ALTER TABLE的限制：SQLite的ALTER TABLE命令功能比较弱，它只能添加列，不能删除列，不能修改列名或类型，如果你需要做这些操作，就得用“曲线救国”的方式：
- 创建一个新表,包含你想要的最终结构。
- 把旧表的数据导入新表。
- 删除旧表。
- 把新表重命名为旧表的名称。这个过程稍微麻烦点，但FMDB的轻量级事务可以保证这个过程的安全。
数据迁移：有时候不只是改结构，还要改数据，你把一个存储性别的字段，从字符串"男"/"女"改成数字0/1，这就需要在新增加字段后，写一段逻辑，遍历老数据，进行转换和填充，这个操作最好也放在事务里，和结构变更一起完成。
升级失败怎么办？ 上面的代码里用了事务，一旦某一步出错，整个升级过程会回滚，数据库保持原样，但这可能意味着用户无法使用新功能，一种更极端的处理方式是，如果升级失败，记录错误日志，然后备份当前数据库文件，删除它，再根据最新结构重新创建一个空的数据库，这会导致用户数据丢失，所以是下下策，但至少保证了App不闪退，对于重要数据，应该考虑在升级前先备份数据库文件。
测试！测试！测试！ 这是最最重要的一步，你一定要模拟各种升级路径：从版本1升到最新版，从版本2升到最新版……确保每条路径都能走通，手动测试虽然繁琐，但对于保证稳定性至关重要。