DBA晨报·第32期｜MySQL 9.7 LTS即将发布、国产数据库头部厂商格局变化、DBA职业警钟

📊 HiddenMerit Daily · Issue 57 Focus on Database Frontiers, Practical Insights for DBAs July 17, 2026 ｜ 5 Selected Global Breaking News 01｜CAICT Releases “Database Development Research Report (2026)”: China Market to Reach RMB 98 Billion by 2028, AI‑Native Becomes the Main Theme On July 9, at the 2026 Trustworthy Database Development Conference, the China Academy of Information and Communications Technology (CAICT) officially released the “Database Development Research Report (2026),” comprehensively revealing the latest landscape and evolution directions of the global and Chinese database markets. Key Data: Global Market: The global database market reached $131.6 billion in 2025 (approximately RMB 894.09 billion). Chinese Market: The Chinese database market reached $9.49 billion in 2025 (approximately RMB 64.48 billion), accounting for 7.2% of the global market. By 2028, the total Chinese database market is expected to reach RMB 97.974 billion, with a compound annual growth rate of 13.06% . Industry Landscape: There are 394 database product providers globally, with China and the US leading in vendor count. The number of global open‑source and closed‑source products is roughly balanced. Commercial databases account for over 70% in China, while the proportion of open‑source databases is increasing. After rapid growth from 2022 to 2024, […]

SQL 与查询优化（PostgreSQL 篇）· 第一期 读懂执行计划 & 索引优化入门 本系列专注于 PostgreSQL 中 SQL 能力的深度挖掘与查询性能调优。 第一期从最核心的工具——执行计划入手，结合统计信息与索引选择，带你建立系统性的优化思维。 一、为什么查询优化如此重要？ 很多开发人员写出功能正确的 SQL，却忽略了执行效率。当数据量从万级增长到千万级，一个缺少索引或写法不佳的查询可能导致响应时间从毫秒变成分钟。PostgreSQL 提供了强大的优化器、丰富的索引类型和精准的代价模型，但前提是你要学会如何“引导”它。 优化不是盲目加索引，而是： 看懂执行计划 – 知道 PG 实际怎么执行你的 SQL。 理解统计信息 – 让优化器获得准确的基数估算。 合理选择索引与改写 SQL – 用最小的代价让查询走最优路径。 二、执行计划 – 透视 PG 的内部动作 2.1 基础命令：EXPLAIN EXPLAIN SELECT * FROM orders WHERE customer_id = 12345; 输出示例： Seq Scan on orders (cost=0.00..2043.00 rows=10 width=88) Filter: (customer_id = 12345) Seq Scan：顺序扫描整张表。 cost：第一个数字是启动成本（获取第一行的代价），第二个数字是总成本。 rows：优化器估计返回的行数。 width：结果行平均字节数。 真正执行并返回实际耗时： EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 12345; ANALYZE 会真正运行查询，输出实际执行时间、实际行数、内存使用等，是分析的黄金工具。 ⚠️ 注意：EXPLAIN ANALYZE 会修改数据（如果 SQL 包含 INSERT/UPDATE/DELETE），建议在事务中回滚或使用只读查询。 2.2 常见扫描方式 扫描类型 说明 适用场景 Seq Scan 全表顺序扫描 表很小、或需要读取大部分数据（>5%~10%）、或没有可用索引 Index Scan 索引扫描 + 回表 索引过滤条件强，返回行数较少 Index Only Scan 仅索引扫描 所有需要的字段都在索引中，不需要回表 Bitmap Index Scan + Bitmap Heap Scan 位图扫描 多个索引条件组合，或返回行数中等（减少随机 I/O） 举例： -- 创建索引后 CREATE INDEX idx_orders_customer ON orders(customer_id); EXPLAIN SELECT * FROM orders WHERE customer_id = 12345; 输出变为： Index Scan using idx_orders_customer on orders (cost=0.29..8.30 rows=10 width=88) Index Cond: (customer_id = 12345) 2.3 连接方法（Join 策略） PostgreSQL 有三种常见连接算法： 连接方式 原理 复杂度 适用场景 Nested Loop 外层表每行去内层表匹配 O(outer * inner) 驱动表很小，内层表有索引 Hash Join 构建一个表的哈希表，另一表探测 O(outer + inner) 两表较大且等值连接，无索引可用 Merge Join 两表按连接键排序后归并 O(outer + inner) 两表已有序或连接键有序，常用于不等值连接 阅读执行计划时，注意最里层（缩进最多的节点）最先执行。例如： Hash Join (cost=...) Hash Cond: (o.customer_id = c.id) -> Seq Scan on orders o -> Hash -> Seq Scan on customers c 先扫描 […]

📊 HiddenMerit Daily · Issue 29 Focus on Database Frontiers, Practical Insights for DBAs May 25, 2026 ｜ 5 Selected Global Breaking News 01｜China Academy of Art Launches RMB 550,000 Xinchuang Procurement: University Xinchuang Moves from “Pilot” to “Full‑Scenario Replacement” On May 15, the China Academy of Art released its government procurement意向 for May 2026, with a budget of RMB 550,000 for the “Domestic Xinchuang Construction – 2026” project. The procurement requirements explicitly state: by 2025, achieve basic domestic production of educational new infrastructure related software and hardware, and by 2027, complete full‑chain replacement of core business systems and terminal environments, forming an autonomous and controllable ecosystem covering “chips – operating systems – databases – application software – security services.” Specific technical paths include: large‑scale deployment of domestic CPUs (Kunpeng, Loongson, etc.), operating systems (UnionTech UOS, Deepin), and databases (Dameng DM8, KingbaseES) in data centres, labs, and office terminals, with a domestic production rate of over 90% for core equipment; driving deep compatibility of key applications such as academic affairs management, research collaboration, and smart classrooms with domestic environments, achieving 100% adaptation rate; building a “zero‑trust access + perimeter protection + data encryption + log audit” defence system based on […]

第四期：云原生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月，最新动态请以各项目官方发布为准。）

📊 HiddenMerit Daily · Issue 46 Focus on Database Frontiers, Practical Insights for DBAs June 18, 2026 ｜ 5 Selected Global Breaking News 01｜OceanBase Launches AI Integrated Solution at Financial Expo: Nearly 70% of Trillion‑Yuan Banks Have Adopted It, Ranked #1 in Distributed Market for Three Consecutive Years On June 16, the 2026 China International Financial Expo opened in Shanghai. Ant Group’s OceanBase launched its “Financial AI Integrated Data Solution,” processing transactions, analytics, and multi‑modal data within a single engine, supporting hybrid search across vectors, text, and more. It also includes built‑in data branching capability, enabling safe AI exploration and iteration in isolated environments. Key Data: Market Position: According to IDC data, OceanBase has been ranked #1 in market share in China’s financial industry distributed database on‑premises deployment market for three consecutive years. Bank Coverage: Nearly 70% of banks with trillion‑yuan assets have deployed their core systems on OceanBase. Financial Institution Coverage: Has served over 400 financial institutions, covering state‑owned major banks, joint‑stock banks, city commercial banks, and others; 75% of leading insurance institutions, 80% of leading securities firms, and 60% of leading fund institutions have chosen OceanBase for their core business systems. OceanBase CEO Yang Bing identified two forces […]

PostgreSQL 运维实战系列，第七期：云原生与混合部署实践 0. 前言：为什么云原生 Database 是必经之路 前六期我们搭建了生产环境，配置了高可用集群，做了容量规划，也学会了故障诊断。但接下来一个更基础的问题摆在你面前：你打算把数据库放在哪里？ 过去三年，数据库运行的模式发生了根本性的变化——超过 80% 的组织已在 Kubernetes 中运行生产级数据库，AI/ML 工作负载正在加速这一转变。无论是选择云厂商的托管服务、在 Kubernetes 上自建 Operator，还是落地混合云架构，如何让 PostgreSQL 跑得更省心、更具弹性，是所有现代 DBA 必须回答的新命题。 本期聚焦云原生的核心实践： 部署模式决策：托管服务 vs Kubernetes Operator vs 自建——选对起点 弹性伸缩与无服务器：告别“资源预留”，让数据库跟着流量走 混合与多云架构：打破供应商锁定，构建可迁移的数据基础 云原生可观测性：600+ 核心指标全栈覆盖 1. 部署模式：托管、K8s Operator 还是自建虚拟机？ 今天的 PostgreSQL 云原生生态已高度成熟，可以从“自建虚拟机 → Kubernetes → 全托管”这条演进路线中，根据团队能力、成本预算和业务重要性作出合适的抉择。 1.1 模式对比速查表 维度 托管服务 (RDS/Aurora/Cloud SQL) K8s Operator (CNPG/Percona) 虚拟机自建 运维成本 极低——自动备份、补丁、监控即开即用 中等——需维护 K8s 与 Operator 自身，但数据库被 Operator 接管 极高——备份、监控、高可用全部手写 可控性 中等——部分内核参数受限，存储上限受微软与亚马逊等约束 高——完全控制 PostgreSQL 配置与实例行为，操作系统级别也能触及 完全可控 弹性伸缩 原生支持——所有主流云厂商均提供弹性计算 需配合 K8s HPA 与节点自动扩缩容 人工干预，甚至需要提前规划扩容窗口 高可用 跨 AZ 自动切换，RTO < 30s Operator 原生支持自动故障转移 手工搭建 Patroni + 流复制 备份与恢复 托管服务内置自动化 PITR 通过 pgBackRest + 对象存储 WAL 归档 自建备份脚本与存储系统 成本模型 按实例规格 + 存储 + I/O 多重计费 基础设施按实际使用付费，数据库免费 基础设施费用 + DBA 人力成本 适用场景 初创快跑、企业标准应用、不想管底层 统一技术栈的 K8s 平台团队、混合云一致性需求 遗留系统、极端合规或定制化需求 选型原则清晰：团队规模小、追求快速上线就选择托管 RDS；技术栈统一至 K8s、追求自动化就选择 CNPG 等 Operator；而虚拟机自建在今天只作为最后选项——除非有很特殊的合规或成本限制。 1.2 主流托管服务横向对比 AWS:RDS for PostgreSQL 是最简便的托管方式，一键开启自动备份和跨 AZ 高可用；Aurora PostgreSQL 则提供更高的性能和更丰富的可用性选项，15 个只读副本 + 30 秒内故障切换，但需额外为 I/O 付费。AWS 在 2025 年正式推出 Aurora DSQL，这是一个与 PostgreSQL 兼容的无服务器分布式数据库，支持多区域强一致性与 99.999% 的可用性。 Google Cloud:Cloud SQL 是对标 RDS 的极简方案，价格友好——入门级配置 db-f1-micro 约 $11/月，对于小型业务非常合适。AlloyDB 是 Google 的“Aurora 对标品”，通过专属列式引擎大幅提升分析查询效率，适合中大型交互式应用负载。 Azure:Azure Database for PostgreSQL 的灵活服务器模式支持区域冗余（跨可用区）高可用，零数据丢失的同步复制，是构建关键交易系统的坚实选择。 2. Kubernetes Operator：生产级云原生的事实标准 如果你所在的组织已经将大部分应用容器化并运行在 K8s 上，逻辑上只有一步之遥——将数据库也移入 K8s。 2.1 CloudNativePG（CNPG）：事实标准 CloudNativePG（CNPG）是目前运行 PostgreSQL on Kubernetes 的事实标准，也是增长最快的 Operator，GitHub 上已超过 8,000 星。CNPG 设计上最大的亮点是它不依赖任何外部共享存储，所有实例使用本地存储，集群高可用和故障转移完全通过 PostgreSQL 的流复制实现。这里给出一个生产级的部署示例： apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: prod-db-cluster namespace: database spec: instances: 3 # 三个实例——一个主，两个副本 storage: […]