AI Infra：用 HTTP3 访问可能比原生 MySQL 二进制协议还快

https://planetscale.com/blog/faster-mysql-with-htt
「Faster MySQL with HTTP/3」

一、文章在讲什么？

PlanetScale 做了一套实验性的 HTTP API，通过 HTTP/2、HTTP/3 去访问其 MySQL 兼容数据库，并写了一个 Go 驱动与之对接，然后在多种场景下与传统的 MySQL 协议做了性能对比，重点关注：

• 冷启动连接（connect + SELECT 1）
• 并发小查询
• 中等数据量读写
• 大数据量读写
• 不同网络环境（高延迟 vs 低延迟）

结论：

在很多真实场景下，HTTP/2 / HTTP/3 访问 MySQL 可以比传统 MySQL 协议更快，尤其是高延迟网络和冷启动场景，而且 HTTP/3 在大流量、不稳定网络下还有额外优势。

二、整体架构与实现方式

1. 服务端：HTTP API + MySQL

PlanetScale 在原本的 MySQL 兼容后端前面加了一层 HTTP API：

• 协议栈：基于 gRPC 兼容的 connect-go
• 传输层：支持 HTTP/2 和 HTTP/3

• 编解码：

  • protobuf：结构化序列化
  • Snappy：压缩（客户端可压缩 SQL 或数据包，减少网络传输）

注意：这套 HTTP API 在文章时还是实验性的，未完全公开文档。

2. 客户端：实验性质的 Go 驱动

作者实现了一个 database/sql 兼容的 Go 驱动，和 MySQL 官方/社区驱动对标：

• 一个版本使用 MySQL 原生协议（基线）
• 一个版本使用 HTTP/2（通过标准 Go HTTP client）
• 一个版本使用 HTTP/3（基于 quic-go 实验库）

对开发者而言，这意味着**可以保持使用 database/sql 接口，但底层连接方式通过 HTTP 完成，实现了对应用层的透明替换。

三、关键结果：为什么冷启动会更快？

实验对比了 MySQL 原生协议与 HTTP/2、HTTP/3。在高延迟环境下，HTTP 展现了压倒性的优势。

冷启动连接（Connect + SELECT 1）

• 高延迟（Reno 到 us-west-2）：MySQL 162ms vs HTTP 35ms
• 低延迟（同区域 EC2）：MySQL 11ms vs HTTP 3ms

原因拆解：

• TLS 1.3 + 0-RTT：HTTP/3 允许在握手阶段直接发送业务数据。
• 连接复用：HTTP API 可以通过单一长连接承载多个逻辑数据库对话。

四、HTTP/3 的现实局限与生态问题

存在一些现阶段的限制：

• 库成熟度：

  • quic-go 作为 HTTP/3 / QUIC 的实现仍在完善中，尤其在大 payload、高并发时可能存在性能瓶颈

• 生态与工具链：

  • 主流运维工具、驱动、代理大多围绕 MySQL 协议构建
  • 迁移到 HTTP/3 需要一段时间的生态跟进

五、文章的总体结论

综合各项测试，文章给出的主线结论可以概括为：

1. HTTP API（HTTP/2 / HTTP/3）总体上“很不错”甚至优于原生 MySQL 协议

   • 特别是在「冷启动、多短连接、高延迟网络、不稳定网络」场景下
   • 可以把数据库访问“HTTP 化”，受益于现代 Web 协议栈（TLS 1.3、0-RTT、QUIC、多路复用、通用代理）

2. HTTP/3 是对 HTTP/2 的合理进化，而不是颠覆 MySQL 协议的魔法子弹

   • 在最坏情况下，HTTP/3 至少不会比 HTTP/2 差太多
   • 在最好情况下，HTTP/3 能与 HTTP/2 相当，甚至更好（特别是糟糕网络和大数据量）

3. 冷启动收益最大

   • 利用 TLS 1.3 + 0-RTT、连接复用，把“每次访问都要昂贵握手”的开销降到最低
   • 对 serverless 架构、按请求计费的函数执行模型尤为重要

4. 中等场景下，数据库自身是主要瓶颈

   • 对常规业务查询/写入，差别更多由 SQL / 索引 / 数据库引擎决定
   • HTTP/3 在这些场景的加速空间有限，但不会负优化

5. 大流量和弱网络是 HTTP/3 最具价值的战场

   • 对需要“快速、大量、可靠传输”的场景，HTTP/3 + 压缩 + 多路复用可以给出更稳、更可预测的尾部延迟表现

标签：mysql, ai