同事甩 10–40% 截图让你升 Go 1.26？先量自己的 GC 占比

Fri, 17 Jul 2026 02:40:00 +0800

值班群里有人贴了 Go 官方的截图：Green Tea 能把 GC 开销降 10–40%。

下一句往往是：那下周就升 1.26，服务应该能快不少。

我会先去看一条监控：GC CPU 在总 CPU 里占多少。没有这个数，截图再漂亮，也不能替你做性能判断。

网上的 10–40% 说的是 GC 自己的 CPU，不是你的服务；先量自己的 GC 占比，再决定要不要为 Green Tea 做 A/B。

先把 10–40% 的分母说清

官方的说法有边界：对 GC 压力很重的真实程序，GC 开销预计可下降约 10–40%。多数程序接近 10%，少数可以接近 40%。这里减少的是垃圾回收本身消耗的 CPU 时间，不是 QPS 一定上涨，也不等于 p99 一定下降。

官方给过一个很实用的换算。如果一个程序有 10% 的 CPU 时间花在 GC，上述改善折算到总 CPU，大致是 1–4%。这个数字不小，但它和“服务快了 40%”是两回事。

你的服务里 GC 若只占 5% 的总 CPU，即便 GC 自身少花 40%，总 CPU 的变化也很有限。反过来，GC 在 CPU 性能分析里长期占着明显一段，或者分配频繁、堆里有大量小的指针对象，Green Tea 才值得认真对比。

这里没有玄学，先看两个数：GC CPU 占比，以及 GC 自身能少花多少。前者很低时，升级后业务指标没有明显变化，本来就是可能出现的结果。

我为什么从 MySQL 投奔 PostgreSQL（以及没有全盘迁移）

Sat, 27 Jun 2026 10:00:00 +0800

上一篇《MySQL 千疮百孔，为什么没人能替代它》发出去之后，收到的留言比我预想的多。大部分不是技术讨论，是一种很微妙的共鸣：我知道它有问题，但我确实不知道该不该换。

这其实才是真正的困惑。

你看完 MySQL 那堆坑——ENUM 排序按定义位置、级联外键不触发 trigger、DDL 隐式提交——你的第一反应不该是"PostgreSQL 好，我要换"。你的第一反应应该是：我当前的项目，这些坑到底有没有咬到我？

如果没咬到，别动。

如果咬到了，也不能说换就换。你得知道换了之后会面临什么全新的疼法。

这篇就是讲这个的。

让我的手指终于放在键盘上的那个瞬间

先说我的触发点。

不是什么宏大的"我们要用更先进的数据库"。是一个凌晨两点半的告警电话。

线上 MySQL 实例的活跃连接数冲破了 500。thread_cache_size 已经调过一轮了，max_connections 也放宽过。但 MySQL 的 thread-per-connection 模型到了这个量级，上下文切换已经压垮了 CPU。新连接进不来，已有查询跑不完，连接池开始拒绝请求。回滚也回不干净，因为 DML 都被堵在了锁等待队列里。

我试过调参数、重启连接池、杀掉慢查询。能做的都做了，只够撑到天亮。

天亮以后我查了接下来半年要上线的功能排期。三个和搜索有关的，两个需要地理查询，还有一个说想在用户标签里做 JSON 过滤。MySQL 的 JSON 你是知道的——每次解析全文，索引靠虚拟列绕路，这不是能用，是将就。

那天中午我开了个会。结论不是"PG 更好"，是"在这个点上，不改的成本已经超过改的成本了"。

但我仍然没有做全盘迁移。这篇就是告诉你我换了什么、没换什么、以及换完之后才知道的学费。

第一块：什么让我决定换

连接数瓶颈——不是 PG 更好，是 PgBouncer 把它变成了可控问题

MySQL 的 thread-per-connection 模型在 <100 连接时没什么感觉。到了 200+，你就开始频繁看 Too many connections。到 500+，运维基本靠祈祷。

这问题技术上不是 MySQL 不能处理高并发——淘宝、Facebook 都在用——但那是建立在应用层做了极其精细的连接管理之上的。大部分团队没有那个资源。