技术文章 DuckDB Engineering Blog 2026/11/10
文章以 DuckDB 的列式存储为线索，解释分析查询为何只需读取命中的列，并串联起文件原地查询、通配符与 Hive 分区、投影/分区裁剪、列级 SQL、聚合快捷语法、窗口函数与 QUALIFY、ASOF JOIN，以及写出高压缩 Parquet 的排序、分区、窄类型和 EXPLAIN ANALYZE 验证。核心结论是让查询只读取所需列和值，可同时减少 I/O、提升压缩率并利用 zonemap 跳过数据块。文中示例具体、可操作，适合作为 DuckDB/SQL 分析实践参考；但内容偏官方特性导览，主要覆盖 DuckDB 方言和 Parquet 场景，对底层内核实现与其他数据库的差异讨论有限。
推荐收录：文章把列式存储原理与 DuckDB 的原地查文件、列级 SQL、聚合/窗口/ASOF、Parquet 分区排序等具体用法对应起来，并用 EXPLAIN ANALYZE 展示投影裁剪和分区跳过，证据充分。适合做数据分析、ETL 或本地/湖上查询的工程师作为可迁移的 SQL 与文件组织参考；风险是 DuckDB 方言和产品特性较强，跨数据库迁移时需注意等价语法与底层差异。
技术文章 ClickHouse Engineering 2026/11/06
文章是 ClickHouse 26.10 版本发布说明，但并未停留在变更列表，而是用 SQL 示例解释函数组合运算符、写入行数配额、数组/Map 新函数、SQL 兼容整数除法、IN 子查询落盘、LowCardinality GROUP BY 优化、Top-K 动态过滤、实验性列缓存、LATERAL JOIN 和任意 ON 条件 JOIN 等功能。作者结合 UK 房产、IMDb 与 Amazon 评论数据集，给出耗时、读行数和峰值内存对比，说明优化收益及启用参数。文中也标注了实验特性、默认关闭项、依赖 wide part 或主键等适用边界。其价值集中在 ClickHouse 版本升级评估和查询调优参考，属于版本相关技术说明而非通用数据库理论。
推荐收录：文章虽为版本发布稿，但包含函数组合重写为 lambda、IN 集合落盘、Top-K 动态过滤与列缓存等机制说明，并配有可复现的 SQL 和性能数据。对正在使用或评估 ClickHouse 的数据库工程师、数据平台开发者有直接参考价值；需注意其结论绑定 26.10 版本和特定数据集，不能外推为通用性能结论。
工程实践 TiDB 社区博客 - 实践案例 2026/11/05
文章复盘一条订单查询从 MySQL 迁到 TiDB 后变慢的排查过程：查询按 status 与 created_at 过滤并按时间倒序取 20 条，作者起初加联合索引却无效。改用 EXPLAIN ANALYZE 后，他发现优化器走 TableFullScan、扫描约 120 万行；根因是统计信息过期，使 CBO 误判索引回表代价。执行 ANALYZE TABLE 后计划改用索引，耗时从约 2 秒降到 80 毫秒；文中还提醒大表可采样分析，并介绍执行计划绑定作为兜底。最后作者对比 MySQL 的局部修补与 TiDB 先看全局计划的思路。该案例具体但属单点入门经验，未展开完整基准和 binding 语法细节。
推荐收录：文章用可复现的排查链条说明 TiDB 调优不能只靠加索引——从 EXPLAIN ANALYZE 定位 TableFullScan，到检查统计信息并用 ANALYZE TABLE 验证，再到 plan binding 兜底，路径清晰。适合使用 TiDB 或分布式数据库的后端、DBA 读者借鉴；但只是单案例入门经验，正式 binding 命令和基准数据缺失，不能替代系统化优化手册。
工程实践 ClickHouse Engineering 2026/10/28
文章介绍 ClickHouse 新成本模型连接优化器：用 DPsub 动态规划枚举表子集，在既有成本模型下为最多 10（可调至 12）张表的查询寻找更优连接顺序，并将在 26.10 默认启用。核心创新是引入基于 SIGMOD 2013 核心搜索空间的冲突检测器，按交换律、结合律等规则把 LEFT/RIGHT/FULL、SEMI/ANTI 连接纳入重排且保证结果不变。文章用 280 万候选计划零无效/零遗漏、1200 条随机查询零结果不一致验证正确性，并在 TPC-H/TPC-DS 上报告 25%–55% 加速，半连接下推示例中间结果缩小约 496 倍。边界是超过 12 表回退贪心优化器，收益依赖成本模型与统计信息，运行时连接过滤会削弱部分排序收益。
推荐收录。文章不仅说明新优化器的启用方式，还完整给出 DPsub 搜索、冲突检测器的代数规则、正确性/完整性验证、差分 fuzz 和 TPC-H/TPC-DS 实测，属于可复核的系统实现经验。适合数据库内核、查询优化与 OLAP 性能方向的读者，其把论文算法工程化并建立验证闭环的方法可迁移到其他优化器项目；但需注意结论受 ClickHouse 成本模型和 12 表搜索上限约束。
工程实践 SelectDB 技术分享
文章介绍 Apache Doris 与 Lance 结合中的延迟物化（两阶段读取）优化：先用距离、分数及必要过滤列完成候选筛选和全局 TopN，再依据固定快照与 Lance 原生行 ID 批量回读仅用于输出的宽列。文中拆解了优化器如何判断列依赖、裁剪投影并保留隐藏行定位信息，以及分布式执行中如何按 BE 分组、去重、回读并恢复结果顺序。作者用 1.04 亿行、三组向量检索查询做开关对照，首次执行加速约 4.74～6.29 倍，重复执行最小耗时加速约 6.49～6.64 倍。文章也明确收益模型只覆盖可延迟输出列的逻辑数据量，实际收益受候选数、列宽、读放大、缓存、回读 RPC 和 ANN 计算等影响，适合宽列输出且 Top-K 远小于候选数的检索场景。
推荐收录。文章不仅给出“6 倍”结果，还完整展示了延迟物化在查询优化器、分布式执行和存储回读三层中的实现路径，并附有可复现的实验配置与收益边界。对数据库/OLAP 查询优化、向量检索系统和湖仓性能工程读者有较高迁移价值；但需注意数据来自厂商内部测试，实际部署应结合自身数据分布和瓶颈复核。
工程实践 SelectDB 技术分享 2026/10/27
文章解析 Apache Doris 与 Lance 的延迟物化（两阶段读取）优化：先只读检索、过滤和排序所需列，TopN 后按行定位批量补齐宽输出列。内容覆盖优化器列依赖判断、投影裁剪、隐藏行定位，以及分布式执行中的固定快照、分组回读、去重和顺序恢复。1.04 亿行实测中，三组向量检索查询首次加速 4.74～6.29 倍，重复执行最小耗时加速 6.49～6.64 倍。收益来自减少落选候选的宽列读取、解码和传输；但逻辑数据量不等同真实下载量，输出列窄或瓶颈在 ANN/精排时收益有限。
推荐收录。文章不仅给出约 6 倍加速结论，还拆解了优化器列依赖判断、隐藏行定位、固定快照回读和分布式结果重组等关键实现，并说明适用与不适用场景。对做 OLAP、向量检索或查询引擎优化的读者，两阶段读取思路和性能验证方法可直接迁移；需注意数据来自厂商内部环境，具体倍数不宜外推。
工程实践 PlanetScale Blog 2026/10/14
文章介绍 PlanetScale 分片 Postgres 系统 Neki 如何在分布式查询规划器中实现 Postgres sequences，重点是 volatile 表达式与跨分片同步求值。作者区分 immutable、stable、volatile，指出 now() 等 stable 表达式受 GUC 影响，而 nextval() 等序列操作必须由 router 集中执行，避免分片重复发号。文章用 table expression 和行基数说明 volatile 表达式必须按最终结果行逐行求值，不能因 join 复制而少算；工程上 Neki 尽量下推 immutable 表达式，对 UPDATE 场景先取主键/分片键并 FOR UPDATE，再逐行生成序列值下发。文章未覆盖序列 reset/cycle、全部优化器决策和更复杂 DML，且 join 顺序可能导致含 volatile 谓词的结果不总确定但语义正确。
推荐收录，因为文章以 Neki 的真实查询规划器为对象，给出了 volatile 表达式、table expression、行基数和 nextval() 跨分片协调的具体机制，并展示 UPDATE 场景下的锁与逐行下发方案。对分布式数据库、查询优化器和 Postgres 兼容层实现者而言，这些约束、取舍和实现证据具有直接迁移价值；文章也明确说明 join 顺序与序列 reset/cycle 等边界，避免读者误用。
技术文章 DuckDB Engineering Blog 2026/10/13
本文以 DuckDB 的 iceberg 扩展为例，拆解 Apache Iceberg 表的磁盘结构：顶层 metadata.json、每快照一个 Avro manifest list、若干 manifest，以及底层 Parquet 数据文件和删除文件。作者用本地 REST catalog 创建按日期分区的示例表，执行两次插入和一次删除，再用 SQL 逐层读取，展示 snapshot 演进、摘要计数、manifest 内容、列统计与分区统计。核心结论是 Iceberg 文件不可变、提交只移动 catalog 指针，删除采用 merge-on-read 的 position delete 文件，统计信息用于跳过文件和分区。文章也提醒小提交与删除文件过多会拖慢查询，并说明 summary 字段可选、format-version 3 的 Puffin 删除向量未展开。
推荐收录。文章给出了可复现的 SQL 步骤，从 catalog 指针一路查到 manifest、列/分区统计和 position delete 文件，直接证据充分，能帮助数据工程师在查询变慢、行数异常或跨引擎写表时定位 Iceberg 表内部原因。其文件树、快照提交与统计跳过机制可迁移到 Iceberg 表布局审查和性能诊断；局限是示例较小且依赖本地 fixture，未覆盖所有引擎差异。
技术文章 DuckDB Engineering Blog 2026/10/02
文章以 DuckDB 铁路站点数据为例，解释对重复长字符串做 GROUP BY 为何昂贵：哈希聚合需逐行哈希、比较并复制完整字符串，使哈希表变宽、缓存命中变差并可能提前落盘。作者提出维度表模式：先统计字符串基数，按字符串排序生成最窄无符号整数键，重写事实表为整数键，聚合后再回连维度表取字符串。聚合因此只处理定宽整数，小稠密键域可触发 perfect hash aggregate，排序键也保持字母序与确定性。文中还比较 ENUM、多字符串列与增量更新，并指出窄键无法减少高基数并发聚合的分组数，短字符串、近唯一列、一次性查询等场景不适用。适合数据库与数据分析从业者参考。
推荐收录。文章来自 DuckDB 工程博客，以真实查询模式给出可复现的维度表编码步骤、性能机制解释和适用边界，并包含 ENUM 对比与高基数并发聚合的反例。对数据库内核、查询优化和数据分析工程师而言，其中“窄整数键聚合、结果集回连维度表”的方法可直接迁移到重复长字符串的 GROUP BY 优化，同时文末的不适用清单能避免盲目套用。
工程实践 Datadog Engineering 2026/10/01
Datadog 为统一查询栈，选择 Arrow 作为内存格式、Substrait 作为执行计划格式、Apache DataFusion 作为可组合查询引擎，但 DataFusion 只能在单机执行查询，无法支撑其最大的交互式负载。为此团队开发了开源 Rust 框架 Distributed DataFusion，仅作用于物理计划层，复用 DataFusion 分区模型并把分区扩展到多机，引入 stage、task、DistributedLeafExec 等概念，以及 NetworkShuffle、NetworkCoalesce 等节点完成跨机重分区与结果汇聚，支持分区连接、广播连接、分布式 union 和树形归约聚合。文章给出在 12 节点 c5n.2xlarge 集群上基于 TPC-H/TPC-DS（1GB–100GB）与其他引擎的对比，并说明生产中重查询最高提速 10 倍，而计划器会在分布收益不足时让轻查询留在单机。作者还解释了为何放弃 ClickHouse、Spark、Ballista、Trino：需要的是可扩展框架而非完整引擎，且必须低延迟、零拷贝、与 Arrow/Substrait 及自有网络栈集成。其边界在于面向交互式低延迟场景，而非后台容错批处理作业。
推荐收录：文章基于真实生产约束（低延迟交互式查询、DataFusion 单机瓶颈）给出了完整的设计取舍、物理计划改造细节和可复现的 TPC-H/TPC-DS 基准，并明确说明何时不分布。对构建查询引擎、数据基础设施或评估分布式执行框架的工程师，其分区扩展、网络 shuffle/coalesce 机制与引擎选型理由都可迁移参考。
技术文章 SelectDB 技术分享
Doris 4.2 起可在 Iceberg、Paimon 上直接读写 VARIANT 半结构化数据。文章分三层讲解：值由 metadata 字段名字典与 value 二进制编码，可按路径拆成类型子列，类型不匹配的值保留在 residual/fallback；读取按文件与 Row Group 选择叶子投影、残余补齐或完整投影，并结合统计裁剪；执行层保留 Encoded、Typed、Shredded 三种形态并延迟物化，避免重建完整对象。写回时 Iceberg 经 Arrow 生成 Parquet，Paimon 经 JNI 交给原生 writer，当前不回写拆列文件。测试称相比 Spark 冷跑 15.10×、热跑 19.14×，拆列热跑 58.64×，但 SQL 示例未在集群执行。
Doris 团队完整拆解了 Variant 的编码、拆列、按路径读取与延迟物化机制，并给出可观测的 Profile 指标和冷热跑对比数据，可作为湖仓半结构化数据格式设计与查询优化的参考。适合从事 OLAP/湖仓选型、Parquet 列裁剪与执行引擎优化的工程师阅读；需注意性能数字来自厂商自测、不含导入耗时，SQL 示例也未实机验证。
技术文章 Greptime 技术 2026/09/23
文章深入解析 GreptimeDB 1.2 新增的 JSON2 类型，针对传统 JSONB 按整文档存储、分析查询需读取并解析完整 JSON 的问题。其核心是有界自动 shredding：高频路径展开为独立列，并分为静态类型路径、预算内动态路径和 Parquet Variant 余量三层；查询时通过类型具体化从 SQL 推断所需结构类型，类型提示可固定路径类型并拒绝不匹配写入。结论是 JSON2 适合日志、trace 等可观测性场景，能按路径裁剪读取且保留原始嵌套；但冷路径仍需读余量，类型推断可能出错，自动展开有上限，1.2 中修改配置尚未正式支持。
推荐收录：文章不仅介绍功能，还给出 JSONB 与 JSON2 的读写差异、三层存储、类型具体化、类型提示和完整 SQL 示例，并引用 JSONBench 数据说明边界。适合数据库、存储引擎、可观测性平台工程师理解半结构化数据的列式化设计；可迁移到日志/trace 分析中的路径裁剪、列式存储和类型约束设计，但需留意冷路径读取与类型推断错误风险。
技术文章 Greptime 技术 2026/09/23
文章解析 GreptimeDB 1.2 新增的 JSON2 类型，面向日志、Trace 等路径繁多但查询只访问少数路径的 JSON 数据。传统 JSONB 按整文档存储，读一个字段也需扫描和解析完整文档，索引无法消除这类 I/O 与 CPU 放大。JSON2 采用有界自动 shredding，将热路径展开为独立 Parquet 列，长尾写入 Parquet Variant remainder，并支持 type hints 固定类型；查询端通过 query type concretization 从 SQL 推导结构化类型，实现列裁剪与向量化执行。局限是类型推断依赖 SQL 表达式，写错可能返回无意义结果，且 1.2.x 不能修改已有 JSON2 配置。该方案适合可观测性分析，但冷路径仍需读 remainder，自动展开预算默认 100。
推荐收录。文章基于 GreptimeDB 1.2.1 的真实实现，清晰给出 JSONB 整文档读放大、JSON2 有界 shredding、Parquet Variant remainder、query type concretization 与 type hints 的设计细节和 SQL 示例，并明确说明类型推断错误、冷路径成本和 1.2.x 配置不可变等边界。适合数据库内核、存储引擎和可观测性平台开发者参考，其“热路径列化+长尾归并+查询驱动类型推导”的取舍可迁移到其他半结构化分析系统。
工程实践 TiDB 社区博客 - 实践案例 2026/09/04
文章以TiDB生产环境中的三个真实SQL调优案例为主线，展示从“跑不动”到“飞起来”的完整排查过程。第一个案例是因统计信息过期导致优化器误判筛选率，未走联合索引的最优范围，通过ANALYZE和配置自动收集恢复性能；第二个案例是分区表查询因NOW()等非常量表达式导致分区裁剪失效，改写为常量时间后恢复正常；第三个案例是自增主键在聚簇索引下形成写热点，通过AUTO_RANDOM或业务主键加预分裂分散写入。每个案例都给出根因判断、优化SQL和执行计划变化，并总结出先看执行计划、重视统计信息、预防写热点三条方法论，附有诊断命令速查。边界在于案例基于TiDB特定实现，部分结论对传统单机数据库不一定适用。
推荐收录。文章不是零散技巧，而是围绕具体线上问题的诊断链路：现象、根因定位、方案验证和预防措施都写得很清楚，适合TiDB/分布式数据库运维和SQL调优读者。文中关于统计信息、分区裁剪、写入热点的分析方法可迁移到其它分布式或关系型数据库，只是需要结合各自引擎特性试用。
工程实践 DuckDB Engineering Blog 2026/08/25
本文来自 DuckDB 工程博客，介绍了 v2.0 对递归 CTE 执行引擎的重构，目标是消除迭代间重复调度与重建状态的开销。核心方法是将物理算子树、预计算调度投影和可复用执行器池归查询计划所有，递归调用持有跨 epoch 的不变状态（如基于静态表构建的哈希表），每个 epoch 仅重置依赖前沿的状态，并通过精确的边界基数选择内联或并行调度。针对 USING KEY 递归，冻结键控状态以支持直接探测，内连接可用 RECURSIVE_KEY_JOIN 或部分键索引，并引入语义变化：UNION 仅转发最终发生变化的键，UNION ALL 仍转发全部候选。实验显示，在 100 万边可达性查询中延迟从 4.051 秒降至 0.095 秒，LDBC SF100 路径查询提速 6.55 倍且峰值内存下降，63 个递归基准几何均值改善 5.5%。适用边界包括：保留状态需可重复性证明，预聚合要求聚合状态可组合且无顺序依赖，宽唯一键更新场景有约 6% 的回归。
直接证据是作者为 DuckDB 核心开发者，提供了 PR 编号、EXPLAIN 分析与中位数基准对比，且讨论了语义变化与回归。适合数据库内核开发者、查询引擎研究者与对 SQL 递归性能优化感兴趣的读者。可迁移价值在于状态所有权划分、基于实测基数的自适应执行和变更键去重思想；风险是部分语义变更（UNION 改变行为）需使用者注意。
技术文章 ClickHouse Engineering 2026/08/24
文章是 ClickHouse 26.7 版本发布说明，主体是对查询执行与向量检索内部优化的解析。它把按序聚合与新增的 limit 下推融合，使 GROUP BY…ORDER BY…LIMIT 成为可提前终止的流式流水线；JOIN 新增构建键驱动的探测端 granule 裁剪、哈希表行引用压缩与 dpsub 连接顺序算法；QBit 引入 Int8 量化、跨步存储、Hadamard 旋转与量化编解码器。文中用 TPC-H 与 HackerNews 数据集给出基准，称 Top-N 提速 313 倍、峰值内存降 592 倍，JOIN 提速 6.2 倍。还简述短语位置索引、EXPLAIN ANALYZE、Remote 引擎和 URL 统一等特性，并标注部分能力为实验性。
推荐收录：虽为版本发布说明，但每项优化都给出机制解释（如按序聚合与 LIMIT 下推融合、运行期过滤器驱动 granule 裁剪）和可复现的 TPC-H/HackerNews 基准，属于有边界、可验证的工程性能证据。适合数据库内核、OLAP 查询优化与向量检索方向读者；排序键前缀聚合、构建侧过滤下推等思路可迁移。主要风险是性能倍数依赖特定数据集与硬件，不宜直接外推。
技术文章 DuckDB Engineering Blog 2026/08/17
DuckDB v2.0预览文章由核心开发者撰写，概述了即将发布的重大版本的主要特性。文章首先介绍了DuckDB作为服务器的新模式，通过Quack协议和CONNECT语句实现客户端/服务器架构，支持远程查询生产数据库。随后重点讲解了VARIANT类型的深化应用，使其能高效处理半结构化数据，并配合一系列variant_*函数。文章还介绍了触发器、丰富SQL方言（如NEAREST连接、CTE内DML、嵌套schema等）、全引擎异步I/O、大量查询性能优化（如重写递归CTE、聚合下推、分区感知规划）、新存储格式、全新PEG解析器，以及用自研实现替代ICU库带来的体积和性能优势。最后强调了稳定C API和自定义扩展仓库，使扩展编写和分发更加便捷。文章以预览形式呈现，强调细节可能在正式发布前调整，并提到部分破坏性变更。
本文是DuckDB官方工程博客的权威技术预览，内容详实，包含具体代码示例、性能基准和设计动机，展示了嵌入式数据库向客户端/服务器模式演进的关键架构决策。适合数据库内核工程师、数据分析平台开发者和对查询引擎优化感兴趣的读者。文中关于异步I/O、存储格式演进和扩展稳定ABI的设计思想具有可迁移性，但需注意各功能为预览状态，正式发布可能调整。
技术文章 Phil Eaton - databases
文章在 gosql 项目中扩展索引支持，涵盖 PRIMARY KEY 词法解析、红黑树索引创建、插入时索引维护和 SELECT 查询优化。作者使用 GoLLRB 红黑树存储索引项，通过识别 WHERE 条件中可应用索引的模式，先用索引预筛选行再执行过滤。文章分析当前查询计划仅支持 AND 连接和列与字面量比较，不能合并范围条件，且索引并非总是优于线性扫描。基准测试显示 100 万行插入时带索引内存和耗时增加，但等值查询从秒级降至微秒级，体现空间换时间的权衡。
推荐收录，因为文章通过写一个 Go 语言 SQL 数据库的索引模块，完整展示主键约束解析、红黑树索引构建、插入维护和查询预筛选的端到端实现，并给出有/无索引的实测性能对比。适合想理解数据库索引原理、查询规划和存储引擎实现的读者；其简化取舍与限制分析也可作为进一步阅读真实数据库文档与源码的入门桥梁。
工程实践 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 替代方案。需要注意的是测试仅基于单节点和特定数据集，索引列选择需按业务权衡。
工程实践 ClickHouse Engineering 2026/08/11
文章介绍 pg_clickhouse v0.10.0 的更新，重点是扩大 PostgreSQL 查询向 ClickHouse 下推的范围。作者以 TPC-H 为度量，将完全下推的查询从 22 条中的 12 条提升到 16 条；Q17 从 32.7 秒降至 37 毫秒，并快于原生 PostgreSQL 的 2.1 秒。技术核心是把相关子查询与 NOT IN 下推为半连接/反连接，同时用额外空值守卫弥合 PostgreSQL 三值逻辑与 ClickHouse 二值逻辑在 NULL 上的语义差异。工程侧还改用 clickhouse-c 重写 C 驱动，统一 HTTP 与二进制 Native 协议，修复并发扫描连接冲突，并扩展统计聚合、有序集聚合和分区聚合下推。文章明确仍剩 6 条 TPC-H 查询未下推，受限于 join tree 两侧遍历，且相关子查询要求 ClickHouse 25.8 以上，否则回退本地执行。
推荐收录：文章不仅列出 pg_clickhouse 新功能，还给出可验证的 TPC-H 性能改进（Q17 32.7s→37ms）、三值/二值逻辑差异导致的正确性陷阱及守卫实现，以及驱动层从 C++ 到 C 的架构权衡和并发修复。对使用 PostgreSQL FDW、构建异构数据库查询下推、OLAP 加速或数据库扩展开发的工程师具有直接参考价值，其语义兼容性验证思路可迁移到其他数据源集成场景。
工程实践 Crunchy Data Blog 2026/07/30
文章系统探讨了在PostgreSQL和pgvector中实现混合搜索（向量相似度加标量过滤）的工程模式。首先阐述了pgvector迭代索引扫描如何平衡召回与性能，然后分析了向量优先和标量优先两条路径各自的适用场景与局限。作者进一步提供了三种实用工作区：为低基数过滤构建部分HNSW索引；通过过采样再过滤应对高基数或临时过滤器；以及利用缓存加速重复查询。文中给出了过采样的估算公式、查询计划诊断方法以及各方案的决策指南，并强调了每种模式在召回率、性能和维护成本之间的权衡。
推荐收录，因为本文是针对Postgres+pgvector混合搜索问题的实战指南，从问题根源到四种解决方案给出了完整的权衡分析、代码示例和调优公式，远超简单教程。适合正在构建带标量过滤的向量搜索系统的工程师，文中部分索引、过采样和缓存等模式可直接应用于生产环境，决策树和EXPLAIN诊断方法具有跨场景的可迁移价值。
技术文章 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/13
文章记录了一次 PostgreSQL 生产事故：在没有代码或流量变化的情况下，数据库 CPU 飙升，查询延迟从毫秒级恶化到约 10 秒。通过监控工具定位到一个特定查询模式，发现其执行计划突然放弃索引而进行全表扫描。根因在于 PostgreSQL 查询优化器基于统计信息生成计划，而数据增长导致统计信息演变，使得优化器在罕见情况下选择次优计划。团队临时使用 Database Traffic Control 立即拦截该查询以恢复数据库健康，随后在安全环境通过 EXPLAIN 分析计划变化，并提出长期修复方案，包括执行 ANALYZE 刷新统计、调整索引或重写查询。文章展示了从发现现象、定位根因、应急止损到永久修复的完整工程流程，并点明查询计划不稳定的普遍风险与应对思路。
这篇文章是典型的数据库性能事件复盘，有明确的故障现象、诊断过程（延迟关联、计划变化对比）和分级应对方案。它不仅展示了应急响应手段，还解释了 PostgreSQL 优化器行为的技术背景，为 DBA 和开发者在类似场景下快速识别和修复计划退化提供了可迁移的经验。文中虽有产品功能描述，但技术分析独立且扎实，适合作为数据库稳定性实践案例收录。
技术文章 Crunchy Data Blog 2025/12/04
这篇文章以 Postgres 的 EXPLAIN 输出为切入点，系统讲解了常见扫描类型及其适用场景，帮助读者从执行计划中判断查询为何快或慢。文章依次解释了顺序扫描、索引扫描、位图索引扫描与位图堆扫描、并行顺序扫描、并行索引扫描以及索引仅扫描，并配合真实的 EXPLAIN ANALYZE 示例展示各自的计划形态和指标。作者不仅说明了这些扫描方式的工作机制，还强调了优化器的选择逻辑，例如小表、返回比例较高或需要随机访问过多时，顺序扫描可能优于索引扫描。对于索引仅扫描，文章进一步讨论了覆盖索引带来的收益，以及写放大、索引体积和适用列数等边界条件。整体上，这是面向 PostgreSQL 性能排查与执行计划阅读的实用入门，但内容仍以常见扫描类型为主，未深入展开代价模型或更复杂的连接/排序计划。
文章直接给出了多种 EXPLAIN 扫描节点的真实输出和判读方法，适合做 PostgreSQL 性能排查、SQL 优化和执行计划入门参考。它的可迁移价值在于帮助读者建立“选择哪种扫描方式、为什么会选它”的心智模型，但内容主要覆盖基础扫描类型，深层优化仍需结合具体工作负载。
工程实践 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/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/09
文章记录作者在 PlanetScale 实习期间，为 Vitess 查询规划器设计随机 SQL fuzzing 的过程。团队先评估了 SQLancer，但由于 Vitess 需要尽量模拟 MySQL 且受 VSchema、分片键等约束，直接接入成本过高，最终转向自建生成器。生成器会从给定表集合中随机抽取表、列和表达式，覆盖 SELECT、WHERE、GROUP BY、ORDER BY、LIMIT 及派生表等场景，并把 Vitess 与 MySQL 的结果和错误逐条比对。作者还改造了查询简化器，使其能处理端到端测试所需的 VSchema 信息，并扩展表达式生成以支持列引用和受语义限制的聚合表达式。文章最后指出当前样例表和分片方案仍较固定，且部分已知失败查询依赖过滤开关，后续可通过随机化 schema/VSchema 和清理代码继续提升覆盖率。
收录理由明确：文章给出了在数据库查询规划器上做 fuzzing 的具体实现、与 SQLancer 的取舍、以及查询简化器和表达式生成器的改造细节。适合做数据库测试、查询优化器或模糊测试实践参考；其局限也清楚，当前覆盖仍受固定 schema 和分片模型限制。
技术文章 PlanetScale Blog 2024/02/13
这篇文章围绕 MySQL 数据库设计中的三个常见错误展开：字段类型选得过小或过大、索引缺失或冗余、以及半结构化数据存储方式不当。作者用一个车联网系统的真实案例说明，ID 列早期采用 INT 可能在业务增长后迅速逼近上限，最终甚至会威胁线上可用性；同时也举了 VARCHAR 过短导致写入失败、字段类型过宽造成额外存储浪费的例子。针对索引，文章解释了缺少索引会让大表查询退化为全表扫描，而过多或重复索引又会增加存储和写入维护成本。对于 JSON 数据，作者强调应优先使用 MySQL 原生 JSON 类型，而不是用 TEXT 直接存字符串，因为前者支持更高效的二进制存储、按字段查询和基于 JSON 内容建索引。结尾还提到通过把有符号整型回绕到负数区间临时扩容 ID 的权宜之计，并指出数据库设计必须结合增长预估和业务边界来权衡。
文章给出了字段类型、索引和 JSON 存储三个维度的具体反例与后果，不是泛泛而谈，而是能直接指导 MySQL 表结构设计和性能排查。适合后端开发、DBA 和做系统容量规划的读者参考，尤其对需要在增长、存储和写入成本之间做取舍的场景很有迁移价值。