SQLite在3.7.0版本的WAL机制

   在android P上调试数据库拷贝问题时，发现应用的databases目录下除了普通的db后缀的数据库文件外，还有两个额外的文件，以我自己的应用为例，分别为 app.db、app.db-wal、app.db-shm。 然后发现即使已经往数据库更新数据后，通过工具打开db文件发现文件中的数据并未变化。调查了下发现是SQLite在3.7.0版本上的新特性。

     1.什么是WAL？

      WAL的全称是Write Ahead Logging，它是很多数据库中用于实现原子事务的一种机制，SQLite在3.7.0版本引入了该特性。

      2.WAL如何工作？

      在引入WAL机制之前，SQLite使用rollback journal机制实现原子事务。

      rollback journal机制的原理是：在修改数据库文件中的数据之前，先将修改所在分页中的数据备份在另外一个地方，然后才将修改写入到数据库文件中；如果事务失败，则将备份数据拷贝回来，撤销修改；如果事务成功，则删除备份数据，提交修改。

      WAL机制的原理是：修改并不直接写入到数据库文件中，而是写入到另外一个称为WAL的文件中；如果事务失败，WAL中的记录会被忽略，撤销修改；如果事务成功，它将在随后的某个时间被写回到数据库文件中，提交修改。

      同步WAL文件和数据库文件的行为被称为checkpoint（检查点），它由SQLite自动执行，默认是在WAL文件积累到1000页修改的时候；当然，在适当的时候，也可以手动执行checkpoint，SQLite提供了相关的接口。执行checkpoint之后，WAL文件会被清空。

      在读的时候，SQLite将在WAL文件中搜索，找到最后一个写入点，记住它，并忽略在此之后的写入点（这保证了读写和读读可以并行执行）；随后，它确定所要读的数据所在页是否在WAL文件中，如果在，则读WAL文件中的数据，如果不在，则直接读数据库文件中的数据。

      在写的时候，SQLite将之写入到WAL文件中即可，但是必须保证独占写入，因此写写之间不能并行执行。

      WAL在实现的过程中，使用了共享内存技术，因此，所有的读写进程必须在同一个机器上，否则，无法保证数据一致性。

      3.WAL的优点与缺点

      优点：

      1.读和写可以完全地并发执行，不会互相阻塞（但是写之间仍然不能并发）。

      2.WAL在大多数情况下，拥有更好的性能（因为无需每次写入时都要写两个文件）。

      3.磁盘I/O行为更容易被预测。

      缺点：

      1.访问数据库的所有程序必须在同一主机上，且支持共享内存技术。

      2.每个数据库现在对应3个文件：<yourdb>.db，<yourdb>-wal，<yourdb>-shm。

      3.当写入数据达到GB级的时候，数据库性能将下降。

      4.3.7.0之前的SQLite无法识别启用了WAL机制的数据库文件。

      4.WAL引入的兼容性问题

      在启用了WAL之后，数据库文件格式的版本号由1升级到了2，因此，3.7.0之前的SQLite无法识别启用了WAL机制的数据库文件。

      禁用WAL会使数据库文件格式的版本号恢复到1，从而可以被SQLite 3.7.0之前的版本识别。

      5.WAL引入的性能问题

      在一般情况下，WAL会提高SQLite的事务性能；但是在某些极端情况下，却会导致SQLite事务性能的下降。

      1.在事务执行时间较长或者要修改的数据量达到GB级的时候，WAL文件会被占用，它会暂时阻止checkpoint的执行（checkpoint会清空WAL文件），这将导致WAL文件变得很大，增加寻址时间，最终导致读写性能的下降。

      2.当checkpoint执行的时候，会降低当时的读写性能，因此，WAL可能会导致周期性的性能下降。

    

对于android开发来说，SqliteOpenHelper.java类中有接口可启用或禁用WAL模式：

/**
     * Enables or disables the use of write-ahead logging for the database.
     *
     * Write-ahead logging cannot be used with read-only databases so the value of
     * this flag is ignored if the database is opened read-only.
     *
     * @param enabled True if write-ahead logging should be enabled, false if it
     * should be disabled.
     *
     * @see SQLiteDatabase#enableWriteAheadLogging()
     */
    public void setWriteAheadLoggingEnabled(boolean enabled) {
        synchronized (this) {
            if (mOpenParamsBuilder.isWriteAheadLoggingEnabled() != enabled) {
                if (mDatabase != null && mDatabase.isOpen() && !mDatabase.isReadOnly()) {
                    if (enabled) {
                        mDatabase.enableWriteAheadLogging();
                    } else {
                        mDatabase.disableWriteAheadLogging();
                    }
                }
                mOpenParamsBuilder.setWriteAheadLoggingEnabled(enabled);
            }
        }
    }

如果是直接操作数据库，SQLiteDatabase.java类中也有查询、启用、禁用对应的方法：

public boolean enableWriteAheadLogging() {
        synchronized (mLock) {
            throwIfNotOpenLocked();

            if ((mConfigurationLocked.openFlags & ENABLE_WRITE_AHEAD_LOGGING) != 0) {
                return true;
            }

            if (isReadOnlyLocked()) {
                // WAL doesn't make sense for readonly-databases.
                // TODO: True, but connection pooling does still make sense...
                return false;
            }

            if (mConfigurationLocked.isInMemoryDb()) {
                Log.i(TAG, "can't enable WAL for memory databases.");
                return false;
            }

            // make sure this database has NO attached databases because sqlite's write-ahead-logging
            // doesn't work for databases with attached databases
            if (mHasAttachedDbsLocked) {
                if (Log.isLoggable(TAG, Log.DEBUG)) {
                    Log.d(TAG, "this database: " + mConfigurationLocked.label
                            + " has attached databases. can't  enable WAL.");
                }
                return false;
            }

            mConfigurationLocked.openFlags |= ENABLE_WRITE_AHEAD_LOGGING;
            try {
                mConnectionPoolLocked.reconfigure(mConfigurationLocked);
            } catch (RuntimeException ex) {
                mConfigurationLocked.openFlags &= ~ENABLE_WRITE_AHEAD_LOGGING;
                throw ex;
            }
        }
        return true;
    }

    /**
     * This method disables the features enabled by {@link #enableWriteAheadLogging()}.
     *
     * @throws IllegalStateException if there are transactions in progress at the
     * time this method is called.  WAL mode can only be changed when there are no
     * transactions in progress.
     *
     * @see #enableWriteAheadLogging
     */
    public void disableWriteAheadLogging() {
        synchronized (mLock) {
            throwIfNotOpenLocked();

            if ((mConfigurationLocked.openFlags & ENABLE_WRITE_AHEAD_LOGGING) == 0) {
                return;
            }

            mConfigurationLocked.openFlags &= ~ENABLE_WRITE_AHEAD_LOGGING;
            try {
                mConnectionPoolLocked.reconfigure(mConfigurationLocked);
            } catch (RuntimeException ex) {
                mConfigurationLocked.openFlags |= ENABLE_WRITE_AHEAD_LOGGING;
                throw ex;
            }
        }
    }

    /**
     * Returns true if write-ahead logging has been enabled for this database.
     *
     * @return True if write-ahead logging has been enabled for this database.
     *
     * @see #enableWriteAheadLogging
     * @see #ENABLE_WRITE_AHEAD_LOGGING
     */
    public boolean isWriteAheadLoggingEnabled() {
        synchronized (mLock) {
            throwIfNotOpenLocked();

            return (mConfigurationLocked.openFlags & ENABLE_WRITE_AHEAD_LOGGING) != 0;
        }
    }

参考https://blog.csdn.net/degwei/article/details/9708339