现在NoSQL流行，有一个原因也是因为不需要去刻意处理table的schema，直接存储数据，这样简单!所以也不会有数据库表的迁移问题。数据库表迁移这一块儿一直是一个麻烦点，但我最近用了sqlite3做了个小项目，所以总结下数据库迁移的方案。 　　原理 　　每一次数据表改动，都对应一个数据库版本号 　　数据迁移是渐进式的，比如把数据库版本从1 升级到n，那么就升级n-1次，版本1到2，2到3，直到n-1到n。 　　实施 　　1. 使用sqlite3的user_version 存贮自定义的数据库版 　　/*设置版本号*/ 　　PRAGMA user_version=1; 　　/*读取版本号*/ 　　PRAGMA user_version;

　　2. 所有的数据库升级文件，放在一个文件中，都直接使用sql文件，方便直接查看管理。文件结构如下

　　v1.sql v2.sql, v3.sql等 是每个数据库版本，完整的数据库定义文件 　　v1tov2.sql, v2tov3.sql等 是间隔版本数据库升级文件。一个数据m到n升级的过程就是，运行 v[m]tov[m+1].sql, v[m+1]tov[m+2].sql, 直到 v[n-1]tov[n].sql 　　run.sh 就是每次要跑的数据迁移脚本，包括了当前的版本号和迁移逻辑 　　其中的v2.sql 到v[n].sql 不是必须的，只是为了方便查看当前最新的数据表设计，如果存在v[n].sql 那么创建新数据库也可以直接从这个文件来创建 　　3. 迁移脚本如下， 具体逻辑注释中已经写明。 　　4. v[n].sql 和v[n-1]tov[n].sql 文件的最后都去需要通过user_version来设置数据版本为n，一个v2tov3.sql 的demo如下： 　　总结 　　使用场景 　　目前这套方案适合数据量小，对停机维护可以接受的业务情况，因为需要停机升级，但是这个方案，足够简单清晰且能满足所有不同版本间的数据升级。 　　不足与展望 　　这个方案没有考虑到数据升级失败的回滚。由于是小业务，所以考虑更多的是简单易维护。所以针对这种情况的，首先要保证升级脚本经过了足够的线上数据测试，经的起考验。其次，一旦发生问题，线上可以直接操作维护，写脚本。这样说，因为你都没有测试到这种需要rollback的case，你也不能在写升级脚本的时候，知道这种case是怎样，所以提前写好rollback的逻辑不一定可行或者合适。 　　部署时，数据迁移之前要备份，数据量较大些，用增量备份，节省时间。备份有成熟的工具，而且备份方便升级失败时rollback。部署的步骤应该是: 拉代码build(或者拉docker镜像)-> 备份数据库 -> 升级数据库 -> 跑新的代码 　　对于Android，iOS的设备中使用sqlite3的情况，数据迁移的逻辑是一样。sql文件结构设计可以重用，也可以写到代码里去管理。迁移脚本需要转换成native的Java或者Objective-C，Swift的代码。 　　对于更大的业务，多实例的的数据库迁移可以使用Flyway。