Cloudflare采用Go与sqlc及PostgreSQL构建了一套零ORM方案。这套方案有效避开了传统ORM（如GORM）常见的N+1查询和运行时反射开销，在性能测试中达到了85K QPS（对比GORM的42K QPS），并将p99延迟从3.8毫秒降至1.2毫秒。我们来详细拆解其设计逻辑、迁移细节以及适用场景。
你以为省事，其实在赊账
使用GORM这类ORM连接数据库，感觉像是请了个“代购管家”。你对他说“帮我把这个用户的所有订单和商品信息取出来”，他答应得很好，回头却可能悄悄跑了N+1趟仓库。账面上你只写了几行简洁的代码，但数据库那边已经在默默执行数十条查询。
你不用关心细节，但性能的账单最终由你来支付。
大多数Go项目接入数据库时，第一反应是选择GORM，很少有人会考虑sqlc这条路。理由很充分：GORM文档丰富、社区庞大、复制代码快。这本身没问题，直到流量增长到某个临界点。
除了N+1查询，GORM还有一个不那么显眼却影响深远的麻烦：运行时反射。每次请求进来，GORM都需要动态地检查你的结构体标签、字段类型和关联关系。在10K RPS（每秒请求数）时，这点开销或许还能承受；但当请求量攀升至100K RPS，这个“运行时检查”就会变成压在p99延迟上的一块砖，随之而来的GC压力和内存膨胀将愈发明显。
Cloudflare审视了这条路，最终选择了相反的方向——拥抱sqlc。
sqlc的逻辑：SQL直接编译成Go代码
sqlc的核心思路非常直接：你写SQL，它为你生成Go代码。
它直接将 .sql 文件编译成类型安全的Go函数和结构体，这是一个真正的编译期代码生成过程。运行 sqlc generate 后，代码就生成了，运行时没有任何反射开销，没有中间映射层，直接调用底层的Postgres驱动。
其工作流程如下：
1. 编写SQL文件（例如 queries.sql）
2. 运行 `sqlc generate` → 生成 types.go + queries.go
3. 在业务代码中直接调用生成的函数，IDE有自动补全
4. 编译期即可捕获SQL与Go代码类型不匹配的问题，无需等到生产环境报警
说个具体场景：当你修改了数据库字段的类型，重新运行 sqlc generate 后，再执行 go build ——编译器会直接报错，明确指出哪一行代码存在类型错误。你不需要等待真实的请求打到生产环境才发现数据映射失败。
这就像是出发前就核对好了地图，而不是开到路口才发现道路封闭。
数字说话：85K vs 42K QPS
以下是Cloudflare在10K并发下的实测数据对比：
| 方案 |
QPS |
p99延迟 |
内存占用 |
| Go + sqlc + pgx |
85,000 |
1.2ms |
180MB |
| Go + GORM |
42,000 |
3.8ms |
1.2GB |
| Go + Ent |
38,000 |
4.2ms |
— |
可以看到，吞吐量几乎翻倍，p99延迟从3.8毫秒降至1.2毫秒，内存占用更是从1.2GB大幅缩减至180MB。
内存占用项的差距尤其值得玩味。GORM在高并发下依赖反射机制运作，内存会持续累积，垃圾回收（GC）的频率也随之增加，进而拖慢p99延迟——这是一个恶性循环。而sqlc没有运行时反射，内存占用基本稳定在180MB左右，波动很小。
Cloudflare的生产搭配
Cloudflare将技术栈组合如下：
Go + sqlc + Postgres 生产技术栈
├── sqlc（queries.sql → 编译生成 queries.go）
├── pgx（原生驱动 + 连接池管理）
├── Zerolog（结构化日志）
└── Prometheus（查询延迟 histogram 指标）
Cloudflare的工程师用“刻意无聊”（intentionally boring）来形容这套方案。SQL文件存放在版本控制中，先执行数据库迁移（migration），然后运行sqlc重新生成代码，最后部署。这里没有隐式的查询计划器，没有自动生成的JOIN操作，出现问题直接查看 .sql 文件即可，无需反向推导ORM背后到底执行了什么。
由于生成的代码就是普通的Go函数，因此每条查询都能方便地挂上Prometheus监控指标。你想在哪里添加埋点，一目了然。相比之下，为ORM操作添加监控往往需要绕好几个弯才能弄清楚它实际执行了哪些SQL语句。
sqlc的零停机迁移：双读模式
Schema（模式）升级是ORM最容易翻车的地方。“自动同步schema”听起来很便利，但在生产环境中，这几乎等同于在高速公路行驶时更换轮胎。
sqlc的迁移流程是一系列明确的步骤，不依赖任何“魔法”：
1. 编写新的 migration 文件（增加字段或修改类型）
2. 运行 sqlc generate（新的查询方法自动生成，旧方法保留）
3. 双读期：新旧两套查询同时在线，分批切换流量
4. 流量全部切换到新方法后，删除旧查询文件，重新生成代码
因为每条查询都有严格的类型检查，双读双写的切换在编译期就能验证是否正确。整个过程无需停机，更不必在凌晨三点紧盯迁移脚本，提心吊胆。
什么时候值得从GORM换到sqlc
当然，sqlc并非没有代价。它要求你真正动手编写SQL，不能依赖ORM自动生成查询。如果团队对SQL不熟悉，迁移成本会比预想中高。
适合采用sqlc的场景：
- 查询逻辑复杂，需要使用窗口函数、公共表表达式（CTE）或PostgreSQL特有的JSONB操作。
- 服务对延迟敏感，p99延迟已经开始影响用户体验。
- 希望将数据库层纳入严格的类型系统管控，减少运行时意外。
- 团队已经在手写原生SQL，只是缺少一层类型安全检查。
暂时不建议更换的场景：
- 项目尚处于原型期，数据模型（schema）天天在变化。
- 团队SQL水平参差不齐，需要ORM充当保护层和抽象层。
- 业务逻辑本身不复杂，GORM运行良好，p99延迟也无异常。
- 查询量不大，ORM带来的那点开销完全在可接受范围内。
一个务实的做法是：从最热门的接口开始，将其对应的查询迁移到sqlc，让两套代码共存一段时间。如果性能指标表现良好，再逐步扩大迁移范围。一次性进行全量迁移风险过高，不值得尝试。
本质：别让工具替你隐藏SQL
Cloudflare这套方案背后的逻辑其实很简单：SQL是你与数据库之间的“合同”，这份合同应该清晰明了，而不是交给ORM去自动生成一份你无法完全理解的版本。
sqlc在这条路上走得很彻底。它的定位不是“更好的ORM”，而是提供了一个截然不同的选择——代价是你需要真正懂SQL，好处是你的代码与数据库之间没有黑盒，出了问题直接查看SQL文件就够了。
如果你的服务已经在处理高并发流量，并且p99延迟开始出现抖动，不妨先将最热门的几条查询拿出来，用sqlc重写，对比一下前后的延迟数据。85K QPS还是42K QPS，那张性能对比表就摆在那里，如何判断，一目了然。
欢迎在云栈社区分享你关于Go数据库方案的选择与实践经验。
常见问题
Q: sqlc 怎么安装和配置？
使用 go install github.com/sqlc-dev/sqlc/cmd/sqlc@latest 命令安装。随后在项目根目录创建 sqlc.yaml 配置文件，在其中指定数据库类型（如postgresql）、schema文件路径和SQL查询文件路径。配置完成后运行 sqlc generate，Go代码便会自动生成到指定目录。官方文档位于 docs.sqlc.dev，按照指引通常能在15分钟内跑通第一个示例。
Q: sqlc 能完全替代 GORM 吗？
不能完全替代。sqlc专注于SQL查询的代码生成，不处理数据库迁移（migration），需要配合如golang-migrate或Atlas等工具使用。而GORM提供的模型关联自动管理、软删除等高级功能，在sqlc中都需要通过手写SQL来实现。两者解决的是不同层面的问题。
Q: sqlc 支持哪些数据库？
主要支持 PostgreSQL、MySQL 和 SQLite。其中对PostgreSQL的支持最为完整，涵盖了JSONB、数组类型、自定义域类型等Postgres特有功能。如果你已经在使用Postgres，sqlc基本可以开箱即用。
Q: 已有 GORM 项目怎么迁移？
推荐采用渐进式迁移策略：首先找出慢查询或复杂查询，单独用sqlc重写，让新旧两套代码共存一段时间。确认无误、性能达标后再逐步扩大迁移范围。不推荐一次性进行全量迁移，生产环境风险过高，且改动范围过大时问题难以定位。
发表于 昨天 04:07
|
查看: 3|
回复: 0
