SQlite

# PRAGMA 命令
https://www.sqlite.org/pragma.html#pragma_journal_mode
https://www.w3cschool.cn/sqlite/sqlite-pragma.html
## 查询锁模式

PRAGMA locking_mode;
PRAGMA locking_mode = NORMAL | EXCLUSIVE（排它模式）

此编译指示设置或查询数据库连接锁定模式。 锁定模式为 NORMAL 或 EXCLUSIVE。

在 NORMAL 锁定模式下（默认值，除非在编译时被覆盖 使用 SQLITE_DEFAULT_LOCKING_MODE）、数据库连接 在每次读取结束时解锁数据库文件或 写入事务。当锁定模式设置为 EXCLUSIVE 时， 数据库连接从不释放文件锁。第一次 数据库以 EXCLUSIVE 模式读取，获取共享锁，然后 举行。第一次写入数据库时，独占锁是 获得并持有。

在 EXCLUSIVE 模式下通过连接获取的数据库锁可能是 通过关闭数据库连接或将 locking-mode 使用此编译指示返回 NORMAL，然后访问 数据库文件（用于读取或写入）。只需将锁定模式设置为 NORMAL 是不够的 - 锁直到下一次才会释放 访问数据库文件。

将锁定模式设置为 EXCLUSIVE 有三个原因。

应用程序希望阻止其他进程 访问数据库文件。
文件系统操作的系统调用次数减少， 可能会导致性能略有提高。
WAL 数据库可以在 EXCLUSIVE 模式下访问，而无需 使用共享内存。 （附加信息)
当 locking_mode 编译指示指定特定数据库时， 例如：

PRAGMA 主要。locking_mode=排他性;
然后，锁定模式仅适用于指定的数据库。如果没有 数据库名称限定符位于“locking_mode”关键字之前 锁定模式将应用于所有数据库，包括任何新的数据库 由后续 ATTACH 命令添加的数据库。

“temp”数据库（其中存储了 TEMP 表和索引） 内存中数据库始终使用独占锁定模式。临时数据库和内存数据库的锁定模式不能 被更改。默认情况下，所有其他数据库都使用正常锁定模式 并受到这种杂报的影响。

如果首次进入 WAL 日志模式时锁定模式为 EXCLUSIVE，则锁定模式无法更改为 NORMAL 直到退出 WAL 日志模式后。 如果首次进入 WAL 时锁定模式为 NORMAL 日志模式，则锁定模式可以在 NORMAL 和 独家，并随时返回，无需退出 WAL 日志模式。


## journal_mode 获取或设置控制日志文件如何存储和处理的日志模式
       PRAGMA journal_mode;
       PRAGMA journal_mode = mode;（设置）
       
      PRAGMA journal_mode = DELETE | TRUNCATE | PERSIST | MEMORY | WAL | OFF
      
此编译指示查询或设置数据库的日志模式 与当前数据库连接相关联。

此编译指示的第一种形式查询当前日记 数据库的模式。当省略 database 时， 查询“main”数据库。

第二种形式更改“数据库”的日记模式 或者对于所有附加的数据库，如果省略了“数据库”。 将返回新的日记模式。如果日记模式 无法更改，则返回原始日志模式。

DELETE 日记模式是正常行为。在 DELETE 中 模式下，回滚日志在每次结束时被删除 交易。实际上，删除操作是导致 要提交的事务。 （有关更多详细信息，请参阅标题为“SQLite 中的原子提交”的文档。

TRUNCATE 日志模式通过截断来提交事务 将日志回滚到零长度，而不是删除它。在许多 系统，截断文件比删除文件快得多，因为 包含目录不需要更改。

PERSIST 日记模式可防止回滚日记 在每笔交易结束时被删除。相反，标头 的日记被零覆盖。这将防止其他 回滚日志的数据库连接。坚持 日记模式在以下平台上作为优化非常有用 删除或截断文件比覆盖文件要昂贵得多 文件的第一个块为零。参见：PRAGMA journal_size_limit 和 SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT。

MEMORY 日志模式将回滚日志存储在 易失性 RAM。这样可以节省磁盘 I/O，但会牺牲数据库 安全与诚信。如果使用 SQLite 的应用程序在 设置MEMORY日志模式时事务的中间， 那么数据库文件很可能会损坏。

WAL 日记模式使用预写日志而不是 回滚日志以实现事务。WAL 日记模式 是持久的;设置后，它保持有效 跨多个数据库连接，关闭后和 重新打开数据库。WAL 日记模式下的数据库 只能通过SQLite版本3.7.0访问（2010-07-21） 或更高版本。

OFF 日记模式完全禁用回滚日志。 从未创建过回滚日志，因此永远不会有回滚 要删除的日记。OFF 日志模式禁用原子 SQLite的提交和回滚功能。ROLLBACK 命令 不再起作用;它以一种未定义的方式运行。申请必须 避免在日志模式为 OFF 时使用 ROLLBACK 命令。 如果应用程序崩溃 在事务处理过程中，当 OFF 日志模式为 设置，则数据库文件很可能会损坏。没有日记，就没有办法 在以下情况下解除部分完成操作的声明 约束错误。这也可能使数据库处于损坏状态 州。例如，如果重复的条目导致 CREATE UNIQUE INDEX 语句中途失败， 它将留下一个部分创建的索引，因此会损坏索引。 因为 OFF 日记 mode 允许使用普通 SQL 损坏数据库文件， 启用 SQLITE_DBCONFIG_DEFENSIVE 时，它将被禁用。

请注意，内存中数据库的journal_mode为 MEMORY 或 OFF，不能更改为其他值。 尝试将内存中数据库的journal_mode更改为 忽略 MEMORY 或 OFF 以外的任何设置。另请注意， 当事务处于活动状态时，无法更改journal_mode。
## 
一个程序使用SQlite数据库，进行读写操作，我使用数据库管理工具连接了这个SQLite 库，使用UPdate 更新表中的数据，无法更新数据
这时我在数据库管理工具里 执行PRAGMA journal_mode=waL ,就可以UPdate 修改数据，请问应用程序对SQLite进行了那些操作导致了这种情况？

##  PRAGMA schema.synchronous; 查询或更改“同步”标志的设置
PRAGMA schema.synchronous = 0 | OFF | 1 | NORMAL | 2 | FULL | 3 | EXTRA;
 ### EXTRA(3)
     EXTRA同步与FULL类似，除了目录 包含回滚日志的日志在取消链接后同步 以 DELETE 模式提交事务。EXTRA提供额外的 持久性，如果提交紧随其后的是断电。
 ### FULL （2）
    当 synchronous 为 FULL （2） 时，SQLite 数据库引擎将 使用 VFS 的 xSync 方法确保所有内容都是安全的 在继续操作之前写入磁盘表面。 这可确保操作系统崩溃或电源故障将 不会损坏数据库。 FULL 同步非常安全，但也较慢。FULL 是 非 WAL 模式时最常用的同步设置。
 ### NORMAL （1）
   当 synchronous 为 NORMAL （1） 时，SQLite 数据库 引擎在最关键的时刻仍会同步，但频率较低 比在 FULL 模式下。有一个非常小（尽管不是零）的几率 在错误的时间发生电源故障可能会损坏旧文件系统上 journal_mode=DELETE 中的数据库。
   WAL 模式在 synchronous=NORMAL 时不会损坏，并且可能 DELETE 模式在现代文件系统上也是安全的。WAL 模式始终保持一致 替换为 synchronous=NORMAL，但 WAL 模式确实会失去持久性。交易 在 WAL 模式下使用 synchronous=NORMAL 提交可能会在以下情况下回滚 断电或系统崩溃。事务在应用程序中是持久的 无论同步设置或日志模式如何，都会崩溃。 对于大多数应用程序来说，synchronous=NORMAL 设置是一个不错的选择 在 WAL 模式下运行。
 ### OFF （0）
  在同步关闭 （0） 的情况下，SQLite 继续而不同步 一旦它将数据移交给操作系统。 如果运行 SQLite 的应用程序崩溃，数据将是安全的，但 如果操作系统 崩溃或计算机在写入数据之前断电 到磁盘表面。另一方面，提交可以是 同步关闭时幅度更快。