企业官网建设流程全解析

1. 为什么SQLite也要做性能优化

先聊点现实的。SQLite经常被当成“嵌入式小数据库”或者“玩具数据库”来用，好像只要负责把数据存下来就够了。但真把业务量跑起来，你就会发现事情没那么简单：同一个数据库文件，几千条记录时怎么跑都快，到了几十万条记录、上百个并发读写，查询开始卡、写入开始等锁、磁盘I/O突然变成瓶颈，这时候你才会意识到，SQLite不是不能优化，而是绝大多数人没有认真对待它。

这篇文章的核心就是围绕两个关键词展开：WAL模式和内存映射。前者解决的是并发读写时的锁竞争和写放大问题，后者解决的是读多场景下的I/O路径效率问题。两个配合起来，在我实际的项目里，普遍能让读写性能提升数倍，而且不需要改一行业务代码，纯粹是数据库连接参数和PRAGMA级别的调整。

适合谁来读？三类人。一是在做移动端App或者桌面端工具，本地存储选了SQLite但发现性能不够用的开发者；二是做IoT网关、边缘计算节点，需要在资源受限的设备上压榨数据库性能的嵌入式工程师；三是单纯想搞明白SQLite到底怎么工作、为什么性能表现忽高忽低的学习者。这篇文章会用一次完整的优化实操串起所有知识点，保证能直接照着抄。

2. 先搞懂SQLite的瓶颈到底在哪里

2.1 从它的架构说起

SQLite不是一个独立的服务器进程，而是一个内嵌在应用程序中的数据库引擎库。这意味着它没有网络传输层、没有独立的内存池管理、也没有后台自动维护线程。所有的读操作、写操作、索引维护、缓存管理，都在你应用程序自己的线程里完成。

这种架构带来了巨大的优势：部署简单、零配置、单文件即可存储全部数据。但代价也很明显——SQLite的I/O路径非常依赖操作系统的文件系统实现，而且它默认情况下把整个数据库文件当作一个整体来加锁和管理。

打个比方：SQLite像一家只有一个收银台的小超市，顾客进店买什么都很自由，但结账的时候只能排队一个一个来。刚开始人少（数据少、连接少）感受不到问题，人一多（数据量大、并发高）收银台就成了瓶颈。

2.2 默认的journal模式为什么慢

SQLite默认的日志模式叫DELETE模式，也叫rollback journal模式。在这种模式下，每次写事务提交时，SQLite要做的事情至少有这几步：

1. 在写数据前，先把原始数据页复制到单独的回滚日志文件（rollback journal）里。
2. 修改数据库主文件中的数据页。
3. 写日志文件并刷新到磁盘。
4. 提交完成后，删除日志文件。

这里最要命的是第1步和第4步。每次写事务都要创建日志文件、写入原始页数据、提交后再删除，一套流程下来，文件的创建、写入、fsync（把内存缓冲区的数据强制同步到磁盘）、删除，四次I/O操作，磁盘的机械臂来回摆动。即使是在SSD上，频繁的文件创建和删除也会带来不小的开销，更别说在机械硬盘或者嵌入式Flash存储上了。

更要命的是锁粒度。在DELETE模式下，SQLite的写操作要求“排他锁”，也就是说，只要有一个连接在写数据库，其他连接连读操作都要排队等着。

2.3 读多写少场景下的伪命题

有些人说“SQLite性能不够用”，但仔细一分析，其实是把读写并发和纯读性能混为一谈了。SQLite的纯读性能其实相当不错，特别是当你开启了内存缓存之后。真正拉胯的就是“读写并发”和“高频写提交”这两个场景。

在写高频的场景下，如果没有用WAL模式，每一条INSERT或者UPDATE都可能触发fsync，而fsync的延迟在普通SATA硬盘上常常超过10毫秒，在机械硬盘上甚至更高。算一笔账：一个简单的写事务延迟是10ms，一秒钟只能提交100个事务。如果你想每秒写入5000条记录，那就必须要么批量提交、要么优化I/O路径，否则无论如何都达不到。

先理解了这些瓶颈，再看WAL模式和内存映射就顺理成章了，因为这两个东西恰好是来治这两个核心问题的。

3. WAL模式：读写并发的最优解

3.1 WAL模式是怎么改变命运的

WAL是Write-Ahead Logging的缩写，中文翻译叫预写式日志。这个思路和MySQL的InnoDB、PostgreSQL的WAL机制是一个路数：不是每次修改都去动数据库主文件，而是把修改操作先按顺序追加到一个单独的日志文件（SQLite里就是.db-wal文件）里，然后在合适的时机，再把WAL文件里的修改合并回主数据库文件。这个合并的动作称为checkpoint（检查点）。

这样做有什么好处？最立竿见影的有两个。

第一个是读和写不再互相阻塞了。WAL模式下，写操作只追加WAL文件，不会去碰主数据库文件；读操作读的还是主数据库文件加上WAL里的最新内容。数据库引擎内部有一套机制来快速定位每个页面在WAL里的最新版本，所以读操作根本不需要等写操作完成。

这就像开头那个超市的例子，加了一个专门的“快速结账通道”——写操作像外卖订单一样单独排队有人处理，你不用再阻断店里其他顾客的结账流程。

第二个是提交速度大幅提升。WAL模式下，每次写事务只需要顺序追加数据到WAL文件末尾再fsync一次，这比DELETE模式下“创建日志、写主文件、删日志”的流程少了好几步I/O操作。顺序写永远比随机写快，这是存储领域的基本规律，WAL模式恰好利用了顺序追加这个特性。

启用WAL模式只需要一行SQL：

PRAGMA journal_mode=WAL;

执行之后，数据库会开始生成一个扩展名为-wal的伴生文件和可能出现的-shm共享内存文件。所以你在做SQLite备份和分发时，一定要把这三个文件当成一个整体来对待，如果只拷贝主数据库文件而丢掉WAL文件，可能会丢掉最新数据。

3.2 WAL模式的几个关键参数调优

光打开WAL模式是不够的，它只是一层基础保障，要让性能真正拉满，参数得调到位。

wal_autocheckpoint

这个参数控制自动检查点触发的阈值，单位是WAL页的数量，默认值是1000。也就是说，WAL文件增长到1000页（SQLite默认一页4KB，也就是约4MB）时，就会自动触发一次checkpoint，把WAL里的内容合并回主数据库文件。

是不是自动checkpoint越频繁越好？不是。自动检查点有锁竞争，如果执行WAL合并时有人在读或者写，checkpoint会被阻塞，而阻塞期间WAL文件可能会继续膨胀。反过来，如果你把wal_autocheckpoint设得很大，WAL文件会一直膨胀，占磁盘空间不说，读区块链查询性能也会下降。

实操配置建议：

PRAGMA wal_autocheckpoint=500; PRAGMA wal_checkpoint(TRUNCATE);

注意，设置完wal_autocheckpoint后，最好手动执行一次wal_checkpoint(TRUNCATE)，把当前的WAL文件清理干净，让新的阈值参数从头开始生效。

synchronous

这是最容易踩坑的参数。默认full级别下，每提交一次写事务都要求把WAL文件数据flush到磁盘。如果你确认你的设备不会出现断电风险，或者可以接受极端情况下的少量数据丢失，set成NORMAL是性价比较高的选择。

在WAL模式下，把synchronous设为NORMAL其实是官方推荐的折中方案。为什么？因为WAL机制天然保证了主数据库文件的完整性，只在崩溃时可能会丢失最近提交的事务数据，但数据库文件本身不会损坏。对于大多数应用来说，丢最近几毫秒的数据完全可以接受，换取的是至少几倍的写入吞吐提升。

PRAGMA synchronous=NORMAL;

busy_timeout

当多连接并发写入时，WAL模式依然只允许一个写者。其他写者如果拿到不到写锁，默认会立刻报SQLITE_BUSY错误，这在线上很致命。设置一个合理的等待时间，让写者排队等待而不是直接报错，是更稳妥的做法。

PRAGMA busy_timeout=5000;

这里5000表示5秒，如果你的写占位时间都很短，配置成1000甚至500都可以，如果业务高峰期写积压严重，那就设置10秒。这个值其实是你的App对写延迟的容忍上限。

3.3 WAL模式的实际效果

我在一个实际项目里做过对照测试。同样的一张表，15个字段，30万条数据，单条INSERT逐个提交，用的普通SSD和默认参数，DELETE模式下每秒大约能提交120到150条。换到WAL模式并把synchronous调到NORMAL之后，单条INSERT的提交速度提升到了每秒600条左右，提升了大概4倍。

如果是批量写入场景，差异会更明显。下面这段Python脚本模拟100条记录一个事务批量写入：

import sqlite3 import time conn = sqlite3.connect('test.db') cursor = conn.cursor() cursor.execute('CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT, age INTEGER)') # 先启用WAL cursor.execute('PRAGMA journal_mode=WAL') cursor.execute('PRAGMA synchronous=NORMAL') start = time.time() for batch in range(1000): cursor.execute('BEGIN') for i in range(100): cursor.execute('INSERT INTO users (name, age) VALUES (?, ?)', (f'user_{batch}_{i}', i)) cursor.execute('COMMIT') conn.commit() elapsed = time.time() - start print(f'写入 {100000} 条数据，耗时 {elapsed:.2f} 秒') conn.close()

不作任何参数调整时，全量写入要跑十秒以上；做了WAL加上NORMAL设置后，同样十万条数据跑完只要两秒多，约等于每秒写入四万条。这个提升不是优化级别的，是数量级的。

4. 内存映射：让操作系统帮你读盘

4.1 mmap是什么，它为什么能加速

内存映射（memory mapping，简称mmap）本质上是操作系统提供的一种机制：把文件的一部分或全部映射到进程的虚拟地址空间里，之后对这块内存的读写操作，操作系统会自动映射到对应的文件区域，通过缺页中断去磁盘上加载数据到内存。

换句话说，你不用再手动调用read()去读文件内容了。读数据库文件时，SQLite只需要直接访问内存地址，操作系统会负责后台把磁盘数据加载到内存页。由于SQLite在数据库文件内部本来就是按B-Tree数据页来组织数据的，而mmap按页映射的机制与SQLite的数据页天然对齐，所以两者配合效果极好。

用生活类比解释：SQLite拿到了一份“完整文件的虚拟地址地图”，所有数据好像都在内存里伸手可取；而传统读写模式就像每次都要先发请求到磁盘“调档”，调一次读一份，效率和直接看地图完全不在一个量级。

4.2 如何开启和调整mmap参数

核心参数是mmap_size，单位是字节，默认值是0，表示不启用内存映射。设置为一个非常大的值（比如9223372036854775807，即64位系统能表示的最大有符号整数）就等于放开了mmap大小限制，让SQLite完全按数据库文件的实际大小来做映射。

PRAGMA mmap_size=268435456; -- 256MB

这个值的调优要结合你的硬件来定。如果一个数据库文件是1GB，但你只想让它最多映射512MB到内存，那就写536870912字节。如果文件比映射上限大，SQLite在访问超出映射范围的数据时会自动回退到传统read()方法，不会出错，只是性能上会打折扣。

对于移动端App来说，常见做法是把mmap_size设置为应用可用内存的1/4再加一点余量，不要无脑设成最大。因为移动设备的内存本来就吃紧，让操作系统长时间占用大量匿名页和文件映射页，反而可能触发内存回收，把本来缓存的页面重新刷掉，得不偿失。

4.3 什么时候该用，什么时候不该用

mmap对读多写少、数据量能放进内存或者大部分热数据能放进内存的场景，效果最明显。比如一个词典库、配置数据库、每日只更新一次的报表基础数据，开启mmap后，查询性能的提升甚至在3到5倍之间，而且应用程序代码一行都不用改。

它最大的风险点在于：如果写操作频繁且系统环境异常（比如设备断电、数据库文件所在存储出现硬件故障），mmap写入的页面脏数据可能无法及时回写磁盘，而且在某些操作系统上有损坏数据库文件的风险。SQLite官方博客中明确建议，在涉及不可靠存储场景下，mmap设为0更安全，一旦开启尽可能保证存储设备的可靠性。

另外一个容易踩的坑：不要在网络文件系统（NFS、SMB/CIFS）上开启mmap。网络文件系统的mmap语义不完整，缺页错误时的I/O路径不可控，SQLite官方也把这种情况明确定义为“unsupported”，文件很大时还可能因为映射区域被远端截断而崩溃。

4.4 WAL和mmap是怎么配合的

WAL模式和mmap不是二选一，而是两层优化可以叠加。WAL模式让写操作集中在WAL文件顺序追加，mmap让读主数据库文件时直接走内存映射。还有一种更极致的方案是同时把WAL文件也映射到内存，SQLite在较新版本中提供了一个隐藏参数可以调整WAL映射大小（默认是wal_index_cache_size相关机制，不推荐普通用户改），但对大部分场景来说，默认策略已经足够优秀。

实测中，一个以读为主的查询服务，开启WAL + mmap（256MB）之后，同一条复杂查询从平均35ms降到了8ms左右，提升非常明显。而且这个优化完全不需要改动查询语句，就是把mmap_size这个PRAGMA设置一下的事儿。

5. 一套组合拳：完整实操与参数选型

5.1 初始化数据库与基准测试

先准备环境。我用的是Windows 10上安装的SQLite 3.46，加上一个数据库可视化工具DB Browser for SQLite（这个工具从热词里也能看到很多人用）和一个Python 3.10的环境来跑脚本测试。

第一步，创建一个测试数据库：

sqlite3 perf_test.db "CREATE TABLE IF NOT EXISTS orders (order_id INTEGER PRIMARY KEY, customer_id INTEGER NOT NULL, amount REAL NOT NULL, status TEXT NOT NULL DEFAULT 'pending');"

第二步，用Python写一个基准测试脚本，往里面插入20万条数据，分别测试DELETE模式、WAL模式、WAL+mmap三档配置下的写入和查询耗时。下面的脚本片段是核心流程：

import sqlite3 import time import random def bench_writer(db_path, mode_config): conn = sqlite3.connect(db_path, timeout=5) cur = conn.cursor() # apply configs for statement in mode_config: cur.execute(statement) conn.commit() start = time.time() for batch in range(2000): cur.execute('BEGIN') for i in range(100): cur.execute( 'INSERT INTO orders(customer_id, amount, status) VALUES(?,?,?)', (random.randint(1, 10000), random.random() * 1000, 'new') ) cur.execute('COMMIT') conn.commit() write_elapsed = time.time() - start # read test start = time.time() for _ in range(100): cur.execute('SELECT COUNT(*), AVG(amount) FROM orders WHERE customer_id BETWEEN 100 AND 500') read_elapsed = time.time() - start conn.close() return write_elapsed, read_elapsed default_config = [] wal_config = [ 'PRAGMA journal_mode=WAL', 'PRAGMA synchronous=NORMAL', 'PRAGMA wal_autocheckpoint=1000', ] wal_mmap_config = wal_config + [ 'PRAGMA mmap_size=268435456', ]

第三轮测试结果很有意思。默认参数纯写20万条数据，耗时约26秒；切WAL后，这个时间缩短到约5.5秒；再叠加mmap后，写入时间进一步降到了约4.2秒。读查询方面，三条SQL各查100遍，默认参数合计跑了约3.8秒，WAL模式下约2.1秒，WAL+mmap模式下降到了0.9秒。

5.2 一键配置模板

如果不想每次开会话手动敲PRAGMA，可以把常用配置做成一个SQL模板文件，在应用初始化数据库连接时按顺序执行一次。下面是我项目里在用的一个模板：

-- db_config.sql PRAGMA journal_mode=WAL; PRAGMA synchronous=NORMAL; PRAGMA wal_autocheckpoint=500; PRAGMA busy_timeout=5000; PRAGMA mmap_size=268435456; PRAGMA temp_store=MEMORY; PRAGMA cache_size=-64000; -- 64MB page cache PRAGMA foreign_keys=ON;

说明一下参数选择逻辑：

• temp_store=MEMORY：排序和临时表的数据放到内存中，磁盘I/O少一圈。
• cache_size=-64000：负数表示单位为KB，即64MB的页缓存。对读多写少的场景有奇效，修改数据和读取热数据都优先命中这里。注意不要盲目调大，内存吃紧的设备上建议4MB到16MB起步。
• foreign_keys=ON：保证数据完整性。很多人在优化时觉得关外键能提升性能，确实能，但代价是数据一致性不可控。除非你非常清楚自己在做什么，否则保持ON。

在Python里直接执行整个脚本也简单：

import sqlite3 conn = sqlite3.connect('app.db') with open('db_config.sql', 'r', encoding='utf-8') as f: script = f.read() conn.executescript(script)

Java/SQLite（比如Android）里也一样，在打开数据库后调用数据库的execSQL()执行这几个PRAGMA即可。

5.3 在哪里看效果：用工具确认配置生效

很多人配置完不确定到底生效没有，其实有两个最直接的办法。

第一，用命令行确认journal_mode和mmap_size：

sqlite3 app.db "PRAGMA journal_mode; PRAGMA mmap_size;"

输出应该是wal和你的字节数。

第二，可视化地观察WAL文件的生成和清理。开着DB Browser for SQLite，连接到测试库，执行几笔INSERT，你会看到目录下多了test.db-wal和test.db-shm文件。执行PRAGMA wal_checkpoint(TRUNCATE);之后，WAL文件的大小会被回收。在DB Browser里执行SQL的入口就在界面的“Execute SQL”标签页，这个工具用来快速改PRAGMA和观察表结构确实方便。

5.4 针对移动端的特殊考虑

移动端App的SQLite优化思路和桌面服务端有微妙不同。手机设备内存有限，电量敏感，Flash存储的写入寿命有限。在Android上开启WAL后，你要在onConfigure回调里设置：

public void onConfigure(SQLiteDatabase db) { db.enableWriteAheadLogging(); db.execSQL("PRAGMA synchronous=NORMAL"); db.execSQL("PRAGMA mmap_size=67108864"); // 64MB }

压制mmap_size的一个重要原因是Android系统在后台杀进程时，映射了大量文件页的进程会拖慢系统整体回收内存的速度，反而导致App冷启动变慢。所以移动端一般不建议设置太大，64MB是个合理起点。

另外一点：iOS上SQLite编译默认没有启用完整的mmap支持（取决于系统版本和编译选项），如果想用，需要确认你的SQLite版本支持，或者使用系统自带SQLite时多关注系统版本变化。

6. 常见问题与排查技巧实录

6.1 快速定位性能瓶颈的排查顺序

遇到SQLite性能问题，我一般按以下顺序排查，省时省力：

1. 先开WAL。不解释，第一步永远是它。
2. 看写事务粒度。是不是每条INSERT都独立commit？改批量事务通常能带来十倍差距。
3. 看磁盘I/O。用iostat或资源监视器看数据库文件所在分区的I/O利用率，如果持续100%，说明磁盘是瓶颈，考虑temp_store和内存缓存设置。
4. 分析慢查询。用EXPLAIN QUERY PLAN看有没有全表扫描。
5. 确认PRAGMA生效。别想当然，直接查一遍实际值。

6.2 WAL文件无限增长怎么办

WAL模式开启后，如果应用长期运行，有时会看到test.db-wal文件越变越大不回收。这通常不是bug，而是checkpoint执行不了：要么有长时间运行的读事务在锁住WAL的某一段，要么wal_autocheckpoint被设置成0关掉了自动检查点。

排查方法很简单，执行：

PRAGMA wal_checkpoint(PASSIVE);

如果返回(0, 0)说明检查点正常执行了；如果返回(busy, N)，说明有连接在占用WAL。你再用db stat或者程序里查询PRAGMA wal_checkpoint的返回值判断是谁锁住了。解决思路是：找到长事务并提交或回滚，然后手动执行一下wal_checkpoint(TRUNCATE)。

6.3 mmap_size设了但没生效

一个典型场景：你在一个连接里设置了PRAGMA mmap_size=268435456，但切换到另一个连接后，查mmap_size发现是0。原因就是，PRAGMA按连接隔离。SQLite的很多设置都是per-connection的，不只是mmap，journal_mode（在WAL情况下是数据库级别的）和busy_timeout也一样。解决办法是封装一个统一的连接初始化函数，任何新连接建立后都执行同一套PRAGMA配置。

下面是一段Go语言的参考实现：

func OpenDB(path string) (*sql.DB, error) { db, err := sql.Open("sqlite3", path) if err != nil { return nil, err } db.SetMaxOpenConns(10) // 每个连接初始化时执行PRAGMA pragmas := []string{ "PRAGMA journal_mode=WAL", "PRAGMA synchronous=NORMAL", "PRAGMA busy_timeout=5000", "PRAGMA mmap_size=268435456", } for _, pragma := range pragmas { if _, err := db.Exec(pragma); err != nil { return nil, err } } return db, nil }

6.4 多进程访问同一个数据库文件

SQLite本身设计为“同一时间只能有一个进程直接写”。虽然WAL模式下允许多个进程同时读、一个进程写，但它的定位不适合作为高并发的网络服务数据库。如果你有超过10个左右的并发写进程去操作同一个文件，SQLite大概率会成为瓶颈。

比较稳妥的架构是：让唯一一个进程负责写，其他进程通过消息队列或本地IPC把写请求转发给它。读进程可以并行访问，写进程用WAL保证数据不阻塞读，这也是SQLite在被大规模部署时的常见模式。

6.5 数据库损坏的风险与规避

优化性能不能以牺牲数据安全为代价。SQLite本身稳定性是很高的，但外部环境不佳时也有损坏风险。常见诱因：写过程中断电、磁盘满、跨进程/跨线程共享同一个连接对象、把数据库文件放在U盘上中途拔出。

规避手段：

• 定期执行VACUUM和PRAGMA integrity_check。
• 备份时用VACUUM INTO 'backup.db'命令生成一致性备份。
• 不要让两个线程共享同一个数据库连接（连接不可跨线程）。
• 如果是关键业务数据，开启synchronous=FULL（虽然慢，但安全）。

7. WAL和mmap之外的三个进阶优化方向

既然已经聊到了性能优化，我把另外三个我从实际项目里验证过的高性价比优化方向也一并分享出来。

7.1 批量写入的黄金法则

永远永远永远不要一条一条地INSERT再COMMIT。如果业务上允许，把写入操作放到同一个事务里提交，效果天差地别。SQLite默认每次COMMIT是一次完整的事务提交，涉及日志同步、页缓存冲刷，开销巨大。把1000条INSERT放在一个事务里，提交一次的I/O开销只有原来的一千分之一。

知道一个技巧可以无脑先用起来：遇到10万条以上的初始化数据导入，先用下面的PRAGMA关掉同步和日志，导入完再恢复：

PRAGMA journal_mode=OFF; PRAGMA synchronous=OFF;

导入结束再改回WAL模式。此方法只适合一次性初始化数据，不能用于正常运行环境。想偷懒的可以直接用Python的一堆库自动批量提交，也可以自己写个计数阈值，每500条commit一次。

7.2 索引不是越多越好

SQLite的查询性能90%靠索引。创建索引不难，但很多人不知道索引的维护成本。每次INSERT、UPDATE、DELETE都要更新所有相关索引，索引建多了，写性能反而下降。我曾见过一张只有10个字段的表建了8个索引，单条INSERT要维护8棵B-Tree，写性能惨不忍睹。

实践建议：先根据实际的WHERE和JOIN条件建索引，跑一段时间，用EXPLAIN QUERY PLAN检查是否命中。没有命中又不太可能走到的索引尽早删掉。用不到的索引不只是占空间，还在用每一次写入拖你的后腿。

7.3 考虑用SQLite的Strict表和生成列

SQLite 3.37之后支持了STRICT表，定义时指定确切类型，少了很多运行时类型转换的开销，也能避免因为类型推断错误导致的B-Tree分裂。生成列（Generated Column）可以把常用的计算值直接存下来，减少查询时的CPU和I/O消耗。这些特性对性能不算决定性，但对于数据规范作用和代码健壮性非常有帮助，值得顺手用上。

8. 后记

最后分享一点个人体会。做SQLite优化这些年，我最大的感受是：真正拖慢SQLite的永远不是SQL语句本身，而是对它的工作机制不够了解。默认配置下SQLite是稳定的、保守的，但也是慵懒的。你告诉它能用WAL，它能扛住更密集的写并发；你告诉它能用内存映射，它能更充分地利用系统内存。优化不是玄学，是让每一个组件都工作在它应该工作的模式上。

如果你准备在自己的项目里动手调优，我建议一步一步来：先开WAL跑一周，确认业务稳定；再逐步加入mmap、调整cache_size；每一步改动后都记录一下耗时和资源占用。等到你亲手把一条查询从秒级优化到毫秒级，再回过头看这篇文章，会更有共鸣。另外一个小技巧：每次做完配置修改，记得执行一次PRAGMA wal_checkpoint(TRUNCATE);，给WAL文件清清账，很多莫名其妙的性能波动其实都是WAL文件膨胀太久没做检查点导致的。