iOS CoreData -启用sqlite WAL /预写日志记录有什么缺点吗
在WWDC2013会议“207:核心数据中的新特性”上，他们提到您可以通过在添加持久存储时传递选项字典来启用SQLite WAL：
@{ NSSQLitePragmasOption: @"journal_mode = WAL" }(它在iOS4+上可用，并将成为未来iOS版本的默认设置)。
我想知道在我的应用程序中为早期的iOS版本启用这是否也是一件好事。
我咨询了SQLite page about write ahead logging和他们提到的缺点，除了以下几点，大多数缺点似乎都不适用于iOS：
在主要进行读取而很少进行写入的应用程序中，
- WAL可能比传统的回滚日志方法稍慢(可能要慢1%或2% )。
几乎所有的优点听起来都可能是iOS的优点：
- WAL在大多数情况下都要快得多。
- WAL提供了更多的并发性，因为读取器不会阻止写入器，写入器也不会阻止读取器。读取和写入可以继续使用WAL进行concurrently.
- Disk I/O操作。
- WAL使用的fsync()操作要少得多，因此在fsync()系统调用中断的系统上不容易受到问题的影响。
我断言(可能需要对我的应用程序做一些检查，以确保它不会减慢速度)，这将是一件好事，但是否有任何我应该关注的缺点或任何已知的问题？
回答 2
Stack Overflow用户
发布于 2013-07-05 19:02:26
http://pablin.org/2013/05/24/problems-with-core-data-migration-manager-and-journal-mode-wal/建议他们可能是迁移方面的问题，特别是：
当您使用迁移管理器时，核心数据将为您创建一个新数据库，并开始将实体从旧数据库逐个复制到新数据库。
当我们使用journal_mode = WAL时，除了DB.sqlite之外，还有一个名为DB.sqlite-wal的额外文件。
据我所知，问题似乎是核心数据创建了一个临时数据库，在那里插入了所有内容，当它将其重命名为原始名称时，-wal文件被保留为旧版本的遗留文件。问题是你最终得到了一个不一致的数据库。
(在https://github.com/magicalpanda/MagicalRecord/issues/490上也有提到-这表明如果你使用魔法记录，那么它已经默认为WAL )
Stack Overflow用户
发布于 2014-02-12 03:12:20
关于涉及子类化NSMigrationManager的非轻量级迁移中出现的错误，我已将其作为错误16038419重新报告给苹果。
我还创建了一个不同的method-swizzling workaround，它可以在您始终希望使用遗留的删除/回滚日志记录的情况下修补错误。据我所知，除了在迁移过程中，Pablin's fix是为您想要使用WAL的情况而设计的。此外，您还可以看到this video中出现了错误。
https://stackoverflow.com/questions/17487306
复制相似问题