在 WWDC 2013 session “207:核心数据中的新增功能”中，他们提到您可以在添加持久存储时通过传递选项字典来启用 SQLite WAL:
@{ NSSQLitePragmasOption: @"journal_mode = WAL" }
(在 iOS4+ 上可用，并将成为 future iOS 版本的默认设置)。
我想知道在我的应用程序中为较早的 iOS 版本启用这通常是否也是一件好事。
我咨询过SQLite page about write ahead logging以及他们提到的缺点，除了:
- WAL 可能比 主要执行任务的应用程序中的传统回滚日志方法 阅读，很少写作。
几乎所有的优势听起来都像是在 iOS 上的优势:
- 在大多数情况下，WAL 的速度要快得多。
- WAL 提供了更多的并发性，因为读者不会阻止作者，而作者也不会阻止读者。读写可以同时进行。
- 使用 WAL，磁盘 I/O 操作往往更具顺序性。
- WAL 使用更少的 fsync() 操作，因此在 fsync() 系统调用被破坏的系统上更不容易出现问题。
我假设(可能需要对我的应用程序进行一些检查以确保它不会减慢运行速度)启用这将是一件好事，但是我是否应该注意任何缺点或任何已知的缺点问题？
最佳答案
http://pablin.org/2013/05/24/problems-with-core-data-migration-manager-and-journal-mode-wal/表明他们可能是迁移问题，特别是:
When you use a Migration Manager, Core Data will create a new database for you, and start copying the entities one by one from the old DB to the new one.
As we are using journal_mode = WAL, there’s an additional file besides DB.sqlite called DB.sqlite-wal.
From what I can tell, the problem seems to be that Core Data creates a temporary DB, inserts everything there, and when it renames it to the original name, the -wal file is kept as a leftover from the old version. The problem is that you end up with an inconsistent DB.
(也在 https://github.com/magicalpanda/MagicalRecord/issues/490 中提到 - 这表明如果您使用 magic record 那么它已经默认为 WAL )
关于iOS CoreData - 启用 sqlite WAL/Write-Ahead Logging 有什么缺点吗，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17487306/