现在NoSQL流行，一个原因就是不需要刻意处理表的schema，直接存储数据，sosimple！所以不会有数据库表的迁移问题。数据库表迁移一直是比较麻烦的一点，不过最近用sqlite3做一个小项目，所以总结一下数据库迁移方案。原理数据表每变化一次，对应一个数据库版本号。数据迁移是渐进的。比如数据库版本从1升级到n，那么会升级n-1次，从版本1升级到2，从2升级到3，直到n-1升级到n。实现1.使用sqlite3的user_version存储自定义数据库版本/*设置版本号*/PRAGMAuser_version=1;/*读取版本号*/PRAGMAuser_version;2.所有的数据库升级文件都放在一个文件中，都直接使用sql文件，方便直接查看和管理。文件结构如下：文件结构设计v1.sqlv2.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].sqlrun.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如下：总结使用场景。目前该方案适用于数据量小，可以接受停机维护的业务情况，需要停机升级，但该方案简单明了，足以满足所有不同版本之间的数据升级。不足与展望本方案没有考虑数据升级失败的回滚。由于它是一家小型企业，因此更多的是简单性和易于维护性。所以对于这种情况，首先要保证升级脚本已经通过了足够多的线上数据测试，经得起考验。其次，一旦出现问题，可以直接在线运维，编写脚本。这样一来，因为你没有测试过需要回滚的情况，写升级脚本的时候也不知道是什么情况，所以提前写回滚的逻辑可能不可行也不合适。部署时，数据迁移前需要备份。如果数据量很大，可以使用增量备份来节省时间。备份有成熟的工具，备份方便升级失败时回滚。部署步骤应该是：pullcodebuild（或pulldockerimage）->备份数据库->升级数据库->运行新代码对于使用sqlite3的Android和iOS设备，数据迁移的逻辑是一样的。sql文件结构设计可以复用，也可以写入代码进行管理。迁移脚本需要转换为原生Java或Objective-C、Swift代码。对于规模较大的业务，多实例数据库迁移可以使用Flyway
