如果你还没有承受过高并发的毒打，或者接手了一份充满时代印记的古董代码，那么相信本文会给你指出一条踏向加班的不归路。当然，如果你是在操刀一个全新的项目，将本文的规则枷锁套在身上前行，你会走得更慢，但是你能走得更远。所谓的性能问题，本质上大多源于你对手里的东西了解得还不够透彻。偏偏现代高级编程语言为了提高开发效率，用层层抽象屏蔽了大量底层细节。即使不了解这些内容，你也能写出正常运行的业务代码。哪怕是比 Go 更贴近底层的 C 语言，也通过抽象屏蔽了许多硬件细节，例如 CPU 乱序
很多人从 MySQL 切到 PostgreSQL，第一反应是：语法差不多，SELECT、JOIN、索引也差不多，应该很快就能上手。然后某天他打开 PostgreSQL 的类型文档，看见了数组、范围、多范围、复合类型、域、inet、tsvector 和一串几何类型，感觉像误入了数据库的后厨。这些东西到底有什么用？难道只是 PostgreSQL 把「一列只能放一个值」这条规矩也给折腾没了？先把标题里的话说严谨一点：下面有些类型是 MySQL 没有对应物，有些是 PostgreSQ
很多人第一次接触 PostgreSQL WAL，会把它记成一句话：PostgreSQL 的 WAL 就是 MySQL 的 binlog。这句话很好理解，可惜不是一个正确的说法。要真正理解 WAL，不能从文件名、参数或复制命令开始。应该先问一个更朴素的问题：一笔事务已经向客户端返回 COMMIT 成功，但它修改过的数据页还没有写入磁盘；此时突然断电，数据库凭什么保证这笔数据不会消失？WAL 的原始目的就是回答这个问题。流复制、持续归档、PITR 和逻辑复制，都是从这条可靠的变更
sync.Mutex 看起来只有两个方法：Lock 和 Unlock。它的零值可以直接用，结构体也只有一个状态字段和一个信号量字段，于是很多人会把它当成一颗无害的螺丝：需要保护数据时拧上，结束时拧下。真正的故事要长得多。一次没有竞争的 Lock，可能只是对一个 32 位整数做 CAS；一次有竞争的 Lock，会先在 CPU 上短暂自旋，再进入 Go runtime 的信号量队列，必要时让 goroutine 休眠、唤醒并发生调度。这个状态还要在缓存一致性协议、编译器重排、Go
把 Dragonfly 说成「多线程版 Redis」，就像把 PostgreSQL 说成「支持 SQL 的文件系统」：不能算完全错误，但几乎解释不了任何工程现象。Redis 的核心优势并不只是快，而是把复杂的数据结构、事务语义和网络并发压进一条可预测的串行执行流。十几年里，大量客户端、运维工具、故障处理流程和业务假设都围绕这条执行流生长。Dragonfly 则从另一个前提出发：现代云服务器有几十个 CPU 核、数百 GB 内存和高速网卡，如果命令最终仍在一个主线程上排队，那么
