那32毫秒，藏在一个拥塞窗口里

一条再普通不过的 SELECT，在系统空闲一段时间之后，凭空多出约 32 毫秒。

这不是玄学，也不是硬件抖动。ClickHouse 的工程师最终把它追到了一个非常底层的组合：TCP 拥塞窗口被重置后，一串没有做批量化的 Native 协议元数据小包，把刚清零的窗口直接撑爆。修复方式简单得出人意料——把小包攒起来，批量发送。

这个案例连同 iSAM Funds 用 ClickHouse Cloud 搭期权研究平台的经历，放在一起看，恰好说明了当下数据库竞争的真实战场：不在发布会 PPT 上，而在毫秒级尾延迟和 35 倍压缩比里。

“信源说明：本文两个案例分别来自 ClickHouse 官方工程博客（拥塞窗口排查）与 ClickHouse 官网发布的 iSAM Funds 客户案例。文中所有性能数字（32 毫秒、压缩比、摄取速度等）均为厂商侧口径的自述数据，未经第三方独立复核，引用时请注意这一点。

🕵️ 空闲之后的第一条查询，为什么慢了

故事的开头来自一位客户。

他们的现象很典型：服务运行正常，查询正常，唯一的异常是——每当系统空闲一段时间后，第一条简单 SELECT 会额外慢 32 毫秒左右。之后一切恢复如常，直到下一次空闲。

32 毫秒这个数字很有迷惑性。它不够大到像网络故障，又稳定到不像随机抖动。很多团队遇到这种问题，第一反应是调缓存、加预热脚本，把症状糊过去。

但尾延迟的残酷之处在于：P99 上的那 32 毫秒，恰恰是对延迟最敏感的客户最先感知到的部分。对量化基金这类用户来说，每一次研究查询都在和时效赛跑；对在线服务来说，尾延迟直接决定超时重试率和用户体验的下限。

这类『空闲后第一条查询变慢』的问题，在云数据库场景里其实是一个高频病种——弹性环境下的连接管理、网络参数重置、冷启动路径，都是常见病灶。区别只在于，有的团队选择绕过去，有的团队选择挖到底。

ClickHouse 的工程师选择了后者。而挖到底的结论，指向了一个几乎没人会怀疑的地方：TCP 的拥塞控制机制。

🔍 破案：小包、窗口与一次完美的复现

金句先行：性能问题最难的不是修复，而是把假设变成可复现的事实。

排查链条大致是这样的——

拆开讲。TCP 连接在经历空闲或重传超时后，拥塞窗口（cwnd）会被重置。按 RFC 6928 的标准，Linux 默认初始拥塞窗口 IW10——即约 10 个 MSS，在典型以太网 MTU 1500 字节、MSS 约 1460 字节（扣除 TCP/IP 头后）的条件下，初始窗口只有约 14.6 KB。也就是说，窗口重置后的第一个 RTT 内，发送方最多只能把这一万多字节推进网络。

而 Native 协议在查询开始时要传输列级元数据——每个列一块、单包只有几十到几百字节。一条宽表查询涉及数百个列时，这批未批量化的小包数量远超 10 个 MSS 的窗口容量，只好分多个 RTT 逐窗口排空。假设客户端与服务器跨可用区或跨区域，RTT 在 30–40 毫秒量级，多排空一两个窗口，就是 30–40 毫秒的额外延迟——与客户观察到的 32 毫秒在量级上正好吻合。

这里最值得称道的是验证手段：工程师没有靠『改一版上线试试』，而是用 Linux 的 network namespaces 在受控环境里完整复现了这个问题。netns 可以在单机上模拟出带延迟、带带宽限制的独立网络栈，让『拥塞窗口重置 + 小包突发』这个假设变成可重复实验。

复现确认后，修复方案顺势而出：把元数据包做批量化，减少小包数量，让窗口重置后的首波数据不再撑爆拥塞控制。

整个排查过程，可以看作一次教科书级的用户体验旅程——只不过主角是工程师：

一个批次化的改动，换来的是尾延迟曲线上一道清晰的削平。这类修复不会出现在任何版本发布会的 keynote 里，但它会出现在客户的监控大盘和续约决策里。

📊 iSAM Funds：一万倍数据的期权研究平台

如果说 32 毫秒的故事讲的是『快』的细节，那 iSAM Funds 的案例讲的是『大』的工程。

这家量化机构用 ClickHouse Cloud 搭建期权研究平台，核心挑战被称为一个『10,000x 的数据问题』——需要对期权完整历史数据进行研究分析，数据体量相比传统场景膨胀了四个数量级。

效果集中在几个数字上（以下均为 ClickHouse 官方客户案例中的厂商自报数据，口径以该案例文档为准，未注明基准环境与测试条件）：

这些数字背后是两条产业逻辑。

第一，压缩比就是 TCO。 分析型数据库的成本结构里，存储和网络传输占大头。35–50 倍的压缩（若该口径属实），意味着同样的期权历史数据，云存储账单只剩零头，跨节点扫描的网络开销同步缩水。列式存储 + 高压缩编码，从来不是论文里的漂亮指标，而是真金白银。

第二，摄取速度决定数据新鲜度的上限。 单核 100 倍的摄取提速，配合管道简化，意味着从数据到达到可查询的窗口被大幅压缩。对研究型业务来说，『能更快问到最新的问题』本身就是竞争力。

用一张简化的四象限图来看这类技术点在行业里的位置——技术门槛越高、商业价值越大的能力，才是真正的护城河：

注意右上角的『协议层批处理优化』——它看起来只是修 bug，实际上是高门槛、高价值的活儿：做得好不好，直接体现在客户的 P99 曲线上。

💡 毫秒级优化背后的产业逻辑

把两个案例并排看，能提炼出一条被行业反复验证、却总被忽视的判断：数据库的竞争已经进入细节取胜阶段。

用一个冰山模型来看——用户看到的和支撑用户看到的，是两个世界：

水面之下的每一项，都不性感，但每一项都在决定水面之上那几个数字。

行业里私下流传一句话：云数据库厂商的核心秘密武器，往往是一堆没人愿意写进 changelog 的网络和协议层修复。这话或许有夸张成分，但方向没错——当 SQL 引擎和索引结构的差距逐渐拉平，差异化开始沉淀在拥塞窗口、批次策略、编码选择这些『最后一公里』上。

对用户侧的启示同样具体：选型时别只看 benchmark 峰值，要看尾延迟的稳定性、压缩比的真实水位、摄取链路的简洁程度——并且记得问一句：这些数字是谁测的、在什么环境下测的。iSAM Funds 没有为了万倍数据去自建一套复杂的分布式管道，而是选择了一条简化路径——这种克制，本身就是工程判断力。

对厂商侧的启示更直白：32 毫秒的 bug，在 demo 里无感，在量化基金的账单和信任里是真实存在的。慢问题的响应速度，正在成为一种产品能力。

小结

32 毫秒，一个只有约 14.6 KB 的初始拥塞窗口，一次 netns 复现，一个批量化修复；另一边是厂商自报的 35–50 倍压缩、100 倍摄取、一万倍数据。这两个故事共同指向同一件事：数据基础设施的价值，正从『功能有没有』转向『细节扎不扎实』。

可以预见，随着分析负载越来越接近实时、数据规模持续膨胀，协议层优化、受控复现能力、高压缩摄取这些水面之下的工程，会成为数据库厂商新的分水岭。下一次你的空闲首查莫名慢了 32 毫秒——别急着调缓存，先想想那个被撑爆的拥塞窗口。