Time to First Byte（简称TTFB）指的是从客户端发出请求到收到服务器返回的第一个字节之间的时间。很多团队习惯把优化重点放在前端资源加载、CDN缓存上，却忽略了数据库查询往往才是TTFB链条中最不可控的一段。SQLite作为嵌入式数据库，天然省去了网络往返开销，但如果不理解它的事务模型和锁机制，反而会在这条链路上踩出不少坑。这篇文章结合一个实际的Web项目，聊聊如何围绕SQLite把首字节时间稳定压在毫秒级。
先搞清楚：SQLite为什么会拖慢首字节
在一个典型的Web请求里，TTFB大致由几段组成：网络往返、服务端处理、数据库等待、响应首包。对于直接读取SQLite文件的应用，数据库等待这一段主要包含四类开销：打开数据库与连接初始化、SQL解析与查询计划生成、锁竞争等待、磁盘IO。其中最容易被忽视的是锁竞争。
SQLite默认运行在journal模式下，写入时会对整个数据库文件加锁。如果页面的首个查询碰巧撞上一个正在进行的写事务，读操作就会被阻塞，哪怕你只是想读几行数据。这种阻塞在高并发场景下会直接体现在TTFB的P95、P99指标上——平均值看起来还行，但尾部延迟毛刺严重。用户感知到的“页面偶尔很慢”，十有八九就是这种锁等待造成的。
另一个常见问题是连接初始化开销。SQLite虽然不需要建立TCP连接，但每次打开数据库、执行PRAGMA设置、准备语句都有成本。如果每次请求都重新打开文件、重新prepare语句，TTFB里就会白白多出几毫秒甚至几十毫秒。下面的代码演示了一个典型的反面教材：
import sqlite3
def handle_request(user_id):
# 每次请求都打开连接，性能开销大
conn = sqlite3.connect("app.db")
cursor = conn.cursor()
cursor.execute("SELECT name, avatar FROM users WHERE id = ?", (user_id,))
row = cursor.fetchone()
conn.close()
return row这段代码功能上没问题，但每次请求都要完成打开文件、解析SQL、生成查询计划这几步。正确做法是把连接和预编译语句缓存起来，做到一次准备、多次执行，这部分优化通常能带来10%到30%的首字节提升。
WAL模式：降低锁竞争的第一步
如果只做一项优化，那就开启WAL（Write-Ahead Logging）模式。journal模式下读写互斥，而WAL模式下读和写可以真正并行：写操作追加到单独的WAL文件中，读操作仍然读主数据库文件，互不阻塞。这对于首字节时间的意义在于，页面渲染所需的第一个读查询几乎不会再被写事务卡住。
开启方式非常简单，注意要在没有活动事务时执行：
-- 开启WAL模式，只需执行一次，设置持久化保存在数据库文件里 PRAGMA journal_mode = WAL; -- 建议同时开启正常同步级别，兼顾性能与安全 PRAGMA synchronous = NORMAL; -- 合理设置缓存大小，减少磁盘读取 PRAGMA cache_size = -8000;
journal_mode = WAL是持久化设置，写进数据库文件头部，重启后依然生效。而synchronous和cache_size是连接级设置，每个新连接都要重新执行。所以在代码里应该把这些PRAGMA放到连接初始化函数中统一处理。Python的示例如下：
import sqlite3
def create_connection(path):
conn = sqlite3.connect(path, check_same_thread=False)
conn.execute("PRAGMA journal_mode = WAL")
conn.execute("PRAGMA synchronous = NORMAL")
conn.execute("PRAGMA busy_timeout = 5000")
conn.execute("PRAGMA cache_size = -8000")
return connbusy_timeout也值得单独说一下。它定义了遇到锁冲突时最多等待多少毫秒。设置一个合理值可以避免直接抛出database is locked错误，但也不能设得过大，否则极端情况下请求会长时间挂起，TTFB反而恶化。一般建议3000到5000毫秒。
需要注意的是，WAL模式在多进程访问同一个数据库文件时同样有效，这也是很多托管环境下（比如无法跑独立数据库进程的云函数环境）仍然选择SQLite的原因。不过WAL文件会持续增长，需要依赖checkpoint机制回收。默认的自动checkpoint通常够用，但写入密集的应用可以定期手动执行PRAGMA wal_checkpoint(TRUNCATE)，防止WAL文件膨胀影响读性能。
查询层优化：让第一个字节更快到达
连接和存储模式解决的是“等待”问题，查询层优化解决的是“执行”问题。第一件事是让每个查询都用上索引。SQLite提供了非常直观的执行计划分析工具，用EXPLAIN QUERY PLAN就能看到查询是否走索引：
EXPLAIN QUERY PLAN SELECT * FROM orders WHERE user_id = 42 AND status = 'paid'; -- 如果输出包含 SCAN TABLE orders，说明全表扫描，需要建索引 CREATE INDEX idx_orders_user_status ON orders(user_id, status);
复合索引的字段顺序很关键。上面的查询条件同时涉及user_id和status，索引应该把等值条件中区分度高的字段放前面。建好索引后再跑一次EXPLAIN QUERY PLAN，看到SEARCH TABLE ... USING INDEX就说明索引生效了。单表查询从全表扫描变成索引查找，在十万行级别的表上通常能把查询时间从几十毫秒降到零点几毫秒。
第二件事是预编译语句。SQLite的SQL执行分为解析、规划、绑定参数、执行四个阶段，前两个阶段的结果完全可以复用。以Go语言为例，标准库database/sql自带语句缓存：
db, _ := sql.Open("sqlite3", "app.db?_journal_mode=WAL&_busy_timeout=5000")
db.SetMaxOpenConns(1) // 写连接数设为1，避免写锁竞争
stmt, _ := db.Prepare("SELECT name, avatar FROM users WHERE id = ?")
defer stmt.Close()
row := stmt.QueryRow(42)第三件事是审视页面首屏真正需要的数据。很多TTFB问题的根源不是数据库慢，而是接口贪心——首页查询一次拉了几十张表的关联数据。把首屏必需字段和次要数据拆开，首字节只返回渲染第一屏所需的最小数据集，其余用延迟加载补充，这往往比任何数据库调优都更有效。
监控与验证：用数据说话
优化做完不代表结束，必须建立可量化的验证手段。最直接的方法是记录每个请求的数据库耗时，重点关注P95和P99而不是平均值。可以用一个简单的中间件在请求开始和返回首字节时打点：
import time
def timing_middleware(handler):
def wrapped(request):
start = time.perf_counter()
response = handler(request)
ttfb = (time.perf_counter() - start) * 1000
print(f"TTFB: {ttfb:.2f}ms")
return response
return wrapped压测时建议用真实数据规模，构造至少百万行的表再跑并发，否则测出来的数据毫无参考价值。观察优化前后的对比时，重点看三个指标：平均TTFB、P99 TTFB、锁等待次数。WAL模式的效果通常最直观地体现在P99上——开启后尾部毛刺会明显减少。
另外别忘了利用sqlite3_status和EXPLAIN输出做深入分析，也可以在测试环境临时开启PRAGMA profile相关的调试开关，定位具体的慢语句。把慢于50毫秒的查询自动记录到日志里，形成一份持续更新的慢查询清单，是长期保持首字节性能的基本功。
总的来说，SQLite在TTFB这件事上的表现被严重低估了。它没有网络往返，没有独立的连接握手，只要把WAL模式打开、索引建对、语句复用做好、首屏数据做减法，毫秒级首字节完全是可以稳定达成的目标。关键在于建立监控闭环，让每一次优化都有数据支撑，而不是凭感觉调整。