技术文章 Phil Eaton - databases
本篇文章是“用 Go 从零写 SQL 数据库”系列的第一篇，目标是实现支持基本的 CREATE、INSERT、SELECT 命令和交互式 REPL 的最小数据库。作者从词法分析入手，设计 lexer 将输入转换为 token，依据 PostgreSQL 规则处理数字、字符串和标识符，并用 longestMatch 解决关键词前缀冲突；然后定义 AST 模型与递归下降解析器，分别解析三种语句。最后实现内存后端，用 map 存储表，以二进制表示 INT、字节串表示 TEXT，完成建表、插入和查询功能。文章给出完整代码与运行示例，并附测试，边界明确：仅支持单表基础操作，无持久化、事务和复杂表达式，适合初学者理解数据库与解析原理。
推荐收录，因为文章以可运行的 Go 代码完整展示了一个最小 SQL 数据库的词法分析、语法分析和内存执行流程，技术细节具体、步骤清晰，并配有测试样例与后续系列链接。适合想了解数据库内部机制、解析器实现或 Go 语言实践的中级读者，文中的 lexer/parser 组织方式和内存存储结构可直接迁移到其他小型解释器或教学项目。
技术文章 Phil Eaton - databases
本文是《Writing a SQL database from scratch in Go》系列第二篇，在首篇基础上为 gosql 增加二进制表达式与 WHERE 过滤。作者扩展 AST 加入 binaryExpression，采用 Pratt parsing 处理运算符优先级和括号；重构内存后端，让每个表达式针对表行求值。求值器支持标识符、数字/字符串/布尔字面量以及算术、比较、逻辑等运算符，并明确不进行隐式类型转换。SELECT 语句新增 WHERE 条件逐行过滤，投影列可通过表达式计算，文中给出 REPL 交互示例。该实现目前只支持单表、简单运算符，并依赖内存存储，是教学性质的 SQL 引擎骨架，尚未涉及索引、连接等真实数据库特性。
推荐收录，因为文章完整展示了在 Go 中实现 SQL 解析与求值的过程，包含 Pratt 解析器、AST 设计、表达式求值和内存表数据流，且代码与解释同步。适合对数据库内核、编译原理或解释器实现感兴趣的读者，可作为手写 SQL 引擎的参考起点。其可迁移价值在于解析器优先级处理和行上下文求值框架可复用于其他小型语言或查询引擎，但需注意示例省略了类型强制转换、优化和持久化等生产特性。
技术文章 Phil Eaton - databases
文章在 gosql 项目中扩展索引支持，涵盖 PRIMARY KEY 词法解析、红黑树索引创建、插入时索引维护和 SELECT 查询优化。作者使用 GoLLRB 红黑树存储索引项，通过识别 WHERE 条件中可应用索引的模式，先用索引预筛选行再执行过滤。文章分析当前查询计划仅支持 AND 连接和列与字面量比较，不能合并范围条件，且索引并非总是优于线性扫描。基准测试显示 100 万行插入时带索引内存和耗时增加，但等值查询从秒级降至微秒级，体现空间换时间的权衡。
推荐收录，因为文章通过写一个 Go 语言 SQL 数据库的索引模块，完整展示主键约束解析、红黑树索引构建、插入维护和查询预筛选的端到端实现，并给出有/无索引的实测性能对比。适合想理解数据库索引原理、查询规划和存储引擎实现的读者；其简化取舍与限制分析也可作为进一步阅读真实数据库文档与源码的入门桥梁。
技术文章 Phil Eaton - databases
本文通过约600行Go代码构建了一个分布式Postgres概念验证，解释了CockroachDB背后的核心组件：Postgres线协议、SQL解析、Raft共识和存储层。作者使用pgproto3、pg_query_go、Hashicorp Raft和bbolt，实现了CREATE TABLE、INSERT通过Raft复制到各节点，SELECT在任意节点本地执行。文章演示了多节点启动、通过HTTP手动加入集群、故障切换和重启后数据一致性。同时指出方案仅支持少量SQL、快照被禁用、日志重放效率低、JSON存储不高效，并且只实现了复制而非分片或跨分片事务。这个教程展示了如何将成熟库组合成可运行的分布式系统骨架，适合理解分布式数据库基础结构。
推荐收录，因为文章以可运行代码完整演示了分布式Postgres的核心机制：用Raft复制写操作、本地执行读操作，并明确说明了简化与局限。适合想理解CockroachDB等NewSQL系统底层组成或动手实现分布式数据库原型的读者。其将成熟库组合为可扩展骨架的思路、无快照设计取舍和故障切换验证过程具有可迁移价值，但需注意SQL支持和性能远非生产级。
技术文章 Phil Eaton - databases
本文记录作者在 Go 实现的 SQL 数据库 gosql 中添加 LIMIT 和 OFFSET 支持的过程。作者首先更新词法分析器以识别两个新关键字，然后扩展 AST 结构并调整生成代码的辅助函数，使打印结果包含 LIMIT 和 OFFSET。接着，解析器在 SELECT 语句中识别这些子句并解析其后的表达式，同时将 LIMIT 和 OFFSET 作为 WHERE 表达式的边界分隔符。运行时内存后端会先计算 limit 和 offset 数值，然后在逐行过滤中跳过 offset 之前的行，并在超出 limit+offset 范围后停止。文章特别指出，LIMIT/OFFSET 仍需要扫描至少 offset 数量的行，不适合大数据集分页，应优先考虑基于索引的分页。该实现仅针对内存存储，未涉及其他后端或优化策略。
推荐收录，本文不是零散片段，而是完整展示了为 SQL 引擎添加 LIMIT/OFFSET 语法所需的词法、语法分析和运行时三个层次改动，并附有代码 diff 与运行验证。适合对数据库实现、编译前端或 Go 语言工程感兴趣的读者，其修改顺序和边界意识可迁移到类似扩展场景。风险是实现针对特定内存后端，未深入讨论一般化架构，但作为参考案例足够。
技术文章 Phil Eaton - databases
文章从零构建一个基于 Go 和 Pebble 的简易文档数据库，支持通过 HTTP 插入、按 ID 获取和搜索 JSON 文档，代码控制在 500 行以内。作者实现了一个简化版 Lucene 查询语言，包括带引号字段名/值、嵌套路径、相等和范围比较以及隐式 AND。为了加速等值查询，系统在独立索引库中存储“路径=值”到文档 ID 列表的映射，并在搜索时对多个等值条件取交集；基准测试显示 year=1918 的查询从约 1 秒降至 0.03 秒。文章明确指出现有实现不支持范围索引、全文搜索和数组字段，且索引存储采用逗号分隔的 ID 字符串，适合作为理解文档数据库基本原理的教学项目而非生产系统。
推荐收录：文章提供了可运行的 Go 实现，完整覆盖查询解析、路径求值、基于 Pebble 的存储和等值索引构建，并给出了索引前后的性能对比，具有清晰的动手教学价值。适合后端工程师、数据库初学者或希望理解 Lucene 风格查询和倒排索引简化模型的读者。可迁移价值在于展示如何用少量代码实现可扩展的键值查询与索引设计，同时明确标出范围查询、数组和全文搜索等未覆盖边界，避免误导。
技术文章 Phil Eaton - databases
文章是 Phil Eaton “从零用 Go 写 SQL 数据库”系列的第四篇，主题是让自制数据库 gosql 实现 Go 标准库 database/sql 驱动接口。作者展示了如何注册驱动、实现 Driver/Conn/Rows 等接口，以及如何将已有的解析、执行和结果处理逻辑封装到符合 database/sql 规范的 API 中。文中以具体代码说明 Open、Query、Next、Columns 等方法的实现要点，并明确指出当前版本不支持参数化查询、事务和预处理语句，仅处理第一条语句。最终通过一个使用标准 sql.Open 查询数据的示例验证了驱动的可用性。文章篇幅较短，重点在于解释接口契约与底层映射。
推荐收录，因为它以清晰代码展示了如何为自制数据库实现标准 database/sql 驱动，对理解 Go 数据库驱动接口的契约和低层数据流转有直接帮助。适合需要为自研存储系统提供标准 SQL 接入、或想学习 Go database/sql 内部机制的开发者。文章明确承认不支持参数化、事务和预处理，边界清楚，便于读者判断适用范围。
技术文章 Phil Eaton - databases
本文详细介绍用Go语言实现Raft分布式共识协议中领导者选举和日志复制两大核心组件，并构建其上分布式键值存储。作者从状态机与KV API入手，逐步实现持久化、RPC、选举超时、投票逻辑、日志复制与提交推进。文中强调按Raft论文图2建模状态，并给出二进制持久化优化、批量复制等工程取舍。实现约1000行，经过手动与压力测试，但未接入Jepsen，也未实现重配置和快照，且固定日志条目大小；作者明确声明不用于生产，仅用于学习。整体展示了从算法到可运行系统的完整路径，适合理解共识实现细节。
推荐收录，因为文章以完整Go代码和Raft论文为依据，系统讲解选举与日志复制，并明确给出测试情况与限制。适合想深入理解分布式共识实现、数据库复制或使用Raft库的工程师和研究者，可迁移用于实现类似协议或排查相关问题；主要风险是版本未经验证、缺少快照等生产特性。
技术文章 Phil Eaton - databases
文章用单文件 Go 代码演示如何基于 Hashicorp Raft 库构建一个最小分布式键值数据库，约 260 行，通过 HTTP API 支持 set/get 和 join 操作。作者从 Raft 背景出发，逐步实现状态机（Apply、Restore、Snapshot 空实现）、节点初始化（BoltDB 日志存储、TCP 传输）和 HTTP 接口，其中 set 通过 Raft 日志复制，get 直接读本地内存但不保证强一致。文章最后给出可运行的完整示例，并提示未实现快照、不支持删除、节点需手动加入且仅用于学习。整体内容清晰展示了 Raft 库的集成流程与关键注意点，适合分布式系统入门参考。
推荐收录，因为文章以完整可运行的最小示例展示了 Hashicorp Raft 库的端到端集成路径，对理解 Raft 状态机、日志复制和集群管理具有直接帮助。适合分布式系统初学者或需要快速上手的开发者，其简洁实现可作为进一步实践和扩展的起点；同时文中明确指出了快照、读一致性和生产约束等简化点，避免了误用。
技术文章 Phil Eaton - databases
文章调查了 Cockroach、ClickHouse、DuckDB、PostgreSQL、SQLite、MySQL/MariaDB、MongoDB、TiDB 等系统如何执行查询表达式。作者通过阅读核心源码并以控制流函数为判断依据，区分了树遍历解释器、栈/寄存器虚拟机和 JIT 编译三类实现。结论显示多数数据库仍采用树遍历解释器，PostgreSQL 与 SQLite 使用虚拟机，MongoDB SBE 为栈式虚拟机，部分系统支持 JIT；ClickHouse、DuckDB、TiDB、Cockroach 还采用向量化执行。文章认为向量化和 JIT 更契合列存分析负载，事务系统迁移到编译器架构的收益未必显著；局限是结论来自源码阅读，可能存在误判且缺少性能基准。
本文通过大量数据库源码调查，给出了表达式执行模型的一手判断，具有长期技术索引价值。适合数据库内核开发者、查询引擎研究者以及想理解解释器与虚拟机差异的读者。其源码判断方法可直接迁移到其他系统，但需注意结论为静态阅读而非基准验证。
技术文章 Phil Eaton - databases
文章详细展示了如何在 PostgreSQL 的 PL/pgSQL 中从头实现一个类似 Forth 的栈式解释器。作者首先介绍 Forth 语言的基本概念，然后逐步实现数据栈、程序计数器、条件分支（IF/THEN）、内建指令（DUP、SWAP、算术运算等）以及函数定义（DEF）和调用（CALL）机制，并通过 hstore 扩展存储函数入口位置，使用返回指针栈处理嵌套调用。最终通过运行递归斐波那契函数验证了解释器的正确性。文章还指出了实现中的一些 PL/pgSQL 特性限制，如数组长度处理、NULL hstore 合并等问题。该实现仅为 Forth 的子集，未涉及完整 Forth 的诸多特性，但足以展示在受限的数据库过程语言中构造解释器的可行方法。
推荐收录，因为文章提供了一个完整可运行的 PL/pgSQL 解释器实现，包含逐步代码解释、设计取舍和实际运行验证，不是简单的语法介绍或新闻转述。适合对 PostgreSQL 内部过程语言、解释器构造或栈机器实现感兴趣的读者。其可迁移价值在于展示了在资源受限且语法特殊的嵌入式语言中实现编程语言核心机制的方法，对理解解释器原理和数据库编程均有启发，技术主题长期有效。
技术文章 Phil Eaton - databases
本文介绍用 Zig 编写一个最小 RocksDB 嵌入式键值数据库示例，封装 C API 实现 set、get 和基于前缀的 list 命令。作者先说明 RocksDB 以 C++ 编写但提供 C API，便于其他语言集成；随后逐步展示如何在 Zig 中用 @cImport 导入头文件，定义 RocksDB 包装结构，并调用 rocksdb_open、put、get 及迭代器接口。文中重点解释了 Zig 的类型系统和互操作细节，包括 error 类型缺陷、可选指针、C 字符串到切片的转换，以及匿名结构体在跨函数返回时的类型不兼容问题。最后给出 Linux 上的编译步骤、build.zig 配置和命令行运行结果。该示例仅适用于 Linux 与 Zig 0.10.x，RocksDB C API 文档不足，需参考头文件和测试代码。
文章提供了完整可运行的 Zig 调用 RocksDB C API 的最小示例，系统解释了 Zig 的错误处理、可选指针、C 字符串转换及构建配置，直接证据充分。适合希望学习系统编程语言与 C/C++ 库互操作、或集成嵌入式 KV 存储的开发者。可迁移价值在于 FFI 模式和 RocksDB 基础用法，但需注意 Zig 版本（0.10）与当前版本存在差异。
工程实践 Phil Eaton - databases
文章记录了作者在一周黑客活动中探索 MariaDB 内部机制并实现一个 218 行 C++ 的最小内存存储引擎的全过程。作者从构建调试版 MariaDB 开始，发现存储引擎插件必须放在源码树内而非独立仓，并实现了 handler 子类的 create、write_row、rnd_next、rnd_init 等关键方法。文中解释了 MySQL 的固定字节行格式和全局内存表结构，同时坦诚该引擎仅支持 INTEGER 字段、单数据库、非线程安全且不支持 NULL。作者还将 MySQL 与 Postgres 的存储引擎 API 进行对比，认为基于单行传递的设计限制了列存压缩和向量化的收益。最终通过 SQL 查询验证了引擎功能，并指出这类最小项目可作为探索其他存储后端的起点，适合作为学习数据库存储层原理的入门材料。
本文是难得的数据库存储引擎实战教程，作者以最小可行方式展示了如何从零接入 MariaDB 存储接口，代码完整且步骤清晰，并诚实标注了线程安全、数据类型等局限。适合对数据库内核、存储引擎或后端系统感兴趣的开发者阅读，可迁移价值在于理解存储引擎接口的设计约束以及如何快速验证自定义存储方案，同时避免被过度简化的示例误导。
工程实践 Phil Eaton - databases
文章针对 Go 语言中插入密集型数据库工作负载，对比 SQLite 和 PostgreSQL 的流行驱动与替代驱动的性能。作者使用统一基准：1000 万行、两种列数和数据大小，每个测试运行 10 次，记录中位数、标准差、最小/最大和吞吐量。结果表明，最流行的 SQLite 驱动 mattn/go-sqlite3 比作者维护的 gosqlite 慢约 20-40%；PostgreSQL 的 lib/pq 比 pgx（绕过 database/sql）慢约 44-76%，且 lib/pq 已停止开发。作者推测 database/sql 接口可能是开销来源之一，但未完全证明。对于小结果集查询，驱动间差异不大。结论是建议 Go 开发者在插入密集型场景中自行基准测试驱动，并优先考虑 pgx。
推荐收录，因为文章提供了可复现的、具体数据支撑的驱动性能对比，直接指导 Go 开发者在批量插入场景下的技术选型。文章不仅给出结论，还公开了基准测试方法和代码仓库，便于读者验证和扩展。适合后端工程师、数据库应用开发者参考，可迁移价值在于提醒性能敏感场景避免盲从默认驱动，且需关注 database/sql 接口的潜在开销。
技术文章 Phil Eaton - databases
文章展示了如何在 Zig 语言中用约 1700 行代码实现一个基于 RocksDB 的嵌入式 SQL 数据库。作者将项目拆分为词法分析、语法分析、存储层和执行层，详细讲解了每个组件的设计，包括手写 lexer/parser 支持 SELECT、INSERT、CREATE TABLE 等语句，以及如何用 RocksDB 持久化表元数据和行数据。文中还介绍了 Zig 的内存管理（Arena allocator）、数据序列化方案和表达式求值。该实现仅支持极小的 SQL 子集，无主键、事务和索引，主要用于学习数据库内部原理和 Zig/RocksDB 的实践，而非生产用途。
推荐收录，因为文章提供了完整可运行的代码实现和逐步讲解，清晰展示了从 SQL 解析到键值存储映射的完整流程。适合对数据库内部实现、Zig 语言或 RocksDB 感兴趣的开发者阅读，可迁移价值在于理解手写 lexer/parser 的实践、内存管理策略以及嵌入式数据库的架构设计。主要风险是项目功能有限，但作为教学参考具有长期价值。
技术文章 Phil Eaton - databases
文章系统介绍键值数据库（嵌入式如 RocksDB、LevelDB、PebbleDB，分布式如 FoundationDB、TiKV）在当代数据库系统中的重要性。作者从数据库可扩展性切入，解释存储引擎可替换如何帮助优化分析型或写密集型负载，并详细说明将 SQL 行映射为键值对的具体编码方法，包括表标识、主键和行标识组合及高效前缀扫描。文章梳理了可靠存储、嵌入式部署、高效前缀扫描等关键特性，并列举构建在这些存储上的多种数据库实例。最后区分了嵌入式与分布式键值数据库的架构差异，并指出非数据库开发者或非大规模场景可忽略存储层细节。
推荐收录，因为文章清晰梳理了键值存储在现代数据库架构中的核心作用，提供了 SQL 到 KV 映射的具体思路和真实数据库案例，适合想理解数据库存储层或构建数据库系统的开发者。它作为入门导览具有较好的长期参考价值，能帮助读者建立对存储引擎选型和架构分层的整体认知。
技术文章 Phil Eaton - databases
本文是一篇面向 PL/pgSQL 初学者的实践教程，从基础函数定义、命名参数、OUT 参数和递归函数入手，逐步过渡到字符串与数组操作、自定义复合类型，最终实现一个能解析 JSON 对象子集的词法分析器和语法解析器。作者强调目标不是生产级代码，而是熟悉语言特性，因此明确排除了嵌套对象、数组、Unicode 和小数等复杂场景。文中给出了完整可运行代码、测试脚本和错误处理示例，展示了如何利用 PL/pgSQL 的内置 SQL 函数、数组操作和自定义类型完成命令式编程任务。
推荐收录，因为文章不是简单罗列语法，而是通过实现字符串转数组、递归斐波那契和 JSON 解析器三个递进式例子，让读者理解 PL/pgSQL 的函数声明、控制流、复合类型和错误处理机制。对需要在 PostgreSQL 中编写存储过程、触发器或复杂业务逻辑的开发者来说，文中的代码模式和调试方法具有直接参考价值，且作者对语言边界和适用场景的说明清晰克制。
个人心得 Phil Eaton - databases
作者记录了自己加入 EnterpriseDB 分布式 Postgres 团队第一个月的 onboarding 经验。他提出先避开困难的人员、组织与流程问题，利用初期 sprint 自由度专注于构建、测试、运行和文档等可独立完成的任务。具体策略包括收集构建过程写内部博客，尝试静态/动态分析，探索测试覆盖率受阻后转向学习测试框架并撰写测试指南，将 quickstart 迁移到集成测试框架，编写启动本地集群的脚本，以及通过阅读文档和提出“笨问题”加深理解。他还建议将个人笔记开放为团队文档，并尝试绘制架构图。文章强调精确记录必要步骤与试错路径、公开分享学习成果、以及在团队频道中提问的价值。该方法适用于开发者快速上手复杂系统，但主要提供个人经验，尚未涉及深层技术细节。
推荐收录：作者以数据库团队新人视角，清晰展示了从构建、测试到文档的系统性 onboarding 路径，并提供了具体可操作的做法，如写内部博客沉淀知识、将 quickstart 移植为测试、用“笨问题”推动团队理解。适合即将加入新团队或需要快速熟悉复杂代码库的工程师，其方法可迁移到其他基础设施或后端项目。主要风险是内容偏个人经验，技术细节有限，但作为职业成长与工程实践反思仍具长期参考价值。
技术文章 Phil Eaton - databases
文章记录作者在探索 Postgres 查询执行钩子时的学习过程，目标是从 QueryDesc 计划对象重建原始 SQL 字符串。作者搭建了带共享库的调试环境，通过 ExecutorRun_hook 拦截查询，并逐步解释 Plan 节点、范围表、OpExpr、Const、Var 等关键结构。文中给出完整 C 扩展代码，示范如何查找关系名、操作符名和列名。最终实现对简单 SELECT 的 SQL 重建，验证了 a > 1、a + 1 和常数比较等场景。该方法仅覆盖顺序扫描、整型常量与基础 Vars，尚未处理连接、聚合、子查询和别名等复杂计划，且依赖特定版本 Postgres 内部 API。
推荐收录，因为这是一篇可复现的数据库内核级工程笔记，而非泛泛介绍：作者提供了完整 hook 代码、构建方式，并逐步验证从计划树重建 SQL 的能力。适合数据库内核、Postgres 扩展开发者以及对查询计划内部表示感兴趣的后端工程师。其可迁移价值在于展示如何遍历计划节点、解析表达式并访问系统目录，但注意依赖特定版本内部 API，升级时可能变化。
技术文章 Phil Eaton - databases
文章围绕Postgres 12引入的可插拔表访问方法（Table Access Method）API，通过实现一个内存存储引擎原型系统介绍了其工作机制。作者从Postgres调试构建和扩展基础设施开始，逐步探索TableAmRoutine结构体中必需的回调函数，通过日志和断言定位到slot_callbacks、scan_begin、getnextslot等关键方法。文章详细记录了如何在C扩展中管理表结构、存储行数据、处理插入和扫描，并解决slot填充、扫描状态管理等实际问题。最终原型支持创建内存表、插入整数和执行简单SQL查询，展示了复用Postgres上层SQL、协议和生态的潜力。作者明确说明这是原型质量代码，尚未实现索引、删除、更新等完整功能，适合作为进一步探索的基础。
推荐收录，因为文章填补了Postgres表访问方法缺乏最小实现教程的空白，以逐层调试和可运行代码展示了从扩展骨架到内存存储引擎的完整过程。适合数据库内核开发者、Postgres扩展作者和想理解可插拔存储引擎的读者，文中的调试方法、API使用陷阱和原型边界具有直接参考价值。
技术文章 Phil Eaton - databases
文章旨在建立对OLTP系统中分布式共识（尤其是Raft算法）的直觉。作者先解释Raft的基本机制：领导者选举、日志复制、提交和跟随者追赶，然后阐明分布式共识通过副本提供高可用和线性一致性，同时强调其本身并不提供水平扩展，水平扩展需通过分片实现。文章讨论了添加节点对延迟和可用性的权衡，并列举了实际优化技术，包括快照、批处理、磁盘/网络优化和灵活法定人数。此外还涉及安全与测试方法，如Jepsen、确定性测试和TLA+规格验证。最后指出共识开销大，应根据一致性需求选择合适方案。文章主要适用于OLTP系统，未深入非OLTP共识算法或具体实现细节。
推荐收录，因为文章用简洁直观的方式梳理了Raft在OLTP系统中的运作机制，并纠正了分布式共识常被误解为水平扩展的问题。作者从线性一致性、可用性、节点扩展、优化和测试等多个角度展开，既有理论直觉也有工程实践视角，适合分布式系统初学者和数据库工程师建立基础框架，同时为进阶读者提供了丰富的进一步阅读线索。
技术文章 Phil Eaton - databases
文章围绕持久性与预写日志（WAL）展开，作者通过伪代码逐步演示：内存数据库先写全量 B 树到磁盘并 fsync，虽然可实现持久性但效率很低；随后引入 group commit 摊销 fsync 成本，但每次仍写全量结构。作者指出更优做法是先写客户端请求到只追加日志并 fsync，即可安全返回，主数据结构延迟写入，启动时重放日志，这就是 WAL。文章还讨论了 fsync 失败处理、磁盘/文件系统损坏时 checksum 的作用、CDC 与 WAL 的关系，并强调多数数据库默认配置在安全与性能间权衡。最后总结持久性首先取决于向客户端返回成功前是否已落盘，WAL 是低成本实现手段。文章以浅显代码示例搭建直觉，适合理解存储持久性机制，但不涉及具体数据库生产实现细节。
推荐收录，因为文章以清晰的伪代码推演解释了 WAL 并非持久性唯一手段，而是针对全量写盘低效的优化方案。它把 fsync、group commit、checksum 和日志重放等概念串联起来，有助于读者建立数据库持久性的正确心智模型。适合后端工程师、数据库学习者和对存储系统感兴趣的人阅读。需要注意的是，文中为教学目的做了简化，不能直接等同于生产级实现。
技术文章 Phil Eaton - databases
文章用约 400 行 Go 代码实现了一个内存键值数据库，并基于 MVCC 和乐观并发控制支持五种 SQL 事务隔离级别：读未提交、读已提交、可重复读、快照隔离和可串行化。作者从多版本数据结构和可见性规则开始，逐步实现不同隔离级别下的读写逻辑，并通过读写集合在提交时进行写-写冲突或读-写冲突检测。文中用带注释的测试展示并发事务行为差异，同时讨论真空清理、版本存储放大等现实约束，并指出教学实现的局限，如未处理范围查询、子事务和保存点。
推荐收录，因为它以可运行的最小实现和测试清晰地解释了数据库事务隔离级别的核心机制，而非停留在概念罗列。适合数据库初学者、后端工程师或需要理解事务可见性和并发异常的读者；文中展示的版本可见性规则和冲突检测思路可以迁移到实际数据库选型与事务调试中。主要局限是教学简化，未覆盖生产级范围查询等细节。
技术文章 Phil Eaton - databases
文章以 Delta Lake 论文和协议为蓝本，用约 500 行 Go 零依赖代码实现了一个受 Delta Lake 启发的 serverless ACID 数据库。核心是利用对象存储的原子 putIfAbsent 语义，通过不可变数据文件和带事务 ID 的元数据日志实现快照隔离。文中详细演示了基于 POSIX link 的文件系统原子写入、事务动作、内存行缓冲、数据对象刷新和扫描迭代器，并用两个并发测试验证写冲突与读快照行为。作者明确指出该实现仅支持建表、插入和全表扫描，未覆盖更新、删除、日志 checkpoint、压实等，且合并所有表的事务日志比 Delta Lake 更严格，带来更高写冲突。
推荐收录，因为文章不是泛泛介绍，而是给出了从对象存储原语到事务提交的完整可运行实现，并通过测试展示了并发读写的实际行为。适合想理解 Delta Lake、Iceberg 类事务机制或实现对象存储上最小 ACID 数据库的读者，其抽象接口和原子提交思路可直接迁移到教学或原型系统。主要边界是省略了更新删除等生产特性，单写者模型也限制了并发写能力。
技术文章 Phil Eaton - databases
文章提出事务并非存储系统的固有属性，而是一种可以在任意存储系统上实现的协议。作者引用 Delta Lake、Orleans 在云存储上实现事务，以及 Epoxy 在 Redis 等系统上提供事务的方案，并提到两阶段提交作为经典例子。文章进一步指出，即使 PostgreSQL、MySQL、SQLite 已内置事务，开发者也可以选择绕开并实现自己的事务层，如 Convex 所做。作者认为，在需要一致性、原子性和隔离性，尤其是跨数据系统构建应用时，应把事务协议视为系统设计工具箱中的一种工具。文章以观点阐述和文献导引为主，未深入实现细节与性能评估。
这篇短文以清晰的视角将事务定义为可移植协议，串联了多个数据库系统的实现案例，适合需要理解跨存储系统一致性或设计事务层的读者。其价值在于提供思维框架和进一步阅读线索，但内容较为概略，应作为入门索引而非实现参考。
技术文章 Phil Eaton - databases
本文围绕磁盘 I/O 中可能导致数据丢失或损坏的场景展开，涵盖写入未达磁盘、fsync 失败、数据损坏、部分写入、假写、误写/误读等。作者基于 Parity Lost and Parity Regained 与 Characteristics, Impact, and Tolerance of Partial Disk Failures 两篇论文，解释了 buffered I/O 下 fsync 的必要性及其不可靠性，并介绍校验和、原子写、O_DIRECT 等缓解措施。文中对比了 Postgres、SQLite、MySQL、MongoDB、RocksDB 等系统在持久化、校验和与撕裂写处理上的默认行为，指出部分系统默认开启校验和，部分未开启，且假写和误写/误读常被忽视。文章限定于 Linux 环境，强调不同文件系统与磁盘的扇区大小差异，适合需要理解存储可靠性边界的开发者和数据库工程师。
本文以具体故障场景为线索，结合真实数据库系统的默认行为，清晰解释了磁盘 I/O 中容易被忽视的可靠性问题，如 fsync 失败、撕裂写和假写。适合需要设计或维护持久化系统的工程师，尤其是数据库与存储系统开发者。其价值在于将零散的 I/O 风险系统化，帮助读者在事务性场景中做出更稳妥的 fsync、校验和与原子写决策。
工程实践 LinkedIn Engineering - Architecture
文章复盘 LinkedIn 重建消息平台时的存量数据迁移过程。旧系统单体且数据非规范化，共享内容与个人元数据冗余存储；新系统改为规范化微服务，将共享消息与个人元数据分离。迁移采用三阶段方案：先双写实时复制新写入，再通过确定性 UUID v5 生成新旧 ID 映射，最后对 17 年快照做 Hadoop ETL、变换和批量上传。文章重点介绍了阴影验证机制、基于 If-Unmodified-Since 避免覆盖在线更新，以及表索引数量影响上传吞吐等经验。整体展示了大规模在线数据迁移中可迁移的架构权衡与实施细节。
推荐收录：文章提供了 LinkedIn 超大规模消息系统数据迁移的完整工程案例，包含三阶段方案、双写一致性、离线变换与阴影验证等具体实践。对负责数据库迁移、分布式一致性和后端架构的读者具有直接参考价值，尤其展示了复杂在线系统零停机迁移的可操作方法。
工程实践 LinkedIn Engineering - Scalability
本文介绍 LinkedIn 自研图数据库 LIquid 如何支撑其经济图谱（2700 亿条边、200 万 QPS）的实时访问。文章以 People You May Know 功能为例，说明从遗留系统 GAIA 迁移到 LIquid 的架构：用声明式 Datalog 查询做图遍历，再由 Venice 和 Pinot 提供特征与排序。迁移后 QPS 从 120 提升到 18000，延迟降到平均 50ms 以下，CPU 降低 3 倍以上，并支持更细粒度、可解释的推荐和快速 A/B 实验。作者也指出当前同质化架构在数据规模扩大时的低效问题，以及未来分层存储与工作负载优化的方向。
文章以真实生产系统为例，提供了从离线批量到实时图查询的完整迁移路径和可量化性能结果，证据具体、架构清晰。适合关注大规模图数据库、实时推荐或高并发基础设施的工程师借鉴，其关于声明式查询、索引优化和成本控制的方法具有跨团队可迁移价值。
工程实践 SelectDB 技术分享
文章针对大模型应用中专用向量库成本高、混合查询难的问题，深入剖析 Apache Doris 4.1 原生向量检索的工程设计。作者先比较专用向量数据库、关系型数据库扩展和分析型数据库原生支持三条路径，论证原生集成路线的优势。随后详细阐述 IVF 索引降低内存、IVF_ON_DISK 冷热分层、SQ/PQ 量化压缩以及 ANN Index Only Scan 优化查询性能的具体实现和 DDL 示例。文章还演示了结构化过滤联合查询与基于 RRF 的多路召回融合在 SQL 中的落地方式，并给出 VectorDBBench 基准数据。测试表明该方案在 100 万 768 维向量上取得 900 QPS、97% 召回率，构建速度最快，形成成本与性能的均衡。不过文中基准硬件规格不一，实际部署需根据工作负载进行验证。
推荐收录，因为文章不是简单的功能罗列，而是系统拆解了 Doris 4.1 向量检索的工程实现，包括 IVF 降本、磁盘索引、量化压缩、Index Only Scan 等关键设计，并提供了混合检索的 SQL 实现和基准数据。适合数据库内核、AI 基础设施和 RAG 系统开发者参考，其存储分层、覆盖索引和融合排序思路可迁移到其他 OLAP 或向量检索场景。需注意部分内容来自厂商，基准配置存在差异，应结合自身负载验证。
技术文章 SelectDB 技术分享
本文从 AI Agent 日志观测场景切入，指出 Agent 执行流具有嵌套数组、动态 Schema 和非确定性推理等特点，传统扁平日志模型无法还原完整执行树，而全量拍平会破坏上下文关系并导致频繁 DDL，直接存为 String 又会造成全表扫描和 JSON 解析性能瓶颈。作者提出让数据库原生支持半结构化数据，以 Apache Doris/SelectDB 的 VARIANT 类型为例，解释自动子列提取如何保留列式扫描性能和压缩率，倒排索引如何加速长文本和 JSON 内部关键字检索。文章进一步给出动静分离的混合建模实践：高频标量字段用标准列，动态嵌套对象用 VARIANT 列，关键排障字段建立倒排索引，并附建表与查询示例。内容主要基于 Doris/SelectDB 引擎，未提供跨引擎量化对比，但方案思路可迁移到 ClickHouse JSON 类型等类似系统。
推荐收录，因为文章直面 AI Agent 日志观测中 JSON 处理的核心矛盾，清晰对比了全量拍平、String 存储与半结构化原生支持三条路线的优劣，并提供可落地的混合建模 DDL/DML 示例。适合负责可观测性平台、日志分析或 OLAP 数据建模的工程师参考，其动静分离、自动子列提取与倒排索引组合的设计方法可以迁移到其他支持半结构化类型的列式数据库。
工程实践 SelectDB 技术分享
文章对 Apache Doris 4.0.5/4.1.0 引入的 ASOF JOIN 进行系统性能实测，该功能面向时间序列近邻关联，可在按业务键分组后找到不晚于左侧记录的最近右侧记录，适用于交易行情补全、事件归因等场景。测试设计覆盖大小表组合、1 亿行对 1 亿行、不同 NDV、长序列、短序列、乱序存储和过滤条件等六大类典型场景，并与 ClickHouse、DuckDB 在相同硬件和并发参数下对比。结果显示 Doris 在绝大多数用例中显著领先，例如大小表 JOIN 低至 0.15-0.38 秒，1 亿对 1 亿约 0.97-1.13 秒，短序列和乱序场景优势更明显。文章强调该实现具有低延迟和高稳定性，适合大规模、复杂分布的真实业务。需注意内容来自 SelectDB 官方技术团队，测试带有厂商视角，但其测试设计和场景覆盖可作为数据库选型与性能评估参考。
推荐收录，因为文章提供了 ASOF JOIN 系统化的性能基准测试，从测试设计、环境配置到多维度场景结果均有详细说明，对需要处理时间序列近邻关联的数据库工程师和架构师有直接参考价值。其可迁移价值在于展示了如何设计覆盖真实业务复杂度的数据库功能基准测试，但需注意来源为厂商官方，数据结论应结合独立验证或实际业务场景再判断。
工程实践 SelectDB 技术分享
文章讨论云数仓资源管理中长期存在的矛盾：业务负载波动大，固定规格资源常按峰值锁定，导致平均利用率低；传统存算分离架构弹性慢，扩容伴随缓存预热和数据重分布，容易引发查询延迟抖动。作者提出 SelectDB Serverless 的解决方案，通过计算、缓存、存储三层独立解耦，支持秒级原地纵向伸缩，单集群最高16倍弹性区间，并采用“扩快缩慢”策略——CPU 5秒均值或内存瞬时利用率超过60%触发扩容，CPU与内存同时低于30%且持续1分钟才渐进缩容，同时引入AI辅助决策。文章还给出选型参考：峰谷特征明显、可释放计算资源超过28%时Serverless才具成本优势；纵向弹性有16倍边界，极端场景需横向伸缩约3分钟。内容主要基于产品设计与机制说明，缺少独立用户验证数据。
推荐收录，因为它不只是产品宣传，而是提供了具体的弹性架构设计：三层资源解耦、扩缩容触发阈值、原地纵向伸缩机制和选型成本阈值，对云数仓、Serverless 或弹性架构设计的读者有直接参考价值。可迁移的是“扩快缩慢”的弹性策略和计算/缓存/存储解耦思路；需注意其厂商视角，部分性能数据未经独立验证。
技术文章 SelectDB 技术分享
文章分析了 AI Agent 生产环境中可观测性负载的新特点：文本主体大且无结构、关键字段高度动态、trace 有序嵌套、看板需与持续写入并存。作者指出传统搜索、OLAP、文档库难以单独胜任，需要统一混合负载数据系统。AgentLogsBench 用单表 1 亿行 observation 数据评测六种引擎，覆盖 trace 回放、短语搜索、动态 JSON 过滤和实时聚合。结果显示 Apache Doris 综合 slowdown 1.28 领先，hot/cold 均第一，但在长文本 cold phrase search 上仍落后 Elasticsearch。文章解释了 Doris 领先原因包括倒排索引、VARIANT 子列、按 trace_id 分布与排序键、分区裁剪和缓存机制。该文可作为选型或理解混合负载数据系统的参考，但数据来自合成 benchmark，结果需结合实际验证。
推荐收录，因为文章不是空泛宣传，而是给出了 Agent 可观测性基准的具体设计、完整查询负载和跨系统实测数据，并逐项解释 Doris 架构优化如何影响性能。适合从事可观测性、OLAP 或 AI 平台基础设施的读者，用于理解混合负载系统选型与优化。可迁移价值在于把文本搜索、动态 JSON、trace 回放和实时聚合放在同一存储上权衡；主要风险是来自 SelectDB 官方且数据为合成，需结合其他评测交叉验证。
技术文章 SelectDB 技术分享
本文介绍 Apache Doris 4.1 对 Iceberg 的能力扩展，从仅支持查询扩大到 UPDATE、DELETE、MERGE INTO 等 DML、表结构管理与日常维护，并完整支持 Iceberg V3。文章重点解析 Deletion Vector 机制：V3 用位图记录失效行并写入 Puffin 文件，使删除文件数量与数据文件同阶，文中测试显示文件数从336降至17、删除信息存储从98MiB降至3.8MiB、高删除比例查询时间降至约1/3。同时介绍 Row Lineage 提供的 _row_id 和 _last_updated_sequence_number 系统列，用于稳定行标识和增量变化识别，可配合 Time Travel 定位记录。作者也说明这些能力仅适用于 format-version=3 且需 Doris 4.1+，收益受数据规模和文件布局影响，Row Lineage 不等同审计系统。文章最后给出五分钟入门步骤并展望 Variant 读写和增量物化视图。
推荐收录，因为文章不是单纯的产品发布，而是提供了 Iceberg V3 关键机制（Deletion Vector、Row Lineage）的清晰解释、具体 SQL 示例和量化测试结果，并明确标注了版本、格式和场景边界。适合从事湖仓一体、Doris 或 Iceberg 数据管线的工程师理解如何在 OLAP 引擎中收敛查询、修改和维护，其关于减少删除文件开销和行级增量识别的思路具有可迁移价值。
工程实践 SelectDB 技术分享
文章介绍 Apache Doris 内置倒排索引解决 OLAP 稀疏扫描问题的技术机制与实测效果。针对传统 OLAP 依赖列存、排序和 Zone Maps 在稀疏查询下全表扫描的局限，文章详细解析了三种索引结构：字符串精确匹配用 Posting List，数值范围过滤用 BKD 树，非结构化文本检索用分词器结合倒排列表。在 1.35 亿条亚马逊评论数据集上，50 并发测试显示全文检索提速 59 倍，按 ID 点查提速 156 倍，多维组合查询提速 10 倍。同时评估了资源开销：新增 7 个索引后存储从 26GB 增至 47GB，写入耗时增加约 6%，主要来自大文本列。结论认为 OLAP 内置倒排索引可简化 Elasticsearch+OLAP 双引擎架构，但应根据查询特征选择性建索引以控制成本。
推荐收录，因为文章基于 1.35 亿条真实数据给出可复现的建表、索引和查询测试，定量对比了性能提升与存储/写入开销。适合数据库内核开发者、 OLAP 架构师和数据平台团队参考，其倒排索引设计思路可迁移到类似分析型系统或评估 Elasticsearch 替代方案。需要注意的是测试仅基于单节点和特定数据集，索引列选择需按业务权衡。
技术文章 SelectDB 技术分享
文章围绕宽表场景下 Footer 元数据膨胀问题展开，对比 Parquet、Lance 与 Doris Segment V3 的解决思路。作者首先指出列式存储中 Footer 会随列数和 Row Group 增长，在数千列、复杂 JSON/Variant 子列时可达数 MB 甚至数十 MB，拖慢查询启动与元数据解析。随后分析三种格式的约束：Parquet 受生态兼容限制，通过 FlatBuffer 随机访问、裁剪冗余和兼容扩展降低开销；Lance 从文件结构重设计，将列元数据独立存储并放弃传统 Row Group；Doris 则在保留 OLAP 能力前提下，将每列 ColumnMetaPB 外置到独立 Column Meta Region（CMR），并在 Footer 中仅保留轻量目录，同时为 Variant 增加路径索引。性能测试显示极端宽表下 Segment 打开时间从 65 秒降至 4 秒，内存从 60 GB 降至不足 1 GB。适用边界是数千列宽表、复杂 Variant 和大量 Segment 场景，窄表收益有限。
推荐收录，因为文章对列式存储元数据膨胀问题提供了清晰的问题拆解和三种主流格式的取舍对比，并详细说明了 Doris Segment V3 的 CMR 外置、Variant 路径索引以及性能验证数据。适合数据库内核、存储引擎、数据仓库以及对宽表/半结构化数据查询优化感兴趣的工程师阅读。可迁移价值在于理解文件格式设计中的兼容性、功能完整性与查询性能之间的权衡；主要风险是内容带有 Apache Doris 厂商视角，但对 Parquet 和 Lance 的分析仍较客观。
技术文章 SelectDB 技术分享
文章围绕 Agent 日志中动态 JSON payload 的性能挑战展开，基于 AgentLogsBench 基准测试对比了 Apache Doris、ClickHouse、Elasticsearch/OpenSearch 和 DuckDB/Parquet Variant。作者剖析了 Doris VARIANT 将常用 JSON Path 转化为列式 subcolumns 的机制，并通过高频路径列式化、低频路径 sparse columns 和 Storage Format V3 来优化宽 JSON 查询。测试显示 Doris 在动态字段聚合、rollup 和低基数过滤上延迟优势明显，平均比 ClickHouse 快 7.4 倍，比 Elasticsearch 快 2.4 倍，存储占用接近 ClickHouse 且远低于 Elasticsearch。文章还分析了其他系统的取舍，如 Elasticsearch 搜索强但动态聚合成本高、ClickHouse 压缩好但长尾路径查询慢、DuckDB/Parquet Variant 开放格式强但在线分析不足。结论指出，将动态 JSON 纳入列式存储、索引和向量化执行链路是决定搜索后分析体验的关键。边界在于结果来自厂商基准，可能带有一定倾向性，但技术原理和权衡分析具有参考价值。
推荐收录。文章不仅给出了性能对比数据，还深入解释了 Doris VARIANT 的 subcolumnization、Storage Format V3 机制，并对比了 ClickHouse、Elasticsearch、DuckDB/Parquet Variant 的架构取舍，技术细节和可迁移性强。适合数据库内核、OLAP、可观测性和大数据工程师理解动态 JSON 在不同系统中的处理方式，为 Agent 日志分析、技术选型和优化提供依据。尽管来自商业公司，但内容以基准和原理为主，推广成分较低，长期参考价值较高。
技术文章 SelectDB 技术分享
文章系统介绍 Apache Doris 的 Python UDF 功能，旨在让 SQL 直接调用 Python 生态以应对 AI 和实时分析中日益复杂的业务逻辑。核心方法是通过 Arrow RecordBatch 批量传输数据到独立 Python Server 执行，并支持 Pandas Series 向量化计算，减少跨语言和跨进程开销。Doris Python UDF 完整支持标量 UDF、UDAF 和 UDTF，提供内联与 ZIP 模块化加载方式，并内置进程隔离、复用和自愈机制以保证生产环境稳定性。文中给出支付风险分级和金额分桶等示例，展示在数据不离开分析链路的情况下完成规则判断、特征加工和模型打分。该能力已在 SelectDB 商业化产品中提供，适合需要将 Python 逻辑嵌入实时分析查询的场景，但部署前需在所有 BE 节点配置 Python 环境并安装 pandas/pyarrow。
本文对 Doris Python UDF 的设计机制、使用方式和生产化保障做了完整阐述，包含 Arrow 批量执行、向量化优化和故障恢复等关键细节，而非泛泛介绍。适合数据库内核开发者、数据工程师和需要在 SQL 引擎中集成 Python 生态的读者，可迁移到其他分析型数据库的扩展机制设计，帮助理解如何平衡灵活性、性能与可运维性。
技术文章 SelectDB 技术分享
文章系统解析了 Apache Doris 4.1 的 Spill to Disk 机制，用于避免哈希关联、聚合、排序等内存密集型查询触发 OOM。核心增强包括核心算子全覆盖、递归重分区应对数据倾斜，以及基于内存压力感知的主动落盘触发。文章详细说明了由控制层、算子层、基础设施层和内存管理层组成的统一架构，以及预留、暂停、落盘、恢复四阶段流程。针对 Hash Join、Aggregation、Sort 分别给出了化整为零、临时状态落盘和外部归并排序的具体实现策略。基准测试显示，在单 BE 16GB 内存下运行 TPC-DS 10TB 查询，复杂查询全部完成且内存被控制在 8GB 以内，部分场景落盘数据量超过 1000GB，验证了以磁盘 I/O 换取内存空间的可行性。当前 Intersect/Except 算子暂不支持直接 Spill，需要通过等价 Join 改写。
推荐收录，因为文章不仅介绍功能，还深入解释了内存压力感知、算子级落盘策略和统一架构设计，并给出了可验证的基准测试数据。对从事数据库内核开发、性能调优或超大规模分析查询的读者具有直接参考价值，其“预留-暂停-落盘-恢复”的资源控制方法和外部归并排序等思路也可迁移到其他内存受限的查询引擎中。
工程实践 TiDB 社区博客 - 实践案例 2026/08/13
文章复盘学科网阅卷系统从 MySQL 迁移到 TiDB 的实践，背景是业务具有峰谷特征、单机 MySQL 主备集群出现容量与性能瓶颈，同时研发资源有限无法改造代码。作者详细说明选型 TiDB 的关键理由：高度兼容 MySQL 实现零代码迁移、在线 DDL 不阻塞业务、弹性扩缩容适配流量波动、Raft 多副本保证数据强一致。迁移采用分批策略，优先将大表和主从延迟严重的表迁入，收益包括缓解并发压力、消除切换数据不一致风险、节省磁盘空间并避免分库分表改造。文中还总结了扩容规划、小表热点处理、低峰版本升级和索引优化等运维经验。该方案尤其适合教育行业等需要兼容 MySQL 且短时高并发的场景，但需注意跨 AZ 缩容的数据分布和热点小表的处理。
推荐收录，因为文章提供了真实业务约束下的数据库选型、迁移和运维全过程，包含零代码改造、在线 DDL、强一致、扩容规划、小表热点等具体细节，不是泛泛的技术宣传。适合数据库架构师、SRE 以及教育行业技术负责人参考，其“先兼容迁移、争取时间”的平滑演进思路可迁移到其他受限于 MySQL 单机瓶颈且短期无法大改代码的团队。
工程实践 TiDB 社区博客 - 实践案例 2026/08/13
文章围绕TiDB集群在元数据和管理信息完全丢失、仅保留TiKV数据文件情况下的恢复策略展开。作者以测试环境模拟案件取证场景，先通过TiKV日志提取原集群的Cluster ID，然后销毁原有集群与tiup元数据，重新部署相同版本TiDB集群，并将TiKV数据目录指向物理拷贝路径。随后修改last_tikv.toml中的日志、数据、raft等路径，使用pd-recover工具重置Cluster ID，最后启动集群并验证各组件状态。该方法适用于TiDB v6.1.0环境且TiKV数据完整、PD元数据不可恢复的场景。文章给出了具体命令和配置修改项，但未深入解释pd-recover原理、数据一致性验证细节及操作风险，整体更偏向可复现的操作记录。
推荐收录，因为文章提供了一个具体且可复现的TiDB灾难恢复案例，尤其适合运维人员或数据库管理员在元数据丢失时参考。文中的操作步骤、配置修改和Cluster ID恢复方法具备可迁移性，但需注意版本差异和数据一致性风险，建议结合官方文档使用。
工具笔记 Simon Willison 2026/08/12
文章宣布发布 alchemy-utils 0.1a0，这是一个基于 SQLAlchemy 的数据库无关版 sqlite-utils，目标是沿用 sqlite-utils 的核心 API（insert、upsert、insert_all、upsert_all、create、update 和表内省），同时支持 PostgreSQL、SQLite 和 DuckDB。作者通过给 Codex 和 GPT-5.6 Sol Ultra 下达研究性 spike 提示，配合 uv、TDD 和 pytest，在很少的后续提示下获得了可发布的原型。文中展示了用 uvx 列出 PostgreSQL 表数据以及将 CSV 导入 DuckDB 的命令示例，并提到将初始约一小时的 CSV 导入优化到约 35 秒。整体是一篇发布说明，未深入讨论 API 设计权衡、错误处理或扩展性，但提供了 AI 辅助开发数据库工具的具体案例。
推荐收录，因为它记录了一个使用 AI 编程代理快速构建跨数据库 Python 工具的真实过程，并给出了可运行的命令示例，对关注 AI 辅助开发、Python 数据库工具链或 sqlite-utils 生态的读者有直接参考价值。文章虽为 alpha 发布说明，但其中的提示工程思路、uvx 用法和性能优化片段可以迁移到类似项目中。
技术文章 TiDB 社区博客 - 技术解读 2026/08/12
文章系统讨论 AI Agent 的记忆体系，借鉴认知科学将记忆分为短期、语义和情景三层，并补充全文检索记忆需求。作者批评用 Redis、MySQL、向量库和 Elasticsearch 拼接的方案存在数据一致性、混合查询困难和运维复杂等痛点，提出应在同一数据库内核中原生融合关系、向量和全文检索能力。文章以 TiDB 8.5 为例，展示通过 VECTOR 列、向量索引和全文索引在单条 SQL 中组合结构化过滤、语义检索和关键词匹配的实现方式，并说明平凯云服务的 Serverless 弹性、HTAP 能力和全球部署优势。文章适合关注 Agent 记忆系统、RAG 或数据库选型的开发者，但需注意其官方博客的产品宣传色彩和方案边界。
推荐收录。文章不仅解释了 Agent 记忆的分类和需求，还具体分析了多系统拼接架构的工程痛点，并给出使用 TiDB 原生融合关系、向量和全文检索的 SQL 示例，证据具体、有可操作价值。适合构建有状态 AI Agent、RAG 应用或需要混合检索能力的开发者参考，可迁移架构思路，但需注意其中隐含的厂商推广和 TiDB 特定实现约束。
技术文章 Greptime 技术 2026/08/11
文章回顾了可观测性从指标、日志、追踪三支柱独立演进到统一列式存储的历史，并指出到2026年多个厂商已在存储与体验层实现统一。作者分析了两种工程选择：以 ClickHouse 等通用 OLAP 引擎为底座，或以 Grafana LGTM 为代表在控制层统一而存储分离；同时指出这些系统最初都默认人类用户线性查询。文章重点讨论智能体成为第一等消费者后，变化不仅停留在 MCP 和自然语言接口，还涉及并发查询、数据布局、语义层位置与数据发现等数据库架构问题。作者认为统一存储解决了人类时代的数据碎片化，但语义统一与机器高效消费仍待收敛，并留下后续讨论空间。文章属于行业观察与架构判断，而非具体实现验证。
推荐收录，因为它不是产品营销，而是对可观测性统一化与智能体使用场景的深入综述：既梳理了 Bourgon、Sigelman、OpenTelemetry 到 Observability 2.0 的演进脉络，也结合 2026 年多厂商动态提出数据库层尚未解决的关键问题。对从事可观测性平台、列存数据库或 AI 工程化的读者，本文提供了判断统一深度、智能体查询负载和语义层归属的分析框架，具有可迁移的架构参考价值。需注意作者来自 Greptime，可能存在厂商视角，但论证有据且克制。
工程实践 PlanetScale Blog 2026/08/11
文章深入分析PostgreSQL子事务缓存溢出机制及其双重危害：当单个事务累积超过PGPROC_MAX_CACHED_SUBXIDS（默认64）个子事务时，快照标记溢出，迫使所有查询走pg_subtrans SLRU查找，导致集群吞吐量骤降；同时在构建新只读副本时，溢出的RUNNING_XACTS记录使副本无法获取完整活动事务快照，长期无法启用热备模式。作者通过WAL解码、基准测试和火焰图验证了性能退化路径，并给出事务超时监控、pg_stat_slru跟踪等检测与缓解方法。指出重建PostgreSQL或等待CSN快照补丁合并是根本性方向，但当前需依赖运维手段降低风险。
推荐收录，因为文章不仅解释了子事务缓存溢出的原理，还提供了可复现的基准测试和火焰图分析，并展示了从现象到机制、从监控到缓解的完整工程路径。对于PostgreSQL数据库管理员、后端开发者及高可用架构师，本文能够帮助他们识别和规避这类集群级性能悬崖，其故障排查思路和监控设计也可以迁移到其他数据库系统的类似内部机制问题中。
工程实践 TiDB 社区博客 - 实践案例 2026/08/10
文章记录了永康市卫健委全民健康平台为解决业务高峰负载过高与容灾需求，采用平凯数据库物理复制能力进行架构改造的实践。改造将主集群专注核心事务，备集群承担报表查询等读操作和容灾角色，实现读写分离。上线后故障切换低于15秒且数据零丢失，系统负载下降，运维操作秒级完成。文章解释了物理复制基于日志实时同步所有数据库对象，支持最大保护、最大可用、最大性能三种模式，并与 TiCDC 逻辑复制对比，指出物理复制适合集群级容灾和读写分离，逻辑复制适合异构同步与数据管道。实际指标依赖网络拓扑和负载，且相关能力仍在演进。
推荐收录，因为文章提供了真实医疗场景下的数据库高可用与读写分离改造案例，包含明确的问题定义、技术选型依据、实施效果和方案对比。适合关注核心系统容灾、分布式数据库选型或架构优化的读者。可迁移价值在于展示了物理复制在强一致需求下的应用边界，但需注意厂商案例可能带有一定推广成分。
工程实践 Andy Atkinson 2026/08/10
文章介绍了在 PostgreSQL 大型表上安全添加和删除大索引的完整操作方案。针对创建索引可能持续数小时且需与线上查询并发执行的场景，作者详细说明了使用 CONCURRENTLY 选项避免写操作阻塞、设置 lock_timeout 和 statement_timeout 保护、在 screen/tmux 后台运行、通过特殊查询监控多阶段进度（扫描堆、排序元组、加载元组等）以及调整 maintenance_work_mem 和 max_parallel_maintenance_workers 优化资源的具体方法；同时提供了失败后清理 invalid 索引和处理唯一性限制的注意事项，并给出了最终可直接执行的命令模板。文中基于真实操作给出了各阶段耗时（总计约 6 小时）和性能特征，但方案仅适用于非分区表，且要求手动监控和串行执行并发构建。
推荐收录，因为它不是简单的语法介绍，而是生产环境中管理大表索引的实战手册，包含锁定超时、语句超时、并行度设置、进度监控查询等可复用的工程实践。适合数据库管理员、PostgreSQL 运维人员和后端工程师参考，文中的参数调整思路和阶段监控方法可直接迁移到其他长时 DDL 操作的安全执行中。
技术文章 Simon Willison 2026/08/09
文章探索在 SQLite 关系数据库中高效存储文本修订历史的方案。作者提出将文档的每个历史版本完整放入 JSON 字符串数组，再整体用 zlib 或 Zstandard 压缩，以 BLOB 形式存储；另用整数数组列保存时间戳，避免压缩。通过 GPT 辅助生成 Python 原型并模拟 1000 次修订，实验显示 20.4MB 原始修订文本压缩后仅 80.3KB，验证了冗余重复带来的高压缩比。为规避每次编辑全量解压重压缩的开销，进一步提出将历史拆分为多行，每行最多保留 128 个修订或 3MB 未压缩 JSON。该方案实现简单，适用于编辑频繁且文本重复度高的历史记录场景，但尚未评估高频写入、版本检索和并发冲突等生产级问题。
推荐收录，因为文章给出了一个可复现的原型验证：1000 次修订从 20.4MB 压缩至 80.3KB，并明确了拆行存储的工程折衷。这种利用全文冗余进行压缩的简单方案对处理版本历史、审计日志或文档快照的工程师有直接参考价值，可迁移到其他需要高效存储多版本文本的场景。主要风险是未与增量存储或事件溯源等常见方案做对比，也未覆盖高并发写入和随机版本读取的约束。
工程实践 TiDB 社区博客 - 实践案例 2026/08/07
文章记录了在 openEuler 22.03 SP4 国产化操作系统上部署 TiDB v8.5 的完整实践过程，包括 TiUP Playground 快速测试和 TiUP Cluster 单机模拟生产两种方案。作者详细列出了与官方 CentOS/RHEL 文档差异导致的典型问题，如 bash_profile 环境变量不生效、Playground 监听 127.0.0.1、openEuler 默认 MaxSessions=10 导致 SSH 并发连接失败、禁止 root 运行 TiDB 进程、防火墙端口放行、随机密码保存等，并给出对应解决命令。随后使用 Sysbench 进行只读和读写混合压测，复现了读写混合场景下的锁等待超时故障，分析了热点索引页、乐观事务冲突等成因，并通过调整隔离级别、增加 TiKV scheduler-concurrency、使用 --skip-trx 等方法缓解。文章适用于国产化环境部署 TiDB 和初步进行基准测试与故障排查的读者，但部分建议需根据实际业务场景谨慎采用。
推荐收录，因为它是真实环境下的部署与压测案例，覆盖了国产操作系统与分布式数据库兼容性问题、SSH 并发限制、权限管理等工程约束，以及基于 Sysbench 的锁等待故障分析。适合需要在 openEuler 等信创系统上部署 TiDB 或学习分布式数据库基准测试和初步排障的工程师，文中命令和排查路径可直接迁移到类似环境。主要风险是部分优化建议如降低隔离级别需结合业务正确性验证，不宜直接照搬生产环境。
工程实践 QuestDB Engineering 2026/08/07
文章测试 QuestDB 新 QWP 协议将查询结果流式传输到 Apache Arrow 的性能，并与 ClickHouse、TimescaleDB 对比。作者用简单查询和并行读取器基准，测量 500M 行数据的导出速度。最初几轮结果受磁盘 I/O、Python GIL 等因素影响，修正后 QuestDB 达到 220M 行/秒，首批数据仅 32ms，比 ClickHouse 最快流式路径快 2.35 倍。文章还分析了每行字节数、存储占用、扩展性和协调成本，并指出测试的局限（单一 schema、低基数字符串等）。该文提供了可复现的测试方法和详实的过程反思。
推荐收录，因为它不是简单的产品宣传，而是深入的工程基准测试，展示了如何识别并消除磁盘、GIL、协调成本等测试伪影，并提供了可复现的仓库和明确的局限声明。适合数据库选型、性能评估或数据管道设计的读者，可迁移价值在于严谨的流式数据导出基准测试方法和工程分析框架。
工程实践 PlanetScale Blog 2026/08/07
文章复盘了一次 MySQL 生产事故：一个长事务导致 InnoDB 版本历史膨胀，使读查询成本随并发量平方级增长，最终拖垮数据库。作者运用 Gunther 通用可伸缩性定律解析了争用系数 α 与一致性开销系数 β，阐明为何超过临界并发数后吞吐量反而下降。解决方案是将 Vitess 事务池从一万降低到约一千并引入排队，模拟原有线程池的反压行为，从而避免大量并发请求涌入存储引擎。配置变更后，系统在类似流量尖峰下吞吐稳定、无报错，MySQL 内部并发数控制在两百以内。文章强调此策略适用于悲观锁、热点行等高争用场景，且思路可迁移至 Postgres 等系统。
推荐收录，因为文章通过真实事故展示了并发与吞吐的逆向关系，并用通用可伸缩性定律提供量化分析。对负责高并发数据库、稳定性工程及反压机制设计的读者具有直接参考价值，可迁移到类似数据库和分布式系统中。文中提供的实验数据和配置对比使其结论可信，且明确给出了适用边界。
工程实践 PlanetScale Blog 2026/07/31
文章详细介绍了 PlanetScale 如何对分片 Postgres 数据库实现大规模并行备份。核心方法是：每个分片临时启动独立 EC2 实例，从 S3 恢复前次备份，再通过混合回放 WAL（先 S3 后直接从主库拉取最近几分钟日志）将备份追齐到当前状态，最后加密上传到 S3。文中还解释了初始备份的特殊处理、这种并行架构带来的备份速度优势（如 32 TB 数据库在 8 分片下仅需约 2.8 小时），以及备份在数据库扩缩容和节点故障替换中的实际工程用途。文章面向数据库基础设施工程师，展示了如何在降低生产影响的前提下实现快速、一致的备份，但其方案强依赖云环境与 PlanetScale 自研组件，迁移时需适配。
推荐收录，因为它不是泛泛的介绍，而是给出了一个真实工程系统的完整备份流程，包括架构取舍（用临时节点隔离生产影响）、混合 WAL 回放策略和可量化的并行加速效果。对负责大型数据库运维、备份恢复系统设计的工程师来说，文中的临时节点编排、S3 与主库混合回放、分片并行思想等有直接迁移价值，即使具体技术栈不同。
工程实践 Crunchy Data Blog 2026/07/30
文章系统探讨了在PostgreSQL和pgvector中实现混合搜索（向量相似度加标量过滤）的工程模式。首先阐述了pgvector迭代索引扫描如何平衡召回与性能，然后分析了向量优先和标量优先两条路径各自的适用场景与局限。作者进一步提供了三种实用工作区：为低基数过滤构建部分HNSW索引；通过过采样再过滤应对高基数或临时过滤器；以及利用缓存加速重复查询。文中给出了过采样的估算公式、查询计划诊断方法以及各方案的决策指南，并强调了每种模式在召回率、性能和维护成本之间的权衡。
推荐收录，因为本文是针对Postgres+pgvector混合搜索问题的实战指南，从问题根源到四种解决方案给出了完整的权衡分析、代码示例和调优公式，远超简单教程。适合正在构建带标量过滤的向量搜索系统的工程师，文中部分索引、过采样和缓存等模式可直接应用于生产环境，决策树和EXPLAIN诊断方法具有跨场景的可迁移价值。
技术文章 PlanetScale Blog 2026/07/24
文章深入解析 PostgreSQL 的三种备份方式：逻辑备份（pg_dump）、文件系统备份和连续归档。首先介绍 pg_dump 如何利用 MVCC 获取一致性快照，并指出其在特大库上可能因长期持有快照导致事务回卷而触发只读模式的风险。接着说明文件系统备份虽然速度快，但需要停机或原子快照支持，且无法实现时间点恢复。重点阐述了连续归档的原理：通过持续归档 WAL，结合 full_page_writes 在线备份文件系统后，利用 WAL 中的完整页镜像修复备份过程中可能出现的“涂抹”数据，从而得到一致且可恢复的备份。文章还解释了基于此机制的时间点恢复过程，以及 PlanetScale 如何通过每 12 小时自动备份与控制 WAL 重放窗口来保持恢复速度。最后简要提及大规模备份的挑战，为介绍分布式 PostgreSQL 与分片备份埋下伏笔。
本文不只是罗列备份命令，而是清晰解释了 pg_dump 的事务回卷风险、WAL 与 full_page_writes 如何解决在线备份的一致性难题，以及时间点恢复的内部逻辑。这些内容对数据库管理员、后端工程师和运维人员有直接参考价值，能帮助理解备份策略的真实约束和取舍，迁移至其他数据库系统时也有启发。
技术文章 PlanetScale Blog 2026/07/23
文章详细介绍了 Postgres 19 的三个主要变化：在线表压缩 REPACK、默认禁用 JIT 以及查询规划器的多项改进。REPACK 功能将 VACUUM FULL 和 CLUSTER 整合为一个支持在线操作的命令，使用逻辑解码与复制槽实现非阻塞重写，但存在额外磁盘空间和 MVCC 安全等限制。默认禁用 JIT 是因为其对 OLTP 查询可能引入的编译开销，转而允许用户按需启用。查询规划器新增了早期聚合优化，可在特定条件下将聚合下推到连接之前，并改进了 NOT IN 的处理。文章通过示例和对比展示了这些特性的用法与边界，还简要提及了 lz4 默认 TOAST 压缩、并行 autovacuum 等其他改进，为 PostgreSQL 用户和管理员提供了全面的升级指导。
推荐收录，因文章不仅列出新特性，还深入解析了设计动机、内部机制（如 REPACK CONCURRENTLY 使用复制槽与快照实现在线重写）和实际影响（JIT 默认禁用的权衡），附带代码示例和注意事项。适合数据库管理员、后端开发者了解 PostgreSQL 19 的关键变化与适用场景，其技术深度和实用性对长期运维参考价值显著。
技术文章 PlanetScale Blog 2026/07/20
本文深入解析 PostgreSQL 的 MVCC 实现，从元组（tuple）层面阐述多版本并发控制的原理。文章详细介绍了系统列 xmin 与 xmax 如何记录事务可见性，以及快照隔离如何通过 xmin/xmax/xip_list 决定事务看到的数据版本。进一步讲解了子事务、命令 ID（cmin）在解决 Halloween 问题中的作用，并通过 pageinspect 扩展展示页面布局与 VACUUM 的清理过程。还讨论了标准 VACUUM 与 VACUUM FULL 的区别、HOT 链的指针重定向机制，以及事务视界对死元组回收的影响。全文结合大量可执行的 SQL 示例，对理解 PostgreSQL 的膨胀（bloat）与维护具有长期参考价值，但内容仅适用于 PostgreSQL 及其特定版本。
这是一篇高质量的 PostgreSQL 内部机制讲解，不仅涵盖了 MVCC、元组可见性和快照隔离等概念，还通过 pageinspect 和实际操作演示了 VACUUM 的底层行为。对于需要深入理解 PostgreSQL 表空间膨胀原因、定位长事务阻塞 vacuum 的数据库管理员和开发者来说，这些可复现的分析方法可以直接应用到生产问题的排查与预防中。
工程实践 Marc Brooker 2026/07/19
Marc Brooker在这篇博客中介绍了Aurora DSQL论文，重点阐述了系统的整体目标：构建一个简化应用构建与运维、无需关心规模与可靠性的关系型数据库。文中强调了架构解耦的设计思想，将查询处理、事务、复制和控制面拆分为独立服务，并总结了来自Aurora与DynamoDB等系统的运营教训，如避免大缓存、提供强一致可扩展读、将昂贵操作下推到存储层。作者还讨论了乐观并发控制（OCC）在避免客户端阻塞和减少尾延迟方面的优势，以及多区域场景下的快速读写能力。博客最后指出，硬件与数据中心设计的进步使得强一致性成为更优选择，并提供了论文链接供进一步阅读。
作为Aurora DSQL系统的核心设计者之一，作者以第一视角提炼了论文的关键设计决策与运营经验，浓缩了现代分布式OLTP数据库的核心理念。文章对解耦架构、一致性选择、多区域扩展等问题的论述既权威又简明，适合分布式系统工程师、架构师及关注数据库技术演进的研究者快速获取全局认知，其总结的教训可迁移至其他大规模系统设计。
工程实践 Julia Evans 2026/07/17
Julia Evans 分享了她近期在 Django 网站中使用 SQLite 时积累的几个运维经验。她首先发现对 4000 行的表使用 FTS5 全文搜索耗时 5 秒，运行 ANALYZE 后降至毫秒级，推测是查询计划不佳所致。清理大量行时，删除操作超过 5 秒会导致其他工作线程写入超时崩溃，她通过小批量处理来规避。备份方面，最初使用 sqlite3 VACUUM INTO 加上 restic 上传到 S3，但偶尔 OOM 并产生锁问题；近期改用 Litestream 进行增量备份。她还提到拆分多个数据库文件有助于管理。文章基于个人小型项目，作者坦言若需要多写入支持可能得迁移到 PostgreSQL。
本文来自真实工程实践，详细记录了 ANALYZE 优化查询、批量清理避免写入冲突以及两种备份方案的具体步骤，对使用 SQLite 搭建个人或小型 Web 应用的开发者有直接参考价值。虽然深度有限，但作者的反思和解决方案具有可迁移性，适合作为入门级运维经验收录。
技术文章 Crunchy Data Blog 2026/07/16
Postgres 19计划将默认TOAST压缩算法从pglz切换为LZ4。本文追溯了从Postgres 7.0引入lztext到7.1实现TOAST与pglz的历史，解释了pglz设计的取舍：速度优先、极小内存占用、快速终止和零外部依赖。然后对比了LZ4的优势：更快的压缩速度（测试中提速约8倍）、更大的滑动窗口带来更好的压缩率，并保留了快速终止特性。文章详细说明了变长类型的varlena格式、EXTENDED/PLAIN/EXTERNAL/MAIN四种存储策略，以及写入时的压缩决策树：行大小超过约2KB阈值时，依次压缩前列大对象或移入TOAST表。此外，还介绍了B树索引中机会主义压缩的机制：当键值超过510字节时尝试压缩，并举例说明可压缩与不可压缩数据对索引的影响。整体内容既包含机制解析也包含实践测试，展示了Postgres团队在压缩演进上的谨慎策略。边界在于测试非科学化，且未深入LZ4算法内部细节。
本文系统梳理了Postgres压缩框架的历史、原理与决策路径，并结合代码示例和对比数据说明LZ4替代pglz的收益。适合需要理解Postgres存储优化、TOAST机制或索引限制的DBA与开发者，可迁移的价值在于掌握如何诊断压缩效果、选择存储策略以及评估算法升级对性能的影响。内容详实且有长期参考价值。
技术文章 PlanetScale Blog 2026/07/15
文章从数据库扩展瓶颈出发，解释了单节点和只读副本在写入吞吐、数据容量和备份速度上的局限，进而说明为何分片是超越数TB数据的必需方案。以存储1PB数据、跨越256个分片共768台服务器的场景为例，文章重点阐述代理层如何通过查询解析、路由规划和连接池，将众多分片对外表现为单一数据库。文中介绍了基于哈希的分片策略、JSON拓扑配置，并给出从应用经网络负载均衡到代理再到分片的完整数据流。文章主要提供架构层面的概览与工具选择（Neki for Postgres、Vitess for MySQL），而非深入实现细节，适合正在规划数据库扩展的工程师建立整体认知。
该文以清晰的架构图和具体规模为例，系统梳理了数据库分片的核心挑战与代理层设计，对理解分片系统的整体运作有实际参考价值。适合需要应对数据量增长的研发、DBA和基础设施工程师，可迁移的分层架构与路由思想能直接指导技术选型和方案设计。
工程实践 Simon Willison 2026/07/14
文章记录了社区站点 Lobsters 从 MariaDB 迁移到 SQLite 的完整工程实践。自 2018 年起计划切换数据库，最初考虑 PostgreSQL，2025 年转向 SQLite 评估，并于近期完成迁移并稳定运行。新架构中 Rails 应用运行在单台 VPS 上，使用多个 SQLite 文件分别管理内容、缓存、队列和限流数据，总大小约 5.7GB。迁移后 CPU 与内存占用均下降，站点响应提升，VPS 成本减半。文章引用了详细的 PR 和讨论，展示了代码变更量、关键决策和验证过程，为类似规模站点的数据库选型与迁移提供了可参考的真实案例。
推荐收录，因为本文提供了从 MariaDB 到 SQLite 的真实迁移案例，包含决策背景、架构变化、性能对比和成本收益等具体证据。适合后端开发者、架构师及运维人员在评估轻量级数据库方案时参考，其单机多文件部署模式及限流中间件集成具有可迁移价值。
技术文章 Simon Willison 2026/07/13
文章介绍了 DOOMQL 项目，一个完全用 SQLite 实现 Doom 式游戏的大胆实验，将移动、碰撞、敌人逻辑和光线追踪渲染全部写成 SQL 查询。作者展示了如何在终端运行该项目，并利用 Datasette 工具探索其生成的 SQLite 数据库；他还通过 Datasette Apps 插件快速构建了实时游戏画面仪表盘。文章重点在于演示 SQL（尤其是递归 CTE）在实时图形领域的非传统应用，以及如何结合 uv、Datasette 等工具进行探索式开发。适用边界在于这主要是技术验证和教学范例，不适合生产环境游戏开发，但其工具集成和查询设计思路对数据密集型应用的可视化或交互探索有启示意义。
本案例通过具体可复现的步骤，展示了用递归 CTE 实现光线追踪的工程做法，以及利用 Datasette 快速组装定制监控视图的实践。适合对数据库高级应用、工具链集成或创意编程感兴趣的开发者阅读，有助于掌握递归查询的深度用法和轻量级工具组合技巧。虽然游戏本身非工程级，但作为学习范例和灵感启发，其方法可迁移至数据探索、实时可视化等场景。
工程实践 PlanetScale Blog 2026/07/13
文章记录了一次 PostgreSQL 生产事故：在没有代码或流量变化的情况下，数据库 CPU 飙升，查询延迟从毫秒级恶化到约 10 秒。通过监控工具定位到一个特定查询模式，发现其执行计划突然放弃索引而进行全表扫描。根因在于 PostgreSQL 查询优化器基于统计信息生成计划，而数据增长导致统计信息演变，使得优化器在罕见情况下选择次优计划。团队临时使用 Database Traffic Control 立即拦截该查询以恢复数据库健康，随后在安全环境通过 EXPLAIN 分析计划变化，并提出长期修复方案，包括执行 ANALYZE 刷新统计、调整索引或重写查询。文章展示了从发现现象、定位根因、应急止损到永久修复的完整工程流程，并点明查询计划不稳定的普遍风险与应对思路。
这篇文章是典型的数据库性能事件复盘，有明确的故障现象、诊断过程（延迟关联、计划变化对比）和分级应对方案。它不仅展示了应急响应手段，还解释了 PostgreSQL 优化器行为的技术背景，为 DBA 和开发者在类似场景下快速识别和修复计划退化提供了可迁移的经验。文中虽有产品功能描述，但技术分析独立且扎实，适合作为数据库稳定性实践案例收录。
工程实践 知乎 - SmartCode 得物技术 2026/07/09
文章详细记录了得物将 OceanBase 作为多模数据库引入的完整工程实践。面对 MySQL 在 TP/AP 混合负载下性能瓶颈、存储成本高和运维复杂等问题，DBA 团队从选型对比、性能压测、复杂 SQL 优化到业务迁移全流程展开验证。通过计划缓存、分区裁剪、列存索引、并行执行和 Hint 干预等五步优化，将两类聚合查询的执行时间分别从 1.3s 和 3.9s 降至 0.01s 和 0.02s，并获得与 DuckDB、StarRocks 对比的详细性能数据。在真实业务迁移中，SQL 平均耗时下降 88.3%，存储压缩率超过 80%，总体降本 43%，并消除了异构数据同步和手动分流风险。文章同时总结了迁移中遇到的实时物化视图与 DDL 冲突、SQL 语法兼容等具体问题及应对方案，并规划了运维体系转型和团队能力建设路径。该实践适用于有 TP/AP 混合负载、追求成本与可用性平衡的场景，但需注意新功能边界和版本限制。
推荐收录。文章不是泛泛的产品介绍，而是提供了从选型对比、性能压测到生产迁移的完整技术链条，包含具体的 SQL 优化思路、量化收益（近 200 倍提升、43% 降本）和踩坑记录，对考虑 OceanBase 落地或从 MySQL 迁移到分布式数据库的架构师、DBA 有直接可复用的参考价值。文中的五步优化法、物化视图使用约束和运维体系转型经验均具备可迁移性，风险提示也较为坦诚。
工程实践 PlanetScale Blog 2026/07/08
文章围绕数据库死锁导致的排队、重试风暴和潜在宕机展开，先解释 Postgres 如何在 deadlock_timeout 之后检测锁环并回滚一个事务。作者指出，单次死锁通常可恢复，但当高并发下死锁频繁出现时，等待队列会迅速堆满连接池，死锁检测本身反而成为系统压力源。文中给出两类缓解手段：在查询与事务层面保持一致的加锁顺序、缩短事务并尽量晚加锁；在应用层对 40P01 错误做指数退避加随机抖动的重试，避免立即重复触发同一冲突。最后还介绍了通过 PlanetScale 的 Traffic Control 和 Resource Budget 在数据库侧限制问题查询并先以 warning 观察影响，再切换到 enforce 阻断锁竞争。文章适合处理高并发数据库系统的工程实践参考，但其效果依赖于死锁场景的规模、查询模式以及应用是否具备正确重试逻辑。
推荐收录，因为文章明确给出了死锁从“可恢复错误”演变为“队列堆积和宕机”的链条，并提供了查询顺序、事务长度、重试退避和数据库侧限流的组合治理方案。适合做数据库稳定性、故障预防和高并发系统设计的参考，且这些做法可迁移到其他关系型数据库与在线服务场景。
工程实践 Simon Willison 2026/07/07
这篇文章记录了 sqlite-utils 4.0 的正式发布，重点介绍了三个面向长期维护的能力：数据库迁移、可嵌套事务 db.atomic()，以及复合外键支持。迁移机制采用 Python 文件和装饰器定义变更序列，并用 _sqlite_migrations 表追踪已执行项，底层依赖 table.transform() 以“建新表、拷贝数据、替换旧表”的方式实现 SQLite 原生 ALTER TABLE 不支持的结构调整。作者同时说明了 4.0 中的破坏性改动，包括 db.query() 只用于读查询、写入改用 db.execute()、upsert 的冲突处理改为标准 ON CONFLICT 语法，以及 CSV/TSV 类型推断默认开启。文章还讨论了这些设计为何比 Django 式迁移更简单、为何不提供回滚，以及从 sqlite-migrate 合并到 sqlite-utils 的演进背景。最后，作者用 Claude 和 GPT 辅助做了回归测试与文档校对，展示了 AI 在发现事务、外键和导入逻辑缺陷方面的实际价值，但内容边界主要仍是该库自身生态，不是通用 ORM 迁移框架。
文章直接给出了迁移系统、嵌套事务和复合外键的实现方式，还明确说明了破坏性 API 调整与适用边界，适合做 SQLite 工具库设计和演进的长期参考。对维护数据库库、做 schema 演化或关注 AI 辅助测试的读者尤其有价值；但它是单个项目的发布复盘，不是通用教程，迁移设计仍需结合自身系统约束取舍。
科研议题 BAIR Blog 2026/07/07
这篇 BAIR 观点文章讨论了“智能几乎免费”后，数据系统将围绕 agents 重新定义的三类问题：为 agents 设计查询与分析接口、为 agents 构建长期运行与协作的底座、以及由 agents 反向合成可用的数据系统。作者结合已有研究指出，agentic speculation 会带来大量重复子查询，因此系统应支持共享扫描、多查询优化、近似回答、批量查询和更主动的性能反馈，而不再把 SQL 当作唯一交互形式。对于多 agent 场景，文章强调需要结构化记忆、面向任务的检索、并发编辑控制、故障恢复与协商机制，以避免上下文膨胀和 livelock 等问题。最后，作者讨论了用 agents 生成专用 OLAP 引擎、KV 存储乃至证明辅助的系统构造流程，但也指出规格不完备会导致 reward hacking，因此验证与测试是关键边界。整体上它是一篇研究路线图而非成熟方案，价值在于系统梳理了 agents 与数据系统共同演化的研究问题。
推荐收录，因为正文明确提出了“for/of/by agents”三条研究主线，并给出共享查询、结构化记忆、并发控制、系统合成与验证等可落地的技术方向。适合做数据系统、AI 基础设施和 agent 研究的选题地图，但应注意它是前瞻性观点文章，很多结论仍依赖作者正在推进的工作。
工程实践 Simon Willison 2026/07/05
这篇文章记录了 sqlite-utils 4.0rc2 的发布前审查过程，核心是作者借助 Claude Fable 对 rc1 之后的变更做全面回查，并最终推动稳定版发布。文中最关键的发现是事务处理存在多个隐藏缺陷：例如 delete_where() 会留下悬挂事务、db.execute() 的写入语义与文档不一致、db.query() 对返回行与非返回行语句的处理存在副作用。作者据此重构并补齐了事务模型说明，增加了 db.begin()/db.commit()/db.rollback()，同时修正了 Python 3.12 autocommit 兼容性、migrations 原子性、upsert 校验和若干命令行为。文章还展示了多轮子代理、交叉模型复审和基于 changelog 的增量写作流程，并给出约 149 美元的推理成本估算。整体上它既是一次真实的发布事故预防案例，也是一份关于 AI 辅助代码审查与事务语义设计的可复用经验。
推荐收录，因为正文不仅讲了“用 AI 写代码”，而是明确暴露并修复了数据库事务、自动提交和 API 语义上的真实缺陷，证据充分、可验证。适合关注 SQLite/数据库工具、发布审查和 AI 辅助代码审查的读者，尤其有助于借鉴“先审文档、再审实现、用多模型交叉复核”的工作流。
工程实践 知乎 - TencentDB腾讯云数据库 2026/06/26
文章系统剖析了 Redis/Valkey Cluster 在自动故障转移中的三段流程：PFAIL/FAIL 判死、故障副本拉票选举、以及新主广播后刷新路由，并解释了 currentEpoch、configEpoch、auth_timeout、auth_retry_time 和 data_age 的相互作用。作者指出，多个主节点同时故障时，多个副本会在同一 epoch 里并发拉票，因“每个 voter 同 epoch 只能投一票”而发生选票瓜分，导致 5 分片甚至 128 分片集群都可能长期无法自愈。腾讯云在 Valkey PR #1018 中引入 failed_primary_rank，以 shard_id 字典序为故障分片排序，在原有副本内排序基础上再叠加分片间错峰延迟，把抢票改成排队选举。文章还补充了 PR #1009 的快速失败兜底与 PR #762 的分片内错峰，说明这些优化都不改变一票一 epoch 的防脑裂原则，只是降低冲突概率并缩短恢复窗口。其价值在于把协议层的随机恢复，推进为大规模云环境下更确定的自愈流程；边界则是仍依赖 gossip 一致性，极端时序竞争下仍需快速失败兜底。
推荐收录，因为文章给出了从协议机制到线上故障现象的完整链路证据，并明确指出多主同时故障下的选票瓜分是 Cluster 自愈失败的根因。适合做 Redis/Valkey 高可用、分布式选举和故障转移设计的长期参考，尤其对云数据库和大规模集群运维很有迁移价值。
工程实践 PlanetScale Blog 2026/06/25
文章介绍了如何在一个 PlanetScale Postgres cluster 中承载多个应用：先用逻辑数据库把 blog、todo 等数据与 schema 分开，再通过角色与权限控制实现彼此隔离。作者重点解释了 Postgres 默认对新数据库开放 PUBLIC CONNECT、以及需要显式 REVOKE/GRANT 才能把访问收紧到指定角色，这也是多应用共享集群时最容易踩坑的部分。随后文章给出用 PlanetScale API 创建角色、再在数据库内授予 CONNECT、CREATE 和 schema 权限的完整流程，并提醒读写与迁移职责最好拆分成不同角色。最后作者把这些步骤自动化到 Pulumi/IaC 中，展示如何把新增或删除应用简化为修改配置数组并重新部署。文章也明确边界：这种共享集群方案更适合 side project 和小规模应用，增长到高并发或大量用户时仍应迁移到独立集群。
文章直接给出了 Postgres 多逻辑数据库隔离、角色权限收紧和 IaC 自动化的可执行做法，不是泛泛介绍概念。适合需要在同一集群承载多个小应用、或想把数据库权限管理流程自动化的工程读者参考；但它也明确说明了规模上来后应切到独立集群。
工具笔记 Simon Willison 2026/06/24
这篇文章记录了作者把 Mozilla 的 mdn/browser-compat-data 兼容性数据仓库转换成一个约 66MB 的 SQLite 数据库的实践。作者借助 Claude Code 和 sqlite-utils 生成转换脚本，再用 Codex Desktop 编写 GitHub Actions 工作流，在构建后把数据库强制推送到一个独立的 orphan 分支。这样做的目的不是做可写数据库，而是利用普通 GitHub 仓库文件可通过 CDN 访问且带开放 CORS 的特性，方便浏览器端直接下载和在 Datasette Lite 中在线探索。文章的核心价值在于展示了“结构化数据仓库 + SQLite + 静态托管 + 前端可直接查询”的发布链路。它更适合静态、可再生成的数据集分发场景，不适合高频写入或需要事务服务化的系统。
文章给出了可直接复用的证据：SQLite 生成脚本、GitHub Actions 自动构建、orphan 分支静态发布，以及利用 GitHub CDN 的开放 CORS 让浏览器端直接访问。对需要发布可下载数据集、做前端只读查询或搭建轻量数据浏览器的工程实践很有参考价值。
工程实践 Crunchy Data Blog 2026/06/16
文章以不列颠哥伦比亚省时区规则变更为例，讨论了 PostgreSQL 中时间存储的核心陷阱：把未来的“本地意图”仅用 timestamptz 保存，会因 tzdata 更新而在查询时还原出错误的本地时间。作者进一步提出双列模式，将 local_time 和 timezone_name 作为事实源，再用触发器计算并维护 starts_at_utc，以同时满足本地语义、UTC 索引与约束检查的需求。文中还说明了这种方案的适用边界、tzdata 变更后的重算策略，以及 RFC 9557 目前并不能解决这类未来本地时间问题。
推荐收录，因为文章围绕真实的时区规则变更给出了可直接迁移到数据库设计中的方案，不只是泛泛讲时间处理。它对预约、日程、法务截止时间等需要保留未来本地意图的系统尤其有参考价值，也明确提醒了哪些场景仍应继续使用 plain timestamptz。
工程实践 Cloudflare Blog 2026/06/12
这篇文章复盘了 Cloudflare 为 Security Insights 扫描系统做的整体扩容：从每周/每两周扫描一次、部分免费用户未自动扫描，提升到峰值每秒 120 次以上的扫描吞吐，并将免费用户默认扫描和全量扫描频率提升到更高水平。作者按链路拆解了多个瓶颈，包括 Kafka 消费的 head-of-line blocking、Postgres 批量写入效率、跨地域 API 延迟导致的连接池耗尽，以及调度器造成的扫描洪峰，并逐一用批量并行、快慢车道、UNNEST/COPY 混合写入、active-passive API 和自适应限流等手段解决。文章的核心结论是：在大规模系统里，先理解现有架构和真实瓶颈，再针对性优化，往往比简单加机器、加分区或抬超时更有效。
推荐收录，因为它不是泛泛的“扩容故事”，而是完整展示了一个安全扫描平台在消息队列、数据库、调度和跨地域部署上的系统性性能治理。对做后端、基础设施、安全平台或高并发任务调度的读者来说，这篇文章提供了很强的可迁移方法论：如何定位瓶颈、如何权衡架构改动、以及如何用指标验证收益。
工程实践 Datadog Engineering 2026/06/04
这篇文章复盘了 Datadog 在一次 reliability gameday 中发现的 PostgreSQL 故障切换不安全问题：表面上集群看似具备高可用能力，但在 Kubernetes 环境下，原有方案无法保证 failover 时的数据一致性与切换正确性。作者进一步说明了他们如何引入 Patroni 与同步复制，重新设计状态管理、领导者选举和故障转移流程，以提升 PostgreSQL 集群在容器编排环境中的可用性与安全性。文章的重点不只是“如何搭建”，而是明确了 stateful 数据库在 K8s 上做 HA 时必须面对的一致性、自动化与运维验证边界。
推荐收录，因为它不是泛泛介绍 PostgreSQL 或 Kubernetes，而是基于真实演练暴露出的故障切换风险，给出了一套有约束条件的高可用改造思路。对于需要在容器平台上运行状态型数据库、设计故障转移机制或做可靠性演练的读者，这篇文章有很强的迁移价值。
工程实践 知乎 - 胡津铭 2026/05/08
这篇文章介绍了一个面向 AI Agent 和 RAG 场景的嵌入式向量数据库 Caliby，核心卖点是把文本、向量、元数据统一放进同一套进程内引擎，并通过 HNSW、DiskANN、IVF+PQ 三类索引覆盖不同规模与延迟需求。文章还说明了它在磁盘持久化、SIMD 加速、Python 绑定、批量并发检索上的设计思路，并给出与 pgvector、FAISS 的性能对比，强调“pip install 即可用”的本地化部署体验。需要注意的是，正文更偏项目发布与产品介绍，性能数字和结论主要来自作者展示，适合作为选型与架构参考，但不宜当作严谨基准报告直接引用。
推荐收录，因为它不是单纯的产品宣传，而是把“AI Agent 需要什么样的数据引擎”这个问题具体化到了嵌入式、持久化、索引选择和文本/向量统一管理等工程决策上。对做向量检索、RAG、Agent 记忆系统或本地优先工具的读者，这些设计取舍和场景划分具有可迁移价值。
工程实践 Yelp Engineering 2026/04/07
文章复盘 Yelp 数据库可靠性团队如何将一千多台 Cassandra 节点从 3.11 升级到 4.1，并做到全程零停机。作者先说明 Cassandra 在 Yelp 中承载主数据与衍生数据，且集群运行在 Kubernetes 上、由 operator 编排，因此升级必须兼顾状态迁移、回滚和服务连续性。文中强调此次升级的驱动力不仅是版本更新，还包括更好的可观测性、可靠性和性能，且决策参考了公开基准。整体上，它展示了大规模有状态服务在成熟运维体系下的分批规划、验证与上线思路，但其可迁移性明显依赖现有自动化、编排和回滚能力。
有明确工程证据：超过一千台 Cassandra 节点、Kubernetes + operator、3.11 到 4.1、零停机升级，说明这是大规模状态系统的真实复盘。适合做数据库可靠性、滚动升级和有状态服务编排的参考，但方法强依赖现有自动化与回滚机制，迁移时需评估自身条件。
工程实践 Datadog Engineering 2026/03/23
这篇文章复盘了 Datadog 在高流量场景下排查 Postgres 性能退化的过程：一次 upsert 操作表面上没有“更新”数据，却仍然引发了磁盘写入翻倍。作者从现象出发，结合数据库监控与写放大分析，最终定位到 Postgres 的 WAL 行为和 upsert 语义带来的隐藏成本。文章进一步说明，问题并不在业务逻辑本身，而在查询写法与存储引擎内部机制的交互。团队通过重写查询，去掉不必要的写入路径，恢复了写放大和 IO 压力的正常水平。它的价值主要在于揭示了高并发写场景下，SQL 语义、日志机制和性能表现之间的非直观关系，但结论对 Postgres 语义和负载形态有明显依赖。
推荐收录，因为文章给出了明确的工程证据：高频 upsert 导致磁盘写入翻倍，且根因落在 Postgres WAL 与查询语义的组合效应上，而不是泛泛的“数据库慢”。适合做数据库性能优化、线上故障定位和写放大分析的参考案例，但迁移时要注意它强依赖 Postgres 的实现细节。
工程实践 Crunchy Data Blog 2026/01/20
这篇文章讨论了 Postgres 中自增主键从 SERIAL/INT 升级到 BIGINT 的必要性，核心理由是 INT 只有约 21 亿上限，而 BIGINT 基本不会溢出。作者进一步说明 BIGINT 在很多行布局下并不比 INT 更占空间，因为 PostgreSQL 的行对齐和填充会抵消所谓的 4 字节节省，因此用 BIGINT 的长期成本通常很低。文章还对比了 UUID 的适用场景，认为跨系统或需要公开暴露 ID 的场景可以选 UUID，但纯数据库序列号未必需要放弃整数。随后给出了一套可在线执行的迁移方案：新增 BIGINT 列、触发器同步、分批回填、定期 VACUUM、并发建唯一索引、处理外键引用表，再在一个短事务里完成 atomic swap。文中也强调了边界条件：需要预留短暂排它锁、先在非生产环境验证批次大小和回填策略，并确保序列、外键和主键约束在切换后都能正确接管。
推荐收录，因为文章直接给出了从 INT 到 BIGINT 的完整 PostgreSQL 迁移链路，包含分批回填、NOT VALID 外键、并发建索引和原子切换等可复用证据。适合负责数据库演进、线上改表或容量规划的后端/DBA 读者，主要价值是把一次高风险 schema 变更拆成可验证的操作步骤。
工程实践 Crunchy Data Blog 2025/12/11
文章介绍了 Postgres 18 将数据校验和（data checksums）设为 initdb 的默认开启项，强调其核心价值是及早发现磁盘页的静默损坏。作者先解释校验和如何在写入数据页时生成、存入页头，并在读取时重新计算比对，从而把原本难以察觉的数据腐败转化为可报警错误。随后文章说明这一默认变化对新建集群是纯收益，但会影响使用 pg_upgrade 的大版本升级，因为新旧集群的校验和开关必须一致。文中给出两条应对路径：升级时可用 --no-data-checksums 保持兼容，或提前用 pg_checksums 为现有集群补开校验和，但后者通常需要停机或通过副本切换来降低影响。整体适用于自建 PostgreSQL 运维、升级规划和备份完整性管理场景。
文章直接给出 Postgres 18 默认行为变化、pg_upgrade 兼容条件和 pg_checksums 处理方案，证据明确且可操作性强。适合数据库运维、平台工程和升级规划读者，尤其对自建集群的完整性保障与停机权衡有长期参考价值。
工程实践 Datadog Engineering 2025/06/17
这篇文章讲 Datadog 如何在大规模生产环境中拆解一个共享数据库，核心目标是把原本耦合的业务边界重新切开，同时尽量不影响线上稳定性。作者强调先定义清晰的所有权边界，再通过分阶段迁移、风险隔离和回滚预案降低改造成本，而不是一次性“硬拆”。文中还介绍了用于自动化迁移、校验一致性和减少人工操作的配套工具，以保证解耦过程可重复、可持续。它的重点不在数据库原理本身，而在多团队共用核心存储时如何平衡组织边界、迁移风险和工程效率。其适用前提是已有足够的监控、测试和发布控制能力，若系统变更链路薄弱，收益会被迁移复杂度抵消。
文章直接围绕“shared database at scale”的拆分实践展开，给出了边界划分、风险控制和自动化工具这三类可迁移做法，明显属于可长期参考的工程案例。适合正在做服务解耦、数据库分片/迁移或多团队协作治理的读者，但需要注意其前提是具备较成熟的发布与验证体系。
工程实践 Yelp Engineering 2025/05/27
文章来自 Yelp 的 Revenue Automation 系列，聚焦在收入数据管道与第三方系统集成时的测试和验证方案。作者先说明现状：原本依赖 Redshift Connector 在报表发布后再同步到数仓，导致验证数据要延迟约 10 小时才能可见，严重影响迭代效率。基于这一约束，文章讨论了如何设计更稳健的生产测试与集成策略，以便在复杂转换逻辑下尽早发现问题。它的核心价值不在于单点工具，而在于围绕批处理数仓、外部系统联调和回归验证建立更短反馈闭环。该经验对类似的数据工程、财务/收入类流水线和第三方集成场景具有较强迁移性，但对实时系统或纯应用单测场景的直接参考有限。
文中直接给出旧方案通过 Redshift 同步带来约 10 小时验证延迟，这是重新设计测试链路的明确工程证据。适合做数据管道、数仓联调和生产验证的团队阅读，可借鉴其将反馈时延作为核心约束来优化测试策略的思路。
工程实践 PlanetScale Blog 2024/11/19
这篇文章是三部曲的收官篇，集中讨论数据库限流器的客户端识别、优先级控制和规则边界。作者提出，限流器应能区分具体作业或作业类别，否则难以做监控、审计和针对性调度；同时，真正安全的“优先级”通常不是直接放行某个客户端，而是通过对其他客户端提高拒绝率来实现。文中进一步分析了豁免、不同指标下的限流与饥饿风险，指出对某些作业单独放宽指标本质上接近豁免，可能让其他作业长期得不到执行机会。作者也强调，豁免并非绝对错误，在故障修复、系统关键内部流量或短时影响可接受时可以使用，但应设置失效时间。最后，文章对比了协作式限流与代理式强制限流，说明后者更难绕过，但也更依赖客户端/连接层暴露足够的身份信息。
文章直接给出了生产环境限流器的核心设计证据：客户端身份、优先级、豁免、饥饿风险和协作/强制两种模型的取舍。适合做数据库运维、平台工程和系统设计参考，尤其对需要控制批处理、迁移和大规模任务的场景有可迁移价值。
工程实践 PlanetScale Blog 2024/10/10
本文继续分析 throttler 的部署形态，先比较单体服务、独立多实例、主备切换以及引入 agent/API 的方案。作者指出，加入采集代理或跨节点协作后，系统会从单一同步组件演变成分布式多组件系统，复杂度、权限边界和版本兼容问题都会上升，同时采样间隔叠加也会让指标更陈旧。随后文章给出分布式 throttler 的几种切分方式：按可用区、按功能、按主机或按服务粒度，并以 Vitess tablet throttler 为例说明如何在 shard 范围内聚合 replica lag，让 primary 代表整个 shard 做限流判断。最后，文章讨论如何降低 throttler 自身开销，包括客户端退避、空闲时降低采样频率或休眠、以及在无大任务时减少 heartbeat 生成，避免 binlog、磁盘和备份成本被额外放大。其边界在于，这些策略都依赖对业务负载形态、重试行为和一致性要求的准确预判。
收录价值明确：文章直接比较了 throttler 的单体、分布式与 agent 化方案，并用 Vitess 的 shard 级限流给出可落地的架构证据。适合做 MySQL/Vitess、SRE 和基础设施设计参考，但需要注意其结论高度依赖心跳粒度、轮询频率和客户端重试假设。
技术文章 PlanetScale Blog 2024/09/09
文章系统解释了 B-tree 与 B+tree 的结构差异、节点有序性、查找/插入路径，以及它们为何特别适合磁盘上的持久化数据。作者进一步结合 InnoDB 说明：表数据和二级索引都会落到 B+tree 上，查询通常需要先查索引再回表，因此访问的页数直接决定性能。文章重点比较了自增整数、UUIDv4、UUIDv7 等主键选择对树深度、页分裂、写放大和数据局部性的影响，指出随机键会导致插入路径不可预测、叶子分散、缓存命中更差，而顺序键更利于保持浅层和连续访问。文中还说明了页大小、buffer pool 和表宽度对单页可容纳行数的影响，并给出主键大小与可扩展性的权衡。整体适合理解数据库索引底层机制，但内容主要面向 MySQL/InnoDB 场景，结论迁移到其他存储引擎时需结合其页布局和实现差异。
文中直接给出 B+tree、InnoDB 页和二级索引回表的工作方式，并用主键选择解释性能差异，证据充分、可验证。适合数据库开发、后端和性能优化读者，尤其是需要评估主键设计、索引布局和随机写放大风险的场景。
工程实践 PlanetScale Blog 2024/09/04
文章介绍了 PlanetScale 为符合条件的 deploy request 新增的“instant deployment”能力，用于把数据库 schema 部署时间从小时级压缩到接近秒级。其核心前提是请求中的所有变更都必须能被 MySQL 的 INSTANT DDL 满足，例如符合条件的 ALTER TABLE，以及可选的建表、删表、建视图、改视图和删视图。系统会在部署前自动判断是否满足条件，并让用户在 instant deployment 与默认的 Online DDL 之间做显式选择。文章同时强调了边界：instant deployment 不可 revert，在某些负载下迁移表仍可能出现数秒级锁，因此它只适用于少量明确可瞬时执行的 schema 变更。
推荐收录，因为文章给出了数据库 schema 变更加速的具体判定条件、系统预评估机制和不可忽略的风险边界，而不是单纯宣传新功能。适合做数据库平台、迁移系统和 SRE 设计参考，尤其对需要在“速度”和“可回滚/稳定性”之间取舍的场景有直接迁移价值。
工程实践 PlanetScale Blog 2024/08/19
文章围绕数据库在云上扩容时最容易被忽视的 IOPS 和吞吐量成本展开，先解释 AWS EBS 中 IOPS 的计量方式、顺序/随机读写对有效带宽的影响，以及 gp3、io1、io2 的配额与价格差异。随后作者用 RDS、Aurora 和 PlanetScale 的月费对比，说明当单体数据库从中等规模增长到 8 倍需求时，单机方案往往要付出显著更高的 I/O Premium。文章的核心观点是：对 I/O 密集型数据库，分片可以把计算、存储和 I/O 压力拆散到多个 primary 上，从而继续使用更便宜的存储层。文中还指出分片带来的额外收益包括故障隔离、备份更快和长期线性扩展，但没有给出实际压测结果，因此结论更偏成本与架构层面的比较，而非纯性能评测。
文中直接用 EBS 的 IOPS/吞吐限制和三种数据库方案的月费对比，证明了单体扩容会迅速推高 I/O 成本，而分片能把需求摊平到多个 shard 上。适合做数据库容量规划、云成本评估和分片选型的读者；但价格结论依赖区域、流量形态和分片键设计，落地时需要按自身 workload 复算。
工程实践 PlanetScale Blog 2024/08/14
这篇文章介绍了 PlanetScale Insights 新增的“索引使用跟踪”能力，目标是在真实生产流量中观察每个查询模式实际命中了哪些索引，以及这种使用如何随时间变化。作者先比较了 EXPLAIN、MySQL performance schema 等现有手段，指出它们要么只能分析单条手工输入的查询，要么只能提供服务器级累计计数，难以关联到具体查询模式和趋势。随后文章给出实现思路：利用 InnoDB 的索引初始化流程，在查询执行过程中记录被选中的索引，将结果随响应返回到 VTGate，再按查询模式聚合并以时间序列方式写入 Insights 流水线。这样可以在几乎不增加 MySQL 开销的前提下，获得覆盖全部查询的索引使用统计，并支持反向检索“哪些查询在用某个索引”或“哪些查询完全未命中索引”。但它也明确了边界：索引信息目前只对 SELECT 统计，删除索引前仍需独立核实 UPDATE/DELETE 的使用情况。文章的价值在于把数据库可观测性、查询归因和索引治理串成了一套可落地的方法。
收录价值明确：文章不仅解释了功能，还给出从 MySQL/InnoDB 到 VTGate 和 Insights 的完整实现链路，以及为何 EXPLAIN 和 performance schema 不足以支撑生产趋势分析。适合做数据库性能优化、索引治理和可观测性设计的参考，但需注意它只覆盖 SELECT 场景。
工程实践 PlanetScale Blog 2024/08/13
文章系统拆解了 PlanetScale 在 TB 到 PB 级 MySQL 迁移中实现零停机的流程：先做一致性且不加锁的快照，再持续复制 binlog 追平增量，并用 VDiff 对源端与目标端做全表校验。切流阶段通过 VTGate 缓冲请求、等待复制追平、建立反向复制链路，使切换可在秒级完成且可随时回滚。作者进一步说明了底层依赖 Vitess 的 VReplication、MoveTables、路由规则、序列和 sidecar 元数据，展示了按表、按分片串并行协作的实现方式。文章也明确了适用边界：切流前经 PlanetScale 转发会引入额外网络开销，建议使用只读副本作为迁移源；而超过约 250GiB 的库通常应结合分片来控制成本与性能风险。
推荐收录，因为文章不是泛泛谈“零停机”，而是给出了快照、GTID、binlog 追平、VDiff 校验、反向复制和请求缓冲等完整证据链。适合做数据库迁移、分库分表和在线切流的工程参考，尤其对需要评估回滚能力与迁移风险的团队很有迁移价值。
工程实践 PlanetScale Blog 2024/07/30
文章系统解释了 PlanetScale 在 Vitess 体系下的备份流程：先从对象存储取回上一次备份，恢复到专用 VTBackup 实例，再让其通过主库做短暂追平，最后生成新的全量备份写回 S3/GCS。作者强调，单库越大，顺序备份越容易被网络与恢复耗时拖慢；而分片后每个 shard 可并行执行同样流程，从而把总体备份时间显著压缩。文中用 161GB 未分片库与 20TB、32 分片库对比，说明总体吞吐提升主要来自并行化，而非单分片传输速度大幅上涨。文章还补充了备份的工程意义：它不仅用于灾难恢复，也用于新副本初始化、误删恢复和 Vitess 的时间点恢复。适用前提是数据库已分片且备份/恢复链路能并行调度；若是单体库或分片不均，效果会明显打折。
推荐收录，因为文章给出了可复用的备份链路设计、分片并行化带来的吞吐收益，以及备份在副本初始化和误删恢复中的真实作用。对做数据库基础设施、MySQL/Vitess、备份恢复或大规模系统运维的读者尤其有参考价值，但前提是系统本身具备分片与并行恢复能力。
工程实践 PlanetScale Blog 2024/07/29
文章围绕 Vitess 在数据管道中的用途展开，先说明 Vitess 更擅长支撑 OLTP，而分析、报表和跨系统同步这类 OLAP/集成场景需要借助 CDC/ETL 来补足。作者重点介绍了 Vitess 的 VReplication 与 VStream 能力：通过 VTGate 暴露统一的变更流，把一个可能由大量 shard 组成的逻辑库抽象成单一数据源。文中进一步解释了 Debezium、Airbyte、Fivetran 等工具如何依赖这些底层原语把 Vitess 的变更传播到数仓或其他系统。文章还给出可运行的本地示例，展示快照、增量变更和分片后的统一流输出，帮助读者理解复制与重分片过程中的事件形态。其边界在于它更偏架构说明和实践入口，较少讨论容错、延迟、乱序等生产级细节。
文中直接给出了 Vitess 的 VStream/VReplication 作为 CDC 基础、以及 Debezium/Airbyte/Fivetran 的对接方式，证据明确且可操作。适合需要在分片 MySQL 上构建同步、数仓或跨系统集成的工程师，迁移价值在于理解“统一变更流+连接器”的实现路径，但生产细节仍需补充验证。
技术文章 PlanetScale Blog 2024/07/23
文章系统梳理了 2024 年 MySQL 在线 schema 变更的主要方案，重点比较了原生 INPLACE、INSTANT 与第三方工具的适用边界。作者指出，INPLACE 虽然在主库上可让 DML 继续执行，但会大量消耗 CPU/IO、占用额外磁盘，并且在复制链路上会把延迟放大到不可接受的程度。INSTANT 在支持范围内几乎“瞬时”完成，且对副本友好，但它主要覆盖元数据级变更，无法处理类型修改、索引/主键/外键变更、字符集和分区调整等常见需求，删除列还带来数据丢失与查询兼容风险。对于大多数真实生产迁移，文章认为 gh-ost、pt-online-schema-change、Vitess、spirit 这类影子表方案仍是更稳妥的选择，因为它们能限速、可中断、兼容更多 DDL，并且 Vitess 还把可回滚性作为一等能力。整体结论是：能用 INSTANT 时优先用，但面向绝大多数复杂迁移，第三方在线 schema 工具仍是主流答案。
文章直接对比了 MySQL 原生 DDL 与第三方在线迁移工具的行为、成本和失败边界，给出了明确的选型依据，而不是泛泛介绍功能。适合负责数据库架构、上线变更和可靠性治理的工程师参考，尤其能迁移到“如何判断某个 schema 变更该不该用原生 DDL”的决策场景。
工程实践 PlanetScale Blog 2024/07/22
这篇文章复盘了 Vitess 查询规划器中的一次聚合优化：一个包含 join、group by 和 order by 的查询因为无法把聚合下推到 MySQL，导致 VTGate 需要拉取大量数据并可能触发 OOM。作者先分析初始计划和树重写过程，说明 ordering under aggregation 过早执行时会把排序卡在 join 上游，从而阻断聚合下推。随后他利用规划器的阶段机制，延后该重写器直到 split aggregation 阶段，再让聚合穿过 join 下推到各个分片。最终 VTGate 只需合并各分片返回的部分聚合结果，而不是承担全量数据排序和聚合。文章的边界也很明确：该优化依赖重写阶段的时机控制，属于规划器内部顺序与算子可交换性之间的权衡。
文中给出了真实的 OOM 问题、初始执行树、重写前后计划和最终下推结果，是典型的数据库查询优化工程案例。适合做查询规划器、分布式 SQL 引擎和算子重写设计的参考，尤其对需要处理聚合下推与阶段控制的读者很有迁移价值。
技术文章 PlanetScale Blog 2024/07/10
文章以一个健身应用中的 exercise_log 大表为例，解释为什么少数高增长表会先成为数据库瓶颈：写入频繁、历史数据持续被查询，最终把存储、内存和 IO 都推到极限。作者先讨论纵向扩容，即通过增加 CPU、内存和磁盘来延长单机数据库的可用寿命，但指出当数据达到多 TB 时，成本和资源争用会迅速上升。接着介绍垂直分片，把大表从主库中拆出到独立 keyspace，并借助 Vitess 的 MoveTables 平滑迁移和切流，使主业务表与日志表可以分别扩展。最后给出水平分片方案：按 user_id 做哈希分布、使用 sequence 生成全局 ID，再通过 Reshard 把单表扩到多个 shard。文章还总结了分片带来的吞吐提升、备份加速、故障隔离和成本优化，同时提醒分片键选择会直接影响查询局部性和性能。
推荐收录，因为文章明确给出了大表扩容的三级演进路径，并直接展示了 Vitess 的 MoveTables、Reshard 和分片键设计等可操作证据。适合做数据库架构、MySQL 扩容和日志/消息类大表治理的参考，但读者需要结合自身读写模式谨慎选择分片键。
技术文章 PlanetScale Blog 2024/07/08
这篇文章系统介绍了数据库分片的三种常见策略：directory/lookup-based、range-based 和 hash-based，并用示例说明它们如何根据 shard key 将数据分散到不同分片。作者分别分析了每种方法的优缺点：目录式分片便于按业务规则精确路由，但依赖额外的查表步骤，且容易因数据倾斜或热点访问造成单分片压力；范围分片实现直观，但如果范围划分不合理，很容易出现分布不均，需要通过 reshard 调整；哈希分片通常能获得更均匀的数据分布，代价是要做哈希计算，并且仍需谨慎选择高基数且符合访问模式的 shard key。文章还强调，分片方案不是点击按钮即可完成，真正落地时要结合数据分布、访问模式和后续扩容计划一起考虑。PlanetScale 的倾向是把 hash-based 作为默认选择，因为它通常最均衡、复杂度也更低，但这并不意味着它适合所有场景。
文章直接给出了三类分片策略的机制、优缺点和适用边界，属于数据库扩展的基础参考，而不是单纯的产品介绍。适合正在设计 MySQL/分库分表方案、评估 shard key 或做容量规划的读者阅读。
技术文章 PlanetScale Blog 2024/04/29
文章系统解释了 Vitess 的 Vindex 机制，重点聚焦于一致性查找 Vindex（consistent lookup vindex）如何在分片数据库中兼顾路由效率与数据一致性。作者先说明普通 lookup vindex 通过维护二级索引表，把查询从全分片扫描收敛到单分片命中；随后进一步指出，若主表与索引表分属不同分片，直接做跨分片事务会引入昂贵的 2PC。为此，Vitess 采用 Pre、Main、Post 三条连接按固定顺序提交/回滚，并通过加锁与事务编排来处理插入、删除、更新中的一致性问题。文章用删除后残留 orphan row、再次插入触发唯一键冲突等例子说明：即使 lookup 表短暂不一致，查询结果仍能保持与主表一致。它也明确了边界与限制，例如同值更新会产生锁等待，且同一事务内先删后插仍可能遇到该问题。
文章直接给出了 Vitess 一致性 lookup vindex 的提交顺序、锁定策略和失败恢复例子，属于可复用的分片一致性设计经验。适合做分库分表、MySQL 分片路由或数据库中间件设计参考，但其细节强依赖 Vitess 语义，落地时需注意同值更新和同事务删插的限制。
技术文章 PlanetScale Blog 2024/04/24
这篇文章系统解释了 MySQL InnoDB 中的自适应哈希索引（AHI）是如何在 B-tree 索引之上再加一层内存加速的。作者先回顾了 B-tree、InnoDB buffer pool 和普通哈希查找的差异，说明 InnoDB 虽然不支持磁盘上的 HASH 索引，但会在运行时为高频访问的索引值或前缀构建 AHI 条目，把键映射到 buffer pool 中的数据位置。文章还说明 AHI 会根据访问模式和 buffer pool 命中情况自动增减，适合重复查同一批热点值的场景，不适合缓存很小或数据访问很分散的负载。通过 3.9 亿行表上的基准测试，作者展示了开启 AHI 后约 16% 到 20% 的 QPS 提升，并用 InnoDB 状态输出验证了哈希搜索确实被使用。结论强调：AHI 不是通用银弹，但在高并发、热点明显且索引较深的系统中，哪怕单次收益不大，也可能显著影响整体延迟和服务器容量。文章的边界也很清楚：收益高度依赖工作负载、buffer pool 大小和重复访问模式。
推荐收录，因为文章不仅解释了 AHI 的工作机制，还给出了 buffer pool、哈希命中统计和真实基准测试结果，能帮助读者判断它为什么快、何时有效。适合做 MySQL/InnoDB 性能优化、热点查询分析和存储引擎原理参考；但收益强依赖访问模式，不能把文中的提升直接外推到所有业务。
工程实践 PlanetScale Blog 2024/04/17
文章介绍了 PlanetScale 新增的 global replica credentials：用户只需一套复制库密码，即可在全球范围内自动路由到最近的只读副本，并在同一区域内对多个 replica 做负载均衡。作者说明了其默认拓扑是一个 primary 加多个跨可用区 replica，而新凭据可以在新增或删除只读区域时自动更新路由，无需修改应用代码或重新连接。文中进一步拆解了 PlanetScale Global Network 的工作方式：在边缘层终止 MySQL 与 TLS、进行连接池化，并通过低延迟 DNS 选择就近入口。实现上把 Credential、Route 和 Endpoint 分离，Route 由 etcd 监听并按实时延迟排序，从而把下一跳决策稳定地落到最优副本。该方案的价值主要体现在跨地域读扩展和连接管理简化上，但也明显依赖 PlanetScale 自身的全局网络与内部路由体系，通用性受平台约束。
文中给出了凭据、路由、端点三层拆分，以及边缘终止 MySQL/TLS、按延迟排序副本的具体实现证据，不是简单的产品宣传。适合做数据库代理、跨地域读扩展和连接层设计的参考，但迁移时要注意它强依赖 PlanetScale 的全局网络基础设施。
工程实践 PlanetScale Blog 2024/04/04
文章介绍了 PlanetScale 如何把数据库 schema 变更做成一套可自动化、可回滚、对线上流量友好的工程流程。核心思路是把代码发布与 schema 迁移解耦：应用代码和数据库结构不再要求原子同时上线，而是要求双方都能兼容当前与未来版本。实现上，他们利用 Vitess 的在线 schema change 和 PlanetScale 的 safe migrations，在不阻塞生产流量的前提下执行变更，并通过队列保证多人并发修改时的顺序与组合安全。为了适配自家 Rails 应用，团队还用 GitHub Actions 写了拉取请求机器人，自动识别 schema 变化、创建分支、运行迁移、发起 deploy request，并根据变更类型给出前后置部署顺序建议。文章的边界也很明确：这套流程强依赖在线迁移工具和应用侧的向后兼容设计，适合中大型数据库和频繁发布团队，简单项目未必需要如此复杂。
文中直接展示了从 PR 检测、迁移执行到队列合并的完整 schema 变更流水线，并明确说明了为何要把代码与数据库发布解耦。对使用 MySQL/Vitess、需要高频改表或想减少迁移阻塞的团队，这是一篇可直接借鉴的工程实践。
技术文章 PlanetScale Blog 2024/03/29
这篇文章系统介绍了如何用 MySQL 原生能力定位并剖析性能异常查询，适合在大规模数据库和复杂业务负载下做问题排查。作者先从 performance_schema 的 events_statements_summary_by_digest 入手，借助 avg_timer_wait、count_star 等指标找出高代价语句，再结合 sys 库中的 statements_with_runtimes_in_95th_percentile、statements_with_full_table_scans 等视图，从“慢查询”和“全表扫描”两个角度缩小范围。随后文章用 EXPLAIN ANALYZE 展示如何根据执行计划中的 cost、rows、table scan 和索引回表路径判断瓶颈是否来自索引缺失或 SQL 改写空间。最后通过开启 instruments、consumers 和 history 记录，利用 stage 历史表拆分一次查询在执行、优化、加锁等阶段的耗时，并提醒这些监控手段会带来一定开销，需要按需选择范围。文章也提到 PlanetScale Insights 可将同类分析可视化自动化，但核心方法仍然适用于原生 MySQL 环境。
推荐收录，因为文章直接给出了 performance_schema、sys、EXPLAIN ANALYZE 和 stage profiling 的完整排查链路，而不是停留在“查慢 SQL”的泛泛建议。它特别适合 DBA、后端和平台工程师在生产环境中定位索引缺失、全表扫描和执行阶段耗时问题，方法可迁移性强，但需要注意 profiling 本身有一定开销。
技术文章 PlanetScale Blog 2024/03/19
本文系统解释了 UUID 各版本的结构差异，并将讨论重点落在 MySQL 中把 UUID 作为主键时的代价。作者通过 B+Tree 索引、页分裂和 InnoDB 页填充机制说明：随机 UUID 会打乱主键顺序，导致插入时更频繁地重平衡索引，从而拖慢高写入场景的性能。文章进一步指出，UUID 以字符串形式存储会显著放大主键和二级索引体积，即使用 BINARY(16) 也仍比自增整数更占空间。针对这些问题，作者给出几类缓解方案，包括改用二进制存储、采用有序 UUID 版本（如 v6/v7）、利用 MySQL 的 UUID_TO_BIN swap flag，或直接选择 Snowflake、ULID、NanoID 等替代 ID 方案。整体结论是：UUID 能提升分布式唯一性，但在 MySQL 中并非默认的最优主键选择，是否采用应结合写入模式、索引数量和存储成本综合判断。
推荐收录，因为文章不仅说明“UUID 不适合当主键”的结论，还用 B+Tree、页分裂、二级索引膨胀和页利用率等机制给出直接证据。适合做数据库设计、主键选型和性能排障的长期参考，尤其对需要在分布式唯一性与写入性能之间权衡的工程场景很有迁移价值。
工程实践 PlanetScale Blog 2024/02/28
文章介绍了 PlanetScale Insights 新增的 Schema recommendations 功能，目标是基于生产流量自动给出可直接执行的 MySQL 架构优化建议。作者说明系统如何结合表结构变更事件、近期查询表现、Vitess 解析器和列基数统计，生成索引、冗余索引清理、主键 ID 耗尽预警和未使用表删除等建议。其核心特点是把推荐结果以 DDL 形式输出，并支持先在分支上验证，再安全发布到生产。文中还给出新增索引的完整示例，展示了随着数据量增长，p50 延迟上升后如何通过推荐索引显著降低查询时间。需要注意的是，这类建议依赖近期查询与统计信息，仍需结合业务语义、写入成本和迁移风险人工评估。
文章不仅是功能发布，还给出了推荐系统的判定信号、实现链路和落地流程，尤其包含查询解析、基数估计与分支验证这些可迁移的工程细节。适合做数据库性能优化、自动化运维和架构诊断的参考，但读者仍需结合自身业务负载与迁移约束来使用这些建议。
工程实践 PlanetScale Blog 2024/02/15
这篇文章系统拆解了 Amazon Aurora（以 MySQL 工作负载为主）的计费构成，指出它远不只是“选个实例”这么简单，而是要同时评估实例规格、预留实例折扣、副本数量、存储模式、跨可用区/跨区域流量、备份保留、监控和代理层等多项费用。作者特别说明了 burstable 与 memory-optimized 的差异、标准存储与 I/O-optimized 的取舍，以及当 I/O 费用占比超过一定阈值时，I/O-optimized 才可能更划算。文章还把读写副本、Global Database、RDS Proxy、蓝绿部署、自动备份和 Performance Insights 逐项拆开，说明这些“高可用/可运维能力”往往会直接放大账单。最后，文章以 PlanetScale 的定价和托管能力作对比，强调其在连接池、跨区复制、变更管理和监控上的简化与打包，但整体内容对 Aurora 成本建模尤其有参考价值；局限在于只覆盖 Aurora 非 Serverless 场景，且比较部分带有明显产品立场。
推荐收录，因为它不是泛泛介绍云数据库，而是把 Aurora 的主要成本项逐条展开，给出了实例、副本、I/O、流量、备份和监控的实际计费视角。适合做数据库选型、云成本估算和高可用架构评审时参考，但读者也需注意文中 PlanetScale 对比部分存在产品宣传倾向。
技术文章 PlanetScale Blog 2024/02/13
这篇文章围绕 MySQL 数据库设计中的三个常见错误展开：字段类型选得过小或过大、索引缺失或冗余、以及半结构化数据存储方式不当。作者用一个车联网系统的真实案例说明，ID 列早期采用 INT 可能在业务增长后迅速逼近上限，最终甚至会威胁线上可用性；同时也举了 VARCHAR 过短导致写入失败、字段类型过宽造成额外存储浪费的例子。针对索引，文章解释了缺少索引会让大表查询退化为全表扫描，而过多或重复索引又会增加存储和写入维护成本。对于 JSON 数据，作者强调应优先使用 MySQL 原生 JSON 类型，而不是用 TEXT 直接存字符串，因为前者支持更高效的二进制存储、按字段查询和基于 JSON 内容建索引。结尾还提到通过把有符号整型回绕到负数区间临时扩容 ID 的权宜之计，并指出数据库设计必须结合增长预估和业务边界来权衡。
文章给出了字段类型、索引和 JSON 存储三个维度的具体反例与后果，不是泛泛而谈，而是能直接指导 MySQL 表结构设计和性能排查。适合后端开发、DBA 和做系统容量规划的读者参考，尤其对需要在增长、存储和写入成本之间做取舍的场景很有迁移价值。
工程实践 PlanetScale Blog 2024/02/02
文章以 Amazon Aurora 的 blue/green deployment 与 PlanetScale 的 branching 为主线，对比两种“复制环境后再切换”的数据库变更方式。它先解释 Aurora 如何通过克隆集群、binlog 同步和 switchover 完成维护，再说明 PlanetScale 基于 Vitess 的分支本质是独立集群，借助 deploy request、ghost table 和滚动升级来实施 schema 变更与版本升级。文中进一步比较了成本、回滚、数据一致性和停机时间：Aurora 切换会断连且无法直接 fail back，双环境并行成本较高；PlanetScale 则强调在线迁移、Schema revert 和更强的隔离性，但依赖 safe migrations 与 Vitess 能力。整体结论是，两者虽然表面相似，但目标不同，Aurora 更偏维护窗口控制，PlanetScale 更偏持续在线变更。需要注意的是，这是一篇厂商视角的对比文，缺少独立 benchmark 和第三方验证。
文中直接给出 binlog replication、ghost table、rolling upgrades、Schema revert 等机制差异，信息足以支撑数据库变更方案选型。适合做平台工程、数据库运维和迁移设计的参考，但需意识到它带有明显厂商立场，结论应结合独立验证。
工程实践 PlanetScale Blog 2024/01/30
文章围绕数据库灾难恢复（DR）方案的构建展开，先区分了高可用（HA）与灾难恢复的目标：前者强调通过复制和自动故障切换尽量不中断服务，后者强调在重大故障后尽快恢复业务。作者进一步解释了 RPO 与 RTO 的含义，并指出两者越小，恢复方案的复杂度和成本越高，因此必须结合业务可承受的数据损失和停机时间来设定。文章特别强调数据库是有状态系统，不能像无状态应用那样简单替换实例，因此备份、复制和恢复流程都需要按数据一致性来设计。随后对 MySQL 复制、异步/半同步模式、逻辑/物理备份、全量/增量备份及其性能影响做了说明，指出跨区域复制和在副本上执行备份更适合降低恢复时间和主库负载。最后给出一套可落地的 DR 规划建议，包括分级恢复优先级、用收入损失衡量停机成本、自动化恢复、定期演练以及验证备份可恢复性，适合构建面向生产环境的数据库韧性方案。
文章直接给出了数据库灾备规划的关键证据：RPO/RTO 设定、复制与备份策略、跨地域恢复、自动化和演练验证，内容不是泛泛而谈。适合负责 MySQL、云上基础设施或生产稳定性的工程师参考，尤其可迁移到任何有状态系统的容灾设计中。