TTFB 高，我在加 CPU

有个站 TTFB 一直下不来，我看监控里 CPU 还有余量，就加了核心数和工作进程。结果 TTFB 没动，账单先上去了。

后来才发现，请求根本没在 CPU 上卡着，而是在等数据库的一把锁。那次之后我才学会，先把等待分类，再决定动哪里。

这一段到底包含什么

TTFB 是从请求发出，到收到服务器返回的第一个字节。中间有排队、有处理、有生成响应。

它不等于代码执行时间。请求在进程池里排队算它，等数据库算它，调第三方接口算它，WAF 检查也算它。

排队和处理要分开：排队靠扩容，处理靠优化代码或依赖，方向完全不同。

所以 TTFB 高，只说明「第一个字节来晚了」，没说明晚在哪。

先排除不是后端的情况

有时候 TTFB 高是测量上的错觉。

比如站点做了 301 跳转，工具默认跟随后，把两跳的时间算在一起。再比如前面有 CDN，回源慢也会计入。

有些工具可以选择不跟随跳转，那样看到的是第一跳的 TTFB，更接近链路本身。

先确认状态码和最终地址，别在错误的前提上分析。

用分段缩小范围

用宝塔拨测的网站测速看五段。DNS、TCP、TLS 都正常，只有 TTFB 高，才是后端处理的问题。

如果 TTFB 高的同时下载也慢，偏出口带宽和链路，不要一股脑儿怪代码。

按运营商和地区分组看。所有分组都高，偏后端；只有部分高，偏线路或 CDN 节点。

如果 DNS 段也偏高，先解决解析，否则 TTFB 里混着解析的等待，容易误判。同一个站在不同地区测，TTFB 差一截，也可能是回源路径不同。

后端慢，通常慢在哪

最常见的是等外部依赖：数据库慢查询、缓存未命中、调用第三方接口超时。

其次是资源排队：应用进程数不够、连接池打满、线程锁竞争。连接池打满时，请求都在池子里等，CPU 照样是空的。

还有一种是日志和存储：同步写日志、磁盘 I/O 抖动，都会把响应拖住。

这几种从 CPU 使用率上都看不出来，得看慢日志、连接池状态和磁盘等待。

复测和验证

改完用同一批节点复测，只看 TTFB 这一段，别看总时长。总时长会被下载和网络波动带偏。

连测两三次，确认下降是稳定的。顺便看最慢节点有没有一起改善，只优化平均值容易漏掉局部。记录里带上时间段和节点，TTFB 的单位是毫秒，别和总时长混着看。

TTFB 是结果，不是原因。找到它背后在等什么，才算真的解决。