DBA晨报·第31期｜PostgreSQL列存引擎性能飙升10倍、达梦DM9正式发布、Xata开源分支化Postgres平台

📊 HiddenMerit Daily · Issue 42 Focus on Database Frontiers, Practical Insights for DBAs June 12, 2026 ｜ 5 Selected Global Breaking News 01｜AI Reshapes the Underlying Logic of Databases: Industry Evolves from “Warehouse” to “Intelligent Infrastructure” On June 11, Xinhua Finance published an in‑depth report titled “AI Reshapes the Underlying Logic, Databases Ride the Wind Again.” The report points out that when enterprises no longer just ask “can we store the data,” but “can large models directly use my data to answer questions,” databases – seemingly mundane foundational software – are once again riding the wind. Core Views: Agents are the New Users: Wang Yicheng, Vice President of Tencent Cloud, stated that the industry is redesigning database product capability systems with agents as the new users, and the database industry is entering the AI 3.0 era. Profound Change in the Database Mission: In the past, databases served programmers, BI systems, and deterministic business processes. In the future, a more important task is to enable data to be understood and used by hundreds or thousands of agents. “Agent + Database” is the Future Software Paradigm: Zhou Aoying, Fellow of the CCF and Director of the Database Committee, pointed out that […]

PostgreSQL 扩展生态全景解析（第四期）：TimescaleDB —— 当 PostgreSQL 拥抱时间之河 引言：时间，数据的第四维度 前三期，我们讨论了 PostgreSQL 如何通过扩展获得三种能力：GIS（理解空间）、全文搜索（理解关键词）、向量检索（理解语义）。本期，我们要探讨的是数据的第四维度——时间。 时间数据无处不在。打开一个 Web 应用的监控面板，曲线图上每一条线都是从“过去”延伸到“现在”的大时间序列。每当用户刷新页面，新数据用写操作推入数据库，下一秒的曲线就有了新的高点。 但问题是：监控面板背后，数据库正在经历什么？ 一台联网汽车每秒产生数千个数据点，一个工业物联网平台一天能积累数亿条记录。几周之后，这张表就膨胀到数十亿行。普通的 PostgreSQL 设计目标是事务处理，索引膨胀、VACUUM 压力、全表扫描——每一个都是在高频时序写入面前最先倒下的短板。 TimescaleDB 敢在 PostgreSQL 生态中正面回答这个问题。它不是一个新数据库，而是一款扩展——像 PostGIS 一样安装，然后一个普通的表变成了超表（Hypertable）： CREATE EXTENSION timescaledb; CREATE TABLE sensor_data ( time TIMESTAMPTZ NOT NULL, device_id TEXT NOT NULL, temperature DOUBLE PRECISION ); SELECT create_hypertable('sensor_data', 'time'); 这就是 TimescaleDB 的精髓。你用标准 SQL 看数据，TimescaleDB 在底层处理自动分区、压缩、降采样。开发者不必成为时序数据库专家，也不必引入第二套系统。这正是 TimescaleDB（及其背后的公司 Tiger Data）提出的哲学：Start on Postgres, scale on Postgres. 从“理解空间”的 PostGIS 到“理解语义”的 pgvector，再到“理解时间”的 TimescaleDB，我们在这一系列文章中所做的，其实是在见证一件事：当数据库扩展生态足够丰富时，一个实例就能承载几乎任何数据类型——不管你问的是“它在哪里”、“它像什么”还是“它怎么随时间变化”，答案都在同一套 SQL 里。 一、时序数据的特点与普通 PostgreSQL 的“短板” 时间序列数据是一类按时间顺序排列的数据点序列，来自物联网传感器、应用性能监控、金融市场行情、用户行为日志等源源不断的生成源。这类数据有以下几个共性特征： 高写入吞吐：每秒数万甚至百万级数据点涌入 时间有序：几乎只做插入，极少更新或删除——因为过去的历史是确定的 冷热分明：近期数据被高频查询，随着时间推移逐渐进入“归档区” 聚合为主：用户很少查询单一行，常见需求是“过去 24 小时平均温度”“近一周 CPU 使用率的 95 分位值” 那么，普通的 PostgreSQL 在处理这类场景时，存在哪些短板？ 单表过大：亿级行数会导致 MVCC 垃圾积压，VACUUM 压力倍增，索引也随之膨胀 时间范围查询效率低：即使有 B-Tree 索引，如果扫描跨越数亿行的范围，依然需要遍历大量数据页 缺乏自动生命周期管理：无法自动删除 30 天前的数据；要降采样，必须手工写 ETL 作业 无法内建预聚合：细粒度原始数据若要长期保存，查询性能会随数据累积直线下降 TimescaleDB 就是为了解决这些问题而生的。它是一个开源、兼容 PostgreSQL 的时序数据库扩展，在保留 PostgreSQL 全部能力（SQL、JSONB、GIS、ACID 事务）的基础上，针对时序场景新增了自动分区、数据压缩、连续聚合、列式存储和向量化执行等深度优化能力。 二、核心架构设计 2.1 Hypertable（超表）：时序表的“智能分身” 超表是 TimescaleDB 的核心抽象。开发者面向超表写 SQL 就像操作普通表，TimescaleDB 在底层根据时间（可选空间维度）自动将数据划分为一系列“块”（Chunk）。 在 TimescaleDB 的实现中，Chunk 并不是虚拟概念——每个 Chunk 就是一张标准的 PostgreSQL 表。超表相当于一个智能的分区管理层，自动将插入路由到正确的 Chunk，在查询时只扫描与时间范围相关的 Chunk。这种按时间分区的能力使得查询不受全表扫描拖累，读取和写入性能随着数据量增长仍然保持线性稳定。 空间分区（Space Partitioning） 是超表又一个王牌特性。假设传感器数据表包含 device_id，可以在创建超表时额外按 device_id 做哈希分区。查询 WHERE device_id = 'sensor_001' AND time > ... 时，TimescaleDB 直接定位到对应时间段的 Chunk 再裁剪到具体设备。时间 + 空间双分区让时序数据库中常见的复合过滤条件性能大幅提升。 2.2 Hypercore 列式存储引擎：行存储的灵活与列存储的性能兼顾 TimescaleDB 在 2.18 版本开始引入 Hypercore——一个混合行-列存储引擎。 为什么混合存储对时序数据如此重要？现代时序工作负载的特点决定它需要兼顾两种完全不同的访问模式：既要支持高吞吐、低延迟的写入（行式存储为每次写入维护完整记录）；又要支持筛选特定列的大范围聚合分析（列式存储只需要读取被查询列的数据块）。传统数据库必须在 OLTP 和 OLAP 之间二选一，而 Hypercore 将两者融合在一个引擎中。 Hypercore 的数据流转路径是：数据插入时，行式存储层负责高吞吐写入（最近的 Chunk 总是行存储）。当 Chunk 被标记为可压缩时，TimescaleDB 在后台将数据转换为列式存储，空间占用显著降低。用户在查询时无需感知二者边界，TimescaleDB 会决定从行式还是列式存储中读取。 ⚠️ 注意：Hypercore 曾以 Table Access Method（TAM）形式存在（v2.18.0）,但在 2.22.0 中完全移除，原因是 B-tree 架构的 TAM 性能不及预期，而列存储引擎已足够成熟。若从 v2.21.0 或更早版本升级，需先执行 ALTER TABLE ... SET ACCESS METHOD heap 迁移现有数据，否则升级会被阻塞。这提醒我们：即使看似的“下一代存储技术”也可能被废弃，生产环境采用前沿特性前务必评估长期维护成本。 2.3 Chunk 与块大小调优 Chunk 大小的设置直接影响插入和查询性能。TimescaleDB 的默认块大小为 7 天，但最佳做法是确保单个 Chunk 的大小约占主内存的 25%，这样最近的热数据能常驻内存，避免频繁磁盘 I/O。 […]

PostgreSQL 运维实战系列，第九期：生态扩展与深度定制——从经典扩展到AI时代的新边疆 0. 前言：数据库的价值不只在内核，更在生态 前八期我们从生产环境搭建一路走到安全合规与超大规模演进，基本覆盖了DBA日常运维的全部章节。但还有一个维度值得单独展开——PostgreSQL的生态扩展能力。 PostgreSQL之所以能在过去十年超越一众商业数据库成为全球最受欢迎的开源数据库，内核的稳定性是基础，但真正让它“战无不胜”的是其庞大的扩展生态。从高可用到监控，从分区管理向量搜索，PostgreSQL的扩展机制让开发者不用等待内核发版，就能在现有数据库上快速叠加新能力。 正如PostgreSQL全球开发组在2026年初所言，PostgreSQL拥有一个丰富的扩展生态系统——版本化的、可安装的组件，能够扩展数据库引擎本身。从pg_stat_statements到Citus，从pgvector到2026年新生的pgpm，扩展正在改变DBA对数据库的理解方式。 本期聚焦四个方面： 扩展开发入门：从C语言到PL/Python，如何为PostgreSQL增加自定义能力 分布式扩展深度实践：Citus的水平分片架构与存算分离演进 AI时代的新扩展：pgvector向量数据库的生产级部署与优化 扩展生态全景：从pg_stat_statements到pgpm，2026年的扩展管理新范式 1. 扩展开发入门：从零打造你的第一个PG扩展 当现成的扩展满足不了特定业务需求时，开发自己的PG扩展就成了绕不开的技能。PostgreSQL的扩展机制允许开发者在无需修改核心代码的前提下，新增数据类型、操作符、索引方法甚至钩子函数。 1.1 扩展开发的基本架构：一个扩展由什么构成 一个标准的PostgreSQL扩展由以下几个核心文件组成： 控制文件（.control） ：定义扩展的基本元信息——名称、默认版本、是否可重定位等 SQL脚本文件（.sql） ：包含创建扩展对象的SQL命令 C源代码文件（可选） ：实现核心功能逻辑，编译为共享库 Makefile：利用PGXS基础设施自动化构建 PGXS（PostgreSQL Extension Building Infrastructure）是PostgreSQL官方提供的构建基础设施，让扩展模块能够针对已安装的服务端轻松编译。默认情况下，扩展会被编译并安装到PATH中第一个pg_config程序对应的PostgreSQL安装目录下。 1.2 C语言扩展：通往性能巅峰 C语言扩展直接运行在数据库进程中，是追求极致性能时的必选项。开发C语言扩展时需要特别注意内存管理和并发安全，建议合理使用PostgreSQL内存上下文，避免内存泄漏；实现完善的错误检测和报告机制；确保扩展在多用户环境下的稳定性。 常见的使用场景包括创建自定义数据类型（如地理坐标、金融数据、科学计算数据）以及将复杂的业务逻辑封装为数据库扩展，减少应用层代码复杂度，提高系统整体性能。 1.3 PL/Python扩展：快速原型的不二之选 如果说C语言扩展是性能的巅峰，PL/Python则是敏捷性的典范。PL/Python允许开发者用熟悉的Python语言编写数据库函数。以下是一个实际示例：创建一个函数来计算数据数组的统计信息，返回JSON格式的结果——这在数据分析场景中极为实用。开发过程中可使用RAISE NOTICE进行调试输出，并创建单元测试验证功能正确性。 1.4 PG19革命：可插拔的查询规划器 扩展生态最激动人心的进展发生在查询规划层。PostgreSQL 19将引入一项重大变革：允许插件控制路径生成策略。这一由Robert Haas提交的补丁，本质上让扩展能够在PostgreSQL查询规划的最早期阶段影响决策。 今天的PG查询规划器首先生成“路径”（paths）——比如对该表使用顺序扫描，或对该索引使用索引扫描，或对两表连接使用哈希连接。PostgreSQL会提前丢弃一些成本较高的路径，保留其他路径做完整成本比较后保留最优计划。 当前最流行的规划干预扩展是pg_hint_plan，通过查询注释（如/<em>+ SeqScan(a) </em>/）来强制指定访问路径。PG19的路径生成策略补丁将让这类扩展的实现更加优雅——据估算，pg_hint_plan因此可以减少约2500行代码。 1.5 扩展管理模式变革：pgpm的诞生 2026年1月，PostgreSQL官方宣布了pgpm——一个为纯SQL模块引入包管理机制的项目，将模块化能力从系统级扩展下沉到应用层数据库逻辑。 pgpm的核心创新在于区分了“扩展管理”与“应用层模块管理”。传统扩展擅长系统级功能（自定义数据类型、操作符、索引方法），但在托管服务上往往受到限制，且不适合跨环境共享应用层SQL逻辑。pgpm解决了这一空白：让开发者能够像管理应用依赖一样管理PostgreSQL的数据库逻辑，并通过纯SQL实现，无需编译或超级用户权限，即可在本地开发、CI和托管PostgreSQL环境之间一致部署。 pgpm以“工作区”（workspace）为核心概念组织多个相关模块，每个模块包含自己的迁移脚本、依赖和版本，部署时自动解析依赖图并按正确顺序应用变更。 2. 分布式扩展深度实践：从Citus看PG的分布式演进 2.1 Citus 14.0：PG18能力在分布式集群中的“免费午餐” Citus是PostgreSQL生态中应用最广泛的分片扩展。2026年2月，Citus 14.0正式发布，其核心使命是完整适配PostgreSQL 18。 PG18的新特性——异步I/O（AIO）、skip-scan、uuidv7()、OAuth认证、虚拟生成列、时序约束等——在Citus 14.0中自然继承。异步I/O使扫描和VACUUM密集型负载受益；skip-scan在多列B-tree索引上的优化特别适合Multi-Tenant场景；而分布式查询中对时序列约束、生成列的完整支持，则标志着Citus对PG18新SQL语法的全面适配。 2.2 分布列选择：决定集群性能的第一性原理 Citus通过分布列将数据水平分片到多个工作节点，每个节点拥有一部分分片。分布列的选择直接决定整个集群的性能上限。 第一个黄金法则：分布列应具有高基数（大量不同的值），且应出现在大多数查询的WHERE子句中。典型的最佳实践是：通过共享的tenant_id列对分布式表进行分区（例如在SaaS应用中租户为公司的场景），同时将小型跨租户表转换为引用表。 第二个关键原则：Co-location（协同定位）。Citus要求JOIN表的分布列必须完全一致才能高效执行本地JOIN，否则触发跨节点shuffle或广播JOIN，性能下降5倍以上。需要确保列名、类型和colocation_id三者严格匹配，并通过pg_dist_partition和pg_dist_colocation验证。 2.3 物理复制 vs 分布式分片：横向扩展的三种路径 PostgreSQL的横向扩展有三个主要方向： 方案 适用瓶颈 运维复杂度 核心限制 只读副本 + PgBouncer读写分离 读吞吐量饱和 低 副本可能延迟，不减轻主库写入压力 Citus分片 写入吞吐量需横向分发 高 需改造数据模型和应用查询 分析负载卸载（CDC → ClickHouse） 分析查询与OLTP争抢 中 引入额外组件 扩容前需要明确瓶颈来源——是读吞吐量、写吞吐量还是分析扫描量。 2.4 存算分离与列式存储：Citus的混合负载能力 在OLAP领域，Citus原生支持列式存储访问方法（Columnar Access Method），通过专门的列存储引擎加速分析查询，适用于数据累积后的分析场景。 2026年的PostgreSQL分布式生态正经历从“分片扩展”到“存算分离”的范式迁移。Citus在这一演进中占据核心位置，与Amazon Aurora DSQL等多区域强一致性分布式数据库形成差异化竞争。 2.5 高基数复合主键与逻辑复制演进趋势 PostgreSQL的高基数复合主键设计在分布式场景中扮演越来越重要的角色。在双主复制方面，AWS持续推进pgactive扩展——支持跨区域双写，但运维复杂度显著增加（所有表必须有主键、序列不会被复制、DDL不会被复制），适用于“就近写入”的多区域应用场景。 3. AI时代的新扩展：pgvector向量数据库生产级实践 2026年，以pgvector为代表的向量数据库扩展，是PostgreSQL应对AI时代挑战的关键武器。 3.1 核心能力与典型应用场景 pgvector作为PostgreSQL的开源扩展模块，通过原生支持向量数据类型和专用索引结构，让开发者在关系型数据库中高效处理向量数据。它支持向量数据类型（最高16,000维）、三种相似度计算方法（L2欧氏距离、内积、余弦相似度）以及两种索引加速方案（IVFFlat和HNSW）。 典型应用场景包括：语义搜索系统（将商品描述转换为BERT嵌入向量后搜索）、推荐系统（用户行为序列与商品特征向量匹配，响应时间从2.3秒降至85毫秒）、图像检索（管理千万级图像特征库）。 3.2 索引选择：IVFFlat vs HNSW 索引选择是pgvector调优中最关键的一步，两种索引各有千秋。 维度 HNSW IVFFlat 选择建议 构建速度 慢 快 数据静态选IVFFlat 内存/磁盘占用 高（HNSW是IVFFlat的2-5倍） 低 资源紧张选IVFFlat 查询速度 极快 中等 延迟敏感选HNSW 动态数据支持 原生支持 需定期重建 频繁写入选HNSW 一个500万条768维向量的调优案例：HNSW索引构建近2小时但查询延迟10ms以内；切换IVFFlat后构建时间压缩至20分钟以内，存储空间减少约40%，查询延迟上升至20-30ms，但通过连接池和只读副本足以支撑高峰并发。 3.3 成本优化七策 大规模部署pgvector时成本控制的方法有七个关键维度： 精准配置IVFFlat参数：lists设为数据量平方根（内存占用可降低40%），probes根据延迟需求从1逐步提高。 优化HNSW参数：m参数（每层邻居数）根据向量维度调整，低维度（512维）提至20-24。 选择合适的距离函数：内积（IP）计算速度比L2快约15%，比余弦相似度更快，配合向量归一化预处理可降低20-30%的CPU消耗。 内存参数调优：work_mem设为5-10MB/查询，shared_buffers设为系统内存25%，maintenance_work_mem设为系统内存10%加速索引创建。 向量数据压缩：使用halfvec类型将32位浮点压缩为16位，节省50%存储空间，精度损失通常<1%。 查询优化：使用pg_stat_statements监控向量查询执行统计，识别高频搜索模式。 业务分区策略优化：结合表分区管理不同时间段的向量数据，降低单一分区的索引维护压力。 3.4 生产部署必备检查清单 部署阶段 检查项 推荐配置 预部署 向量维度确认、数据量预估 评估选择HNSW还是IVFFlat 索引创建 并行度设置、内存分配 maintenance_work_mem临时提高到系统内存20% 查询验证 EXPLAIN ANALYZE检查索引使用 确认使用Index Scan而非Seq Scan 容量监控 索引大小、内存占用持续追踪 HNSW索引大小可能达数据量的3-5倍 混合查询 向量搜索+传统条件组合优化 考虑partial index或分区策略 4. 扩展生态全景：2026年DBA必备的扩展工具箱 4.1 核心扩展速查 下表整理了生产环境中必备的扩展及其用途： 扩展名称 核心功能 生产必装级别 pg_stat_statements SQL执行统计追踪 ⭐⭐⭐⭐⭐ auto_explain 自动记录慢查询执行计划 ⭐⭐⭐⭐⭐ pg_stat_kcache 真实的I/O指标监控 ⭐⭐⭐⭐ pg_partman 分区表自动化管理 ⭐⭐⭐⭐ pg_cron 数据库内定时任务调度 ⭐⭐⭐ pgaudit 合规审计日志 按需 pg_hint_plan 强制执行计划 按需 pg_prewarm […]

📢 MySQL 新技术系列第八期（最终期） 各位数据库同行、开发者朋友们，大家好！ 欢迎回到「MySQL 新技术」系列。今天，我们迎来了这个系列的最后一期。 从第一期「告别 MySQL 8.0 时代，全景解读 9.x 创新版」开始，我们一路走过了向量检索、JavaScript 存储程序、Group Replication 高可用、安全加固、云原生实践、备份与恢复等七个专题。每一期都试图从一个特定维度，剖析 MySQL 9.x 系列的技术演进与生产实践。 作为收官之作，本期不再聚焦单一主题，而是将前七期尚未覆盖的重要技术方向进行汇总梳理——包括 JSON 能力的跨越式增强、InnoDB 存储引擎的深度优化、分区表的重大改进、字符集与排序规则的现代化、以及查询性能调优的实战指南。最后，我们将对整个系列进行系统总结，回顾 MySQL 9.x 时代的技术全景，并展望未来的演进方向。 让我们开始吧。 一、JSON 能力的跨越式增强 在第二期我们重点讨论了向量检索，但 JSON 作为现代应用开发的核心数据类型，在 9.x 系列中也经历了深刻的变革。 1.1 JSON 优化器重写（9.0） MySQL 9.0 对 JSON 优化器进行了完全重写，改变了 JSON_EXTRACT() 等函数的执行路径。这一变更带来了性能的双面性：部分查询获得显著加速，但也有查询出现了性能回退。 典型案例：某开发者在 8.0 中运行良好的 JSON_EXTRACT 查询，升级到 9.0 后执行时间从 0.3 秒变成了 2.1 秒。分析发现，优化器的新成本模型在某些 JSON 路径表达式上选择了次优的执行计划。 应对策略： 升级前对涉及 JSON 函数的核心查询进行充分的性能回归测试 使用 EXPLAIN FORMAT=JSON 分析执行计划变化 必要时通过 OPTIMIZER_SWITCH 或 JSON_OPTIMIZER_SWITCH 调整优化器行为 1.2 多值索引对 JSON 数组的支持（9.0） 长期以来，在 JSON 数组中检索特定值需要全表扫描或依赖全文索引。MySQL 9.0 引入了对 JSON 数组的多值索引支持，彻底解决了这一痛点。 -- 创建多值索引 CREATE TABLE articles ( id INT PRIMARY KEY, metadata JSON, INDEX idx_tags ((CAST(metadata->'$.tags' AS CHAR(50) ARRAY))) ); -- 高效检索包含特定标签的文章 SELECT * FROM articles WHERE 'mysql' MEMBER OF (metadata->'$.tags'); 性能对比：在 10 万行数据中，8.0 的 MEMBER OF 查询耗时约 450ms（全表扫描），9.0 使用多值索引后降至约 12ms，提升近 40 倍。 多值索引的限制： 仅支持 InnoDB 引擎 只能在一个 JSON 数组列上创建 数组元素类型必须一致（可通过 CAST 统一） 1.3 JSON Duality Views（9.7 LTS 社区版开放） JSON Duality Views 是 MySQL 将关系型数据以 JSON 文档形式呈现的视图机制，允许应用程序通过 JSON 文档接口访问关系数据，同时底层仍保持关系模型的 ACID 事务和约束完整性。 在 9.7 LTS 之前，该功能仅限企业版。9.7 LTS 将其开放至社区版，使开发者能够： 将关系表映射为 JSON 文档集合 通过标准的 HTTP REST 接口或 CRUD 操作读写 JSON 文档 底层自动转换为 SQL 操作，无需修改现有关系模式 这一特性对希望采用「文档数据库」体验但又不想放弃关系数据库 ACID 保证的应用场景尤为实用。 1.4 JSON 聚合函数增强（9.x 持续演进） 9.x 系列还增强了多个 JSON 聚合函数： JSON_ARRAYAGG()：支持更灵活的空值处理和排序 JSON_OBJECTAGG()：支持动态键名生成 JSON_MERGE_PATCH()：符合 RFC 7396 标准的 JSON Merge Patch 语义 二、InnoDB 存储引擎的深度优化 InnoDB 作为 MySQL 的默认存储引擎，在 9.x 系列中获得了多项底层优化。 2.1 […]

第四期：云原生PostgreSQL的分布式架构演进 从分片到存算分离，2026年PostgreSQL如何征服大规模数据挑战 在前三期技术专题的铺垫下，我们已经看到PostgreSQL 18/19的内核能力持续增强，向量检索与图查询等AI生态能力快速融合。而真正驱动PostgreSQL完成“单机数据库→综合性数据平台”这一角色跃迁的底层力量，源自云原生架构的深刻变革。 2026年的PostgreSQL分布式生态，正在经历一场从“分片扩展”到“存算分离”的范式迁移。当Citus、Apache Cloudberry等社区主力持续进化的同时，Google Cloud推动的逻辑复制向主动-主动架构演进、阿里云Serverless Pro模式对存算分离的工程化落地，以及EDB、Aurora、YugabyteDB等商业与开源力量的齐头并进，共同勾勒出一幅云原生时代的分布式PostgreSQL全景图。 一、Citus 14.0：将PG 18的力量带到分布式集群 作为PostgreSQL生态中应用最广泛的分片扩展，Citus在2026年2月迎来了14.0版本，其核心使命是完整适配PostgreSQL 18。 1.1 PG 18能力在分布式集群中的“免费午餐” Citus的实现方式决定了它作为PostgreSQL扩展的本质：一个Citus集群本质上是多个独立PostgreSQL实例（协调器+多个工作节点）共同工作。这意味着，一旦Citus与新版PG完成兼容性适配，绝大多数上游改进无需额外开发即可“自动生效”。在Citus 14.0中，PG 18的以下能力被直接带入分布式场景： 异步I/O：分片密集的分布式集群中，顺序扫描、位图堆扫描和VACUUM操作从AIO中获得显著加速； 跳跃扫描：在多租户应用中，跳过分布列前缀的查询也能有效使用多列索引； uuidv7()：时间有序的UUID在各分片间生成，减少跨分片索引的随机写入开销。 1.2 仍需Citus定制的领域 尽管如此，某些复杂功能仍需Citus团队进行专项适配——包括JSON_TABLE()在分布式查询中的支持、DDL传播的正确性验证，以及PG 18新增时态约束在分片语义下的一致性保证。对于已经或计划采用Citus分片架构的企业而言，14.0是一个值得规划的升级节点。 二、Apache Cloudberry 2.1.0：MPP数据仓库的开源新力量 2026年4月，Apache Cloudberry（孵化中）发布了2.1.0版本，这是继2.0.0正式进入Apache孵化器后的首个重要更新。 Cloudberry的核心定位是MPP数据仓库，继承自Greenplum Database最后一代开源代码，专为大规模分析型工作负载和AI场景设计。2.1.0的核心突破包括： UDP2互联协议：全新实现的计算节点间通信协议，提升分布式查询的执行效率； ORCA优化器增强：支持CTE剪枝和部分聚合下推，多项正确性与内存修复； PAX列存格式LZ4压缩：提升存储效率，配合I/O和内存管理优化； 快速ANALYZE：针对追加优化表的统计信息收集加速，解决大规模环境中的运维瓶颈； MCP服务器：便于与LLM工具和AI工作流集成。 Cloudberry的出现填补了PG生态在“分析型MPP数据仓库”领域的空白。与Citus侧重OLTP/HTAP场景的分片架构不同，Cloudberry沿袭了Greenplum的列式存储与大规模并行执行引擎，与PG 18/19的内核新特性形成互补。值得注意的是，其内核版本目前仍基于PG 14.x，团队正积极推进向PG 16.x的升级，未来内核版本的追赶将是Cloudberry的关键看点。 三、Google Cloud：推动逻辑复制迈向“主动-主动”架构 Google Cloud在2026年初发布的一份社区贡献报告，勾勒出一条清晰的演进路径：让PostgreSQL的逻辑复制从主-从模式走向主动-主动（active-active）架构。 3.1 自动冲突检测：打破双向复制的长期瓶颈 逻辑复制的传统局限在于双向写入场景下，冲突更新可能导致复制中断。Google Cloud工程师向PostgreSQL上游贡献的关键能力是自动冲突检测——数据库在复制过程中可自动识别行级冲突，无需人工干预。这一能力是多节点写入场景的核心突破，也是迈向主动-主动架构的前提条件。 3.2 序列复制与pg_upgrade优化 其他关键贡献包括：将逻辑复制范围从表数据扩展到序列，大幅减少迁移或版本升级时的手动同步需求；修复订阅管理中的自死锁问题；对pg_upgrade的大对象管理优化，缩短大规模部署的升级时间。此外，Google还正在研发复制结构化冲突日志、pg_dump并行数据导出等未来能力。 社区对此反响热烈：Franck Pachot指出，带冲突解决的双向逻辑复制与CockroachDB/YugabyteDB等分布式SQL存在不同的一致性模型基础——前者遵循“最后写入胜出”，后者提供严格ACID语义。但更多观点认为，当超大规模云厂商将主动-主动复制这类企业级特性贡献到上游时，标志着PostgreSQL已成为无可争议的企业默认选择。 四、阿里云Serverless Pro：存算分离的工程化落地 如果说Google Cloud从“复制”维度推动分布式演进，阿里云则从“架构”维度给出了另一条答案——Serverless Pro模式，以存算分离为底座，重塑云原生PostgreSQL的弹性边界。 4.1 从有状态到无状态：架构的范式迁移 传统AnalyticDB PostgreSQL版采用Master/Segment架构，计算节点绑定本地ESSD，数据增长带来存储成本的线性上涨，计算节点有状态导致扩缩容慢；一写多读只能通过“新建集群+复制数据”实现，周期长且存储成本成倍增加。 Serverless Pro模式将持久化数据统一沉降到OSS对象存储，本地ESSD仅用于缓存与临时数据，使计算层趋于无状态。计算与存储解耦后，算力可独立扩缩——峰值快速拉起，低谷及时回收，存储按需付费，避免被本地盘长期绑定。 4.2 Virtual Warehouse：读写分离的极致版本 基于共享存储底座，Serverless Pro支持“主集群+多Virtual Warehouse（VW）”的多集群共享存储架构。主集群处理写入任务，只读业务由独立VW承载，大查询不再抢占主集群资源。创建VW无需复制数据，读扩展从传统“天级数据复制”缩短为“分钟级资源拉起”；多个VW共享同一份底层数据，避免为每个只读集群重复购买存储。 4.3 Log-as-Database的设计思想 Serverless Pro的底层基于“Log-as-Database”思想：将数据库的“随机写Page”转化为WAL的“顺序写”，由存储侧异步回放WAL生成数据页，使最终数据长期驻留在OSS上。其四层架构（计算节点→Log Store→Page Store→OSS）清晰呈现了存算分离的工程全貌。 阿里云已于2026年3月30日正式下线旧版Serverless模式，Serverless Pro成为其云原生数据仓库的标准入口。 五、其他云原生分布式力量 方案 架构路线 关键特点 适用场景 EDB Postgres Distributed 原生分布式 高可用、性能与弹性，全球级分布式支持 企业级全球部署 CloudNativePG 1.29 Kubernetes Operator 8k+ GitHub星标，扩展模块化解耦，供应链安全 K8s环境PG运维 Stolon K8s HA管理器 etcd集群状态管理，自动故障切换 容器化高可用部署 Amazon Aurora PostgreSQL 云托管存算分离 5倍吞吐量，自动存储扩展，Blue/Green切换 云上托管OLTP CockroachDB 协议兼容版 PG线缆协议兼容，Raft分布式共识，跨地域强一致 全球分布式事务 TiDB for PostgreSQL 协议兼容版 TiDB分布式架构 + PG兼容API层，代码迁移成本低 MySQL/PG混合迁移 协议兼容版指在API层面模拟PostgreSQL通信协议、底层为自研架构的产品类型。这类产品基于云原生基础设施构建，可提供跨区域强一致性与水平读写扩展等原生PG难以实现的能力。 六、总结与展望 回顾2026年云原生PostgreSQL分布式架构的演进全景，四条主线贯穿始终： 第一条主线：分片扩展的持续进化。 Citus 14.0完成了PG 18的完整适配，让异步I/O、跳跃扫描等底层性能红利在分布式集群中兑现。作为分片扩展的代表，Citus持续巩固其在OLTP/HTAP场景的领先地位。 第二条主线：MPP数据仓库的生态新生。 Apache Cloudberry 2.1.0的发布填补了PG生态在分析型MPP领域的空白。继承自Greenplum的列存引擎与大规模并行执行能力，为大数据分析提供了开源新选择。 第三条主线：云厂商驱动的基础能力跃迁。 Google Cloud推动逻辑复制迈向主动-主动架构，阿里云Serverless Pro以存算分离重塑弹性边界。云厂商不仅将PG作为服务对外提供，更将内部大规模运维的实践经验反向贡献给上游社区。 第四条主线：多样化分布式生态的百花齐放。 EDB Postgres Distributed面向企业级全球部署、CloudNativePG成为K8s上PG运维的事实标准、CockroachDB与TiDB等协议兼容版以自研分布式架构满足极端扩展需求——不同的架构路径服务于不同的场景诉求，共同构成了2026年PG分布式生态的完整图景。 回看过去一年的分布式架构演进，一个清晰的趋势正在浮现：PostgreSQL正在从“一个可以被分布式的数据库”演进为“一个原生具备分布式能力的数据平台”。 这种变化不仅体现在技术能力上——存算分离、主动-主动复制、MPP分析引擎；更体现在生态格局上——从单一的分片扩展，走向多种架构路线共存的分布式生态系统。 对于企业架构师和技术决策者而言，2026年的选择前所未有的丰富：是采用轻量级的分片扩展（Citus），还是部署完整的MPP数据仓库（Cloudberry）；是依赖云厂商托管的Serverless模式，还是基于Kubernetes自建云原生运维体系——每一条路径都有成熟的开源生态和商业支持作为后盾。 这正是云原生PostgreSQL时代最值得关注的价值：企业可以在不牺牲PostgreSQL生态兼容性的前提下，根据自身的规模、场景和运维能力，选择最适合的分布式演进路径。 📌 下期预告：第五期——PostgreSQL扩展开发实战：用Rust构建自己的PG扩展 从pgvector到VectorChord，从ParadeDB到Citus，PG生态的强大生命力源自其可扩展的内核架构。第五期我们将深入扩展开发实战，以Rust为开发语言，从零构建一个完整的PG扩展，带你掌握PostgreSQL扩展开发的全流程——从环境搭建到Cargo integration，从数据类型定义到性能优化。 （本文数据截至2026年4月，最新动态请以各项目官方发布为准。）

第十期：性能监控与调优方法论 —— 从等待统计到DMV分析 1. 性能优化的核心思维：基于证据，而非直觉 三个关键转变： | 从 | 到 | |—-|—-| | “我觉得这里慢” | “等待统计显示这里花了X%时间” | | “重启一下试试” | “定位具体瓶颈类型（CPU/IO/网络/锁）” | | “加个索引吧” | “分析执行计划+等待类型后再决定” | 核心方法论：Waits and Queues（等待与队列） SQL Server 的性能问题最终都会表现为等待（某个资源不可用） 找出TOP等待类型 → 定位瓶颈资源 → 针对性优化 2. 等待类型分类与解读 等待类型三大类（按可优化性排序）： | 类别 | 定义 | 典型等待 | 处理方向 | |——|——|———-|———-| | 资源等待 | 等待CPU、内存、I/O等硬件资源 | WRITELOG, PAGEIOLATCH_*, SOS_SCHEDULER_YIELD | 升级硬件或优化使用方式 | | 锁等待 | 等待锁释放 | LCK<em>M</em>* | 优化查询、索引、隔离级别 | | 外部等待 | 等待外部应用或网络 | OLEDB, BROKER<em>*, PREEMPTIVE</em>* | 检查外部依赖 | TOP 10 常见等待类型速查： | 等待类型 | 含义 | 最常见原因 | 针对性排查 | |———-|——|————|————| | PAGEIOLATCH_SH | 等待从磁盘读页到内存 | 内存不足，或缺失索引导致大量物理读 | 检查缓冲池命中率，检查缺失索引 | | WRITELOG | 等待日志写入磁盘 | 事务提交频繁，日志磁盘慢 | 批量提交，日志盘换SSD，检查磁盘队列 | | LCK_M_X | 等待排他锁 | 长事务、锁升级、并发写冲突 | 查sys.dm_tran_locks，优化长事务 | | SOS_SCHEDULER_YIELD | 自愿让出CPU（等待调度）| CPU压力大，查询未优化 | 检查CPU使用率，优化高代价查询 | | ASYNC_NETWORK_IO | 等待客户端接收数据 | 客户端处理慢，网络慢 | 检查客户端应用，网络带宽 | | PAGELATCH_EX | 等待页闩锁（内存结构）| tempdb竞争（PFS/GAM/SGAM页）| tempdb增加文件，使用分区表 | | CXPACKET | 等待并行查询同步 | 并行查询的不均衡分布 | 调整MAXDOP，优化倾斜数据分布 | | BACKUPTHREAD | 等待备份完成 | 备份任务占用资源 | 维护窗口做备份，调整备份压缩 | | LOGBUFFER | 等待日志缓冲区空间 | 日志生成过快，磁盘跟不上 | 增大日志文件，优化大事务 | | MEMORY_ALLOCATION_EXT | 等待内存分配 | 内存压力，大查询需要内存授予 | 调整max server memory，优化大排序/哈希 | 查询当前等待统计： -- 查看自上次重启以来的等待累积 SELECT wait_type, waiting_tasks_count, wait_time_ms, &#x20; max_wait_time_ms, signal_wait_time_ms, &#x20; (wait_time_ms - signal_wait_time_ms) AS resource_wait_ms, […]