SQL Server 2025 新技术系列介绍（第三期）
Clyde Jin
04-23
DBA
54
本系列第一期回顾：SQL Server 2025 通过原生向量数据类型、DiskANN 索引、T-SQL AI 函数和 ONNX 模型本地托管，将 AI 深度集成至数据库内核。第二期聚焦企业级高可用、混合架构与数据迁移，解读了包含的可用性组（CAG）、Fabric 镜像、PolyBase 数据虚拟化等核心能力的演进。本期作为系列的收官之作，我们将从开发者与 DBA 的日常实战出发，通过代码案例、性能分析和决策框架，全景呈现 SQL Server 2025 在生产环境中的真实价值。

一、开发者实战：用最熟悉的 SQL 做最酷的事

SQL Server 2025 被微软称为“十年来最重要的 SQL 开发者版本”，其核心逻辑清晰而直接：将过去需要多种外部工具和复杂集成的能力，收敛到 T-SQL 中，让开发者用最熟悉的语言完成从前端 API 到后端向量搜索的全链路开发。

1.1 原生 JSON 数据类型：告别字符串解析时代

JSON 早已成为现代应用的数据交换标准，但传统 SQL Server 中 JSON 以字符串形式存储，查询时需要解析整个字符串才能定位某个键值——效率低下且资源消耗巨大。

SQL Server 2025 引入原生 JSON 数据类型，采用 UTF-8 编码的二进制格式 存储数据，引擎可以直接访问指定的键而无需解析整个文档。同时支持为 JSON 字段建立高速索引，实现高性能的文档式查询。对于从关系数据构建 JSON 文档的场景，新增了两个聚合函数：

  • JSON_OBJECTAGG：将键值对构建为 JSON 对象。语法示例： 
    SELECT JSON_OBJECTAGG('City':City, 'Country':Country) AS Cities
FROM Locations;
    支持 NULL ON NULL（保留 NULL）和 ABSENT ON NULL（忽略 NULL）两种行为控制。
  • JSON_ARRAYAGG：将多行数据聚合成 JSON 数组。

在 SSMS 22 的结果网格中，现在可直接将查询结果导出为 JSON 格式，进一步简化了开发流程。

1.2 正则表达式（Regex）函数：原生实现，告别 CLR 曲线救国

过去在 T-SQL 中做复杂模式匹配，要么用 LIKE 加通配符勉强应付，要么依赖 CLR 扩展——既增加部署复杂度又影响性能。SQL Server 2025 原生引入了三个正则表达式函数：

函数 功能说明
REGEXP_LIKE 判断字符串是否匹配正则模式（支持 SARGable 索引加速）
REGEXP_REPLACE 将匹配正则的子字符串替换为新字符串，支持 LOB 类型
REGEXP_SUBSTR 提取匹配正则的子字符串，支持 LOB 类型

这些函数的原生实现意味着更快的执行速度和更低的资源开销，使 T-SQL 中的文本处理能力跃升了一个台阶。

1.3 模糊字符串匹配：让搜索更“通情达理”

姓名匹配、地址去重、数据清洗——这些场景中，精确匹配往往难以满足实际需求。SQL Server 2025 新增的 JARO_WINKLER_DISTANCE 和 JARO_WINKLER_SIMILARITY 函数，基于 Jaro-Winkler 算法计算两个字符串之间的相似度，非常适合处理姓名、地址等易出现拼写偏差的数据。

1.4 REST API 集成：T-SQL 直连外部服务

SQL Server 2025 新增系统存储过程 sp_invoke_external_rest_endpoint，允许直接在 T-SQL 中调用外部 REST 或 GraphQL 服务，无需编写中间层代码。这使得在数据库触发器中实时调用外部 API、与云服务无缝交互成为可能。

1.5 变更事件流（CES）：实时推送的变革

Change Event Streaming（CES） 是 SQL Server 2025 在数据集成领域的重大革新。不同于传统的变更数据捕获（CDC）需要先将变更写入内部表再供消费，CES 直接从事务日志读取变更并推送到 Azure Event Hubs，大幅降低 I/O 开销。

CES 相比 CDC 的关键差异：

维度 CDC CES
捕获目标 内部系统表（需额外 I/O） 事件流（“无 I/O”）
捕获方法 查询系统表，多目标 处理事件流，单目标
使用场景 数据仓库、审计 事件驱动架构、微服务集成、实时分析、缓存同步
DDL 变更捕获 不支持 支持
传输方式 拉取（pull-based） 推送（push-based）

CES 的核心价值在于：表发生变更的瞬间，JSON 记录即可被推送到事件中心，下游应用实时响应。在 Fabcon/SQLCon 的 F1 主题演示中，当赛道发生事故时，CES 即时触发黄旗信号，AI 服务随即决策是否更换轮胎——这就是事件驱动架构的典型落地。截至 CU3，CES 已支持 Entra 身份认证和 Azure SQL 托管实例。

1.6 Python 驱动程序正式发布

Microsoft Python Driver for SQL Server（mssql-python）正式 GA，提供现代化的高性能连接器，原生支持 Entra ID 认证，为 Python 开发者提供了与 SQL Server 交互的全新体验。

二、DBA 运维实战：让数据库运行得更聪明

如果说开发者新特性让“写 SQL”更高效，那么 DBA 相关的增强则让“管 SQL”更轻松——很多过去需要手动介入的运维工作，现在可以交由数据库自动完成。

2.1 SSMS 22 与 GitHub Copilot：DBA 的 AI 助手

SSMS 22 已正式发布，其核心亮点之一是 GitHub Copilot 的深度集成。截至 22.4.1（2026 年 3 月），Copilot 在 SSMS 中已正式 GA，支持在查询编辑器中自动补全代码、通过聊天窗口直接向 Copilot 询问数据库信息，Copilot 还可以帮助改进查询、检测索引和统计信息、生成查询等。

此外，SSMS 22 新增的 查询提示推荐工具 可自动分析查询并推荐合适的查询提示；ARM64 架构的支持也让 macOS 用户使用体验更加流畅。

2.2 优化锁定 + ADR：高并发场景的黄金组合

在高并发 OLTP 环境中，锁争用和阻塞往往是性能瓶颈的根源。SQL Server 2025 引入了 优化锁定（Optimized Locking） 机制，能够在保持数千个行锁的同时，推迟甚至避免升级到表锁，从而显著降低阻塞和竞争。

这一机制与 加速数据库恢复（ADR） 深度绑定——优化锁定依赖 ADR 管理事务回滚和清理。ADR 启用后，长事务回滚不再是“盯着‘rolling back transaction…’发呆”的痛苦体验，取消的查询能快速清理，崩溃恢复时间大幅缩短。

2.3 tempdb 资源治理：终结“一个查询撑爆整个库”的噩梦

这是 DBA 群体期待已久的功能。SQL Server 2025 中，资源调控器（Resource Governor）终于可以限制每个工作负载对 tempdb 空间的使用量。配置示例：

-- 启用资源调控器
ALTER RESOURCE GOVERNOR RECONFIGURE;
GO

-- 创建限制 tempdb 用量为 25% 的工作负载组
CREATE WORKLOAD GROUP ReportingGroup
WITH (GROUP_MAX_TEMPDB_DATA_PERCENT = 25);
GO

ALTER RESOURCE GOVERNOR RECONFIGURE;
GO

这样一来，即使某个报表查询存在严重的数据溢出，也无法消耗超过 25% 的 tempdb 空间，生产环境的其他工作负载不会因此遭受“池鱼之殃”。

更值得关注的是，资源调控器现在已在 Standard Edition 中可用，这对于使用标准版的企业而言是一个实质性的运维能力跃升。同时，tempdb 现在也可以开启加速数据库恢复，取消的查询能快速清理，tempdb 日志可更积极地截断。

2.4 查询存储（Query Store）与智能查询处理（IQP）协同

查询存储是 DBA 手中的性能诊断利器。在 SQL Server 2025 中，查询存储功能已扩展到 Always On 可用性组的可读辅助副本，DBA 在任何副本上都能获得统一的性能视图。

智能查询处理（IQP）体系在 2025 版本中显著强化：

IQP 功能 说明
可选参数计划优化（OPPO） 在运行时根据参数是否为 NULL 自动选择最优计划，解决存储过程因可选参数导致的性能不一致
表达式的基数估计（CE）反馈 从前序执行中学习，自动将适当的 CE 模型应用于未来查询中的重复表达式
OPTIMIZED_SP_EXECUTESQL 减少动态查询的编译风暴，大量使用动态 SQL 的环境（如 Navision、AX）将显著受益
自适应参数优化（APPO） 根据参数值实时选择不同计划，一个小参数走嵌套循环，一个大参数自动切换为哈希连接

IQP 的核心价值在于从被动响应走向主动优化——引擎不再等待 DBA 介入，而是通过持续反馈和 AI 技术自行检测低效计划并替换或修改。

2.5 ZSTD 备份压缩：更快、更省、更稳

SQL Server 2025 新增 ZSTD（Zstandard）备份压缩算法，相比传统压缩提供更高的压缩比和更快的压缩速度。对于备份窗口紧张或存储成本敏感的环境，这是一个立竿见影的收益。

三、性能调优实战案例：真实负载下的验证

理论之外，真实负载下的性能表现才是 DBA 最关心的问题。以下是几组关键场景的实战验证：

案例一：优化锁定 + ADR 在高并发 OLTP 环境中的效果

在一组针对 20,000 行数据的并发更新测试中，SQL Server 2025 的优化锁定配合 ADR，成功将锁升级阈值大幅提升——在 SQL Server 2022 中，修改约数千行可能触发全表锁，而在 2025 版本中系统能够保持行级锁的精细粒度，显著降低阻塞和竞争。已在真实生产工作负载中验证了其对并发性能的实质提升。

案例二：tempdb 资源治理防止单个查询影响全局

通过资源调控器对报表查询设置 GROUP_MAX_TEMPDB_DATA_PERCENT 限制，即使存在数据溢出严重的查询，tempdb 使用量也被有效控制在指定阈值内，确保了 OLTP 核心业务不受影响。资源调控器在 Standard Edition 中可用后，这一能力惠及更广泛的企业用户。

案例三：参数敏感计划优化消除“计划抖动”

使用 REGEXP_LIKE 配合正确的索引策略，查询性能相比传统 CLR 方案实现了数量级的提升。而参数敏感计划优化机制则解决了存储过程因不同参数值执行计划“时好时坏”的长期痛点。

案例四：混合搜索——向量 + 全文 + 过滤的组合应用

传统的全文索引可以找到“red bike”，但无法理解“crimson bicycle”与“red bike”的语义关联；而向量搜索恰好填补了这一空白。SQL Server 2025 支持将向量相似性搜索与全文检索及结构化过滤条件组合执行，例如：先通过结构化过滤缩小范围，再在子集中执行语义相似性排序。结合 DiskANN 索引，即使数据规模达到数亿级别，检索性能仍然保持稳定。

四、综合建议：何时升级，何时观望

4.1 SQL Server 2022 vs. 2025：差异化价值评估

维度 SQL Server 2022 SQL Server 2025 升级价值
AI 与向量 需外部工具 原生向量 + DiskANN + T-SQL AI 函数 高（语义搜索、RAG 直接落地）
JSON 支持 字符串模拟 原生数据类型 + 索引 + 聚合函数 高（性能与开发体验双提升）
正则表达式 CLR 曲线救国 原生函数（SARGable） 高（性能与简化部署）
优化锁定 锁升级阈值固定 ADR 驱动的智能锁定 中高（高并发环境受益明显）
tempdb 治理 无资源限制 Resource Governor + Standard Edition 可用 高（多租户/共享环境刚需）
CES CDC（拉取 + 内部表） 推送式事件流 中高（事件驱动架构必选）
备份压缩 BACKUP COMPRESSION ZSTD 算法 中（更快更省）
资源调控器 仅 Enterprise Edition Standard Edition 可用 中高（标准版用户获益）

4.2 建议尽快升级的场景

  • AI 应用路线图中包含语义搜索、RAG 或向量检索：原生向量支持是 SQL Server 2025 的核心差异化优势，避免了引入独立向量数据库带来的架构复杂度。
  • 存在明显的锁争用或 tempdb 资源竞争问题：优化锁定和 tempdb 治理是专门为这类环境设计的能力。
  • 正在使用 SQL Server 2014 或 2016 版本：扩展支持已结束或即将结束，升级需求最为迫切。
  • 需要将数据实时推送到事件中心：CES 相比 CDC 的 I/O 开销更低，配置更简洁。
  • 大量使用 JSON 或正则表达式进行数据处理：原生支持带来的性能和开发体验提升是质的飞跃。
  • Standard Edition 用户需要资源管控能力：资源调控器在 SQL Server 2025 Standard Edition 中可用，这是 2022 版本不具备的能力。

4.3 建议审慎评估的场景

  • 重度依赖 SQL Server Reporting Services（SSRS）且 RDL 报表占主导：SSRS 不再捆绑在 SQL Server 2025 安装程序中，SSRS 2022 仍可独立安装并支持至 2033 年，升级前需规划报表方案的迁移或保留。
  • 使用 Master Data Services（MDS）或 Data Quality Services（DQS）：这些组件已被标记为移除，需要提前规划替代方案。
  • 运行在 SUSE Linux Enterprise Server（SLES）上：SLES 自本版本起不再受支持，需要迁移至 RHEL 或 Ubuntu。
  • 使用机器学习服务器中的 R/Python/Java 运行时：这些运行时已被弃用，升级前需迁移至外部包和服务。

4.4 升级流程标准化框架

无论何种场景，建议遵循以下流程：

阶段 关键动作
盘点与发现 使用 SSMS 22 的 Migration Hub 识别所有实例及依赖关系
兼容性评估 运行评估报告，重点关注 MDS/DQS 移除、SLES 停用等阻塞项
目标环境准备 安装 SQL Server 2025，配置兼容性级别 170 以启用新 IQP 功能
迁移执行 使用 SSMS 迁移组件，选择就地升级或并排迁移
后迁移验证 验证架构、权限、性能基线，选择性启用预览功能（通过 PREVIEW_FEATURES）
版本兼容性提示：SQL Server 2025 数据库内部格式升级为永久变更，升级后将无法降级回 2022。生产环境升级前务必在测试环境中完成充分的性能验证。

五、系列总结

回顾整个系列，SQL Server 2025 的革新覆盖了从核心引擎到应用开发的全栈：

  • 第一期聚焦 AI 深度集成——原生向量数据类型、DiskANN 索引、T-SQL AI 函数和 ONNX 本地模型托管，标志着数据库从“数据容器”向“智能引擎”的范式转变。
  • 第二期关注企业级高可用与混合架构——包含的可用性组（CAG）、Fabric 镜像、PolyBase 数据虚拟化，展示了跨越本地与云端边界的统一数据平台。
  • 第三期（本期）通过开发者实战、DBA 运维、性能调优和升级建议，全景呈现了新版本在生产环境中的落地路径与决策框架。

SQL Server 2025 遵循固定生命周期政策，主流支持持续至 2030 年，扩展支持至 2035 年。无论您是正在规划 AI 应用的开发者、忙碌于日常运维的 DBA，还是制定技术路线的架构师，SQL Server 2025 都提供了值得认真评估的新能力。建议从最贴近当前痛点的功能切入，在充分测试的基础上逐步推进——毕竟，最好的升级时机是准备好了的那一刻，而不是最新版本发布的那一刻。

参考资源

系列结语：至此，SQL Server 2025 新技术系列三期已全部推出。从 AI 内嵌到高可用架构，再到开发运维实战，我们共同见证了数据库技术的一次深刻变革。感谢您的持续关注！

Article copyright statement
Star
Donate
SQL Server 2025 新技术系列介绍（第二期）
Previous
PostgreSQL 架构原理第一期：从进程模型到核心内存机制
Next

Leave a comment

Registration is not required

Recommendation

HiddenMerit Daily · Issue 23

HiddenMerit Daily · Issue 23

📊 HiddenMerit Daily · Issue 23 Focus on Database Frontiers, Practical Insights for DBAs May 18, 2026 ｜ 5 Selected Global Breaking News 01｜Vastbase Plans Private Placement of RMB 702M, Doubles Down on HTAP and Multi‑Modal Time‑Series Database On the evening of May 11, Vastbase (603138.SH) disclosed its 2026 private placement plan, aiming to raise up to RMB 702 million. The entire amount will be invested in two cutting‑edge R&D projects: RMB 489 million for a next‑generation high‑performance hybrid transaction/analytical database (HTAP) project, and RMB 213 million for a multi‑modal time‑series database project. Vastbase believes that the traditional “OLTP database + OLAP data warehouse” separated architecture can no longer meet the real‑time, integrated, and high‑concurrency requirements of core scenarios such as finance, retail, telecommunications, and manufacturing. The drawbacks – high O&M costs, data synchronization latency, and difficulty ensuring consistency – have become prominent. The HTAP architecture, with its two core technical advantages of row‑column hybrid storage and unified transaction/analytics processing, can deliver both high‑concurrency transaction performance and batch analytical efficiency. The multi‑modal time‑series database project targets core needs in emerging scenarios such as industrial IoT and energy dispatch, aiming to solve the heavy reliance on foreign technology and insufficient multi‑modal […]
DailyIssue DBA
Clyde Jin
05-18
215 0 0
PostgreSQL 存储与索引系列（三）：查询优化实战——执行计划、统计信息与反模式诊断

PostgreSQL 存储与索引系列（三）：查询优化实战——执行计划、统计信息与反模式诊断

PostgreSQL 存储与索引系列（三）：查询优化实战——执行计划、统计信息与反模式诊断 这是系列第三期，聚焦查询优化。我们将深入解读执行计划，学习如何利用统计信息和 ANALYZE 做出正确决策，识别并避免常见的慢查询反模式，并借助 pg_stat_statements 等工具定位真实瓶颈。前两期关于存储页、可见性映射和各类索引的知识，将在这里融会贯通。 1. 执行计划：读懂 PostgreSQL 的每一步 EXPLAIN 是分析查询性能的首要工具。加上 ANALYZE 会真实执行并返回实际行数、耗时、内存等；加上 BUFFERS 可查看缓存命中情况；加上 VERBOSE 输出额外细节。 核心节点类型 顺序扫描 (Seq Scan) 性能特点：读取表的全部页面，适合小表或预计返回大部分行的查询。 是否应该出现：大表上出现 Seq Scan 通常意味着缺少有效索引，或优化器低估了选择性。 索引扫描 (Index Scan) 过程：通过索引获得匹配行的 ctid，逐个回表获取元组。 效率条件：回表次数多时可能慢，因为随机 I/O 成本高。如果表页面已经缓存，影响会减小。 仅索引扫描 (Index Only Scan) 原理：索引包含查询所需的所有列，且可见性映射（VM）标记相应页面为 all_visible，因此无需回表。 关键：定期 VACUUM 保证 VM 及时更新。如果扫描发现 VM 过时，仍会回表并更新 VM。 位图扫描 (Bitmap Scan) 组成：Bitmap Index Scan + Bitmap Heap Scan。 过程：先通过索引收集所有匹配行的 ctid，生成位图（每个数据页一个比特）；然后按磁盘顺序回表扫描页面。适合返回较多行（如 5%~20%）时，减少随机 I/O。 为什么好：避免 Index Scan 的大量离散随机回表。 连接节点 Nested Loop：对左表的每一行，扫描右表。适合小表驱动或右表有高效索引。复杂度 O(N * M)。 Hash Join：构建右表的哈希表，然后左表探测。适合无索引的大表连接，内存足够时速度快。 Merge Join：两边按连接键排序后合并。适合两表已有序或连接条件为等值且列可排序。 解读 EXPLAIN ANALYZE 的关键指标 actual time：实际执行时间（首次行产出到完成）。 rows：实际行数 vs 估计行数 —— 如果偏差巨大，说明统计信息过期或分布不均。 loops：某些节点（如 Nested Loop 内层）可能执行多次。 buffers：shared hit（缓存命中）、read（磁盘读）、dirtied、written。高 read 说明冷数据或内存不足。 Planning Time 和 Execution Time：规划时间过长可能因为复杂视图或大量分区。 示例分析 EXPLAIN (ANALYZE, BUFFERS, VERBOSE) SELECT * FROM orders WHERE customer_id = 12345 AND status = 'paid'; 如果看到 Seq Scan on orders，且 filter 条件为 customer_id=12345，则需要检查索引。 若使用 Bitmap Index Scan 然后 Bitmap Heap Scan，实际行数远大于估计，则需 ANALYZE。 若执行 Index Only Scan 却回表很多（Heap Fetches 列），说明 VM 不够新，应运行 VACUUM。 2. 统计信息：优化器的眼睛 PostgreSQL 优化器基于表、列、表达式和索引的统计信息估算行数和成本。统计信息存储在 pg_statistic 中，可通过 pg_stats 视图方便查看。 关键统计指标 n_distinct：唯一值数量。负数表示比例（如 -0.1 代表 10% 的行是唯一值）。影响等值查询选择性估算。 most_common_vals / most_common_freqs：高频值及其频率。优化器知道 status='paid' 占 90% 时会选择全表扫描。 histogram_bounds：直方图边界，用于范围查询估算。 correlation：物理存储顺序与逻辑顺序的相关性（-1 到 1）。绝对值接近 1 说明列值与物理位置排序一致，利于索引范围扫描（例如自增主键）。接近 0 则不适合 BRIN 或重点考虑聚类。 ANALYZE 与统计信息维护 手动执行：ANALYZE table_name; 它会收集当前表及其所有索引的统计信息。 Autovacuum 会自动触发 ANALYZE，当表中修改行数超过阈值（autovacuum_analyze_threshold + autovacuum_analyze_scale_factor * reltuples）。 调整统计精度：ALTER TABLE ... ALTER COLUMN ... SET STATISTICS 1000;（默认 100）。更高的值让直方图更精确，但增加分析时间。 极端情况：对于一些不均匀分布或非常活跃的表，可以增加统计目标，甚至手动设置某些列的 […]
DBA
Clyde Jin
04-24
44 0 0
HiddenMerit Daily · Issue 10

HiddenMerit Daily · Issue 10

📊 HiddenMerit Daily · Issue 10 Focus on Database Frontiers, Practical Insights for DBAs May 5, 2026 ｜ 5 Selected Global Breaking News 01｜OceanBase Fully Discloses Global Business for First Time: Covering Over 1.3 Billion Users, Overseas Revenue Up 200% On May 3, at the Infinity2026 conference held in Kuala Lumpur, Malaysia, OceanBase for the first time fully disclosed its global business progress, and simultaneously announced the launch of its Global Support Center in Kuala Lumpur, promising 7×24 hour response – another core hub following its Singapore international headquarters. Public data shows that in the fintech sector, OceanBase has served over 100 enterprises, covering more than 20 e-wallets and over 50 payment platforms, with its customers collectively covering more than 1.3 billion end users. In traditional finance sectors such as banking, it has served over 400 financial institutions, including banks, insurance companies, and wealth management firms, with more than 60% deploying OceanBase in their core business systems. Customers include cross‑border institutions like HSBC and Hang Seng Bank. Among its benchmark clients, the Philippines’ top national super app GCash reduced storage space by 70% and resource costs by 40% after migration, while Malaysia’s TNG eWallet, which has over 26 million verified […]
DBA
Clyde Jin
05-05
171 0 0
HiddenMerit Daily · Issue 26

HiddenMerit Daily · Issue 26

📊 HiddenMerit Daily · Issue 26 Focus on Database Frontiers, Practical Insights for DBAs May 21, 2026 ｜ 5 Selected Global Breaking News 01｜Google Urges PostgreSQL Developers to Leverage AI Coding at Scale, Alibaba Cloud Leads Domestic Open‑Source Contributions On May 20, Google published a strong call for PostgreSQL developers to “massively” adopt AI coding tools for code generation, testing, and optimisation during development. This statement comes as Google increases its contributions to open‑source projects like PostgreSQL – earlier this year, Google contributed a series of new PostgreSQL code, including parallel hash join optimisations and new performance monitoring infrastructure. Google’s core argument is that human‑AI collaboration can dramatically reduce monotonous, repetitive tasks in database kernel development, allowing developers to focus on more complex system logic innovation. Since the beginning of this year, the penetration of AI‑assisted coding tools in database kernel development has significantly increased. At the same time, Alibaba Cloud has recently completed large‑scale kernel‑level contributions from PolarDB to the PostgreSQL community, covering key modules such as executor optimisation and lock manager enhancements, demonstrating that the technology backflow path of domestic databases into the open‑source ecosystem is becoming increasingly mature and systematic. · DBA Perspective: The examples from Google […]
DailyIssue DBA
Clyde Jin
05-21
119 0 0
PostgreSQL 架构原理第四期：查询优化器 —— 统计信息与代价模型

PostgreSQL 架构原理第四期：查询优化器 —— 统计信息与代价模型

PostgreSQL 架构原理第四期：查询优化器 —— 统计信息与代价模型 引言 在前三期的基础上，我们已经了解了 PostgreSQL 的进程模型、存储引擎以及事务并发控制。从用户提交一条 SQL 到真正执行，中间有一个至关重要的环节——查询优化器。它负责在众多可能的执行路径中，找出预计代价最小的那个执行计划。优化器之所以能做出相对准确的决策，核心依赖于两样东西：表的统计信息 和 代价模型。 本期我们将深入剖析： 统计信息的收集与存储：ANALYZE 命令、pg_statistic 系统表、pg_class 中的基本统计 最常见的数据分布：NULL 分数、唯一值数量、高频值（MCV）、直方图 代价模型中的启动代价、运行代价、总代价以及各种操作的代价估算公式 单表扫描（顺序扫描、索引扫描、位图扫描）的代价计算 连接操作的代价估算（嵌套循环、哈希连接、归并连接） 统计信息过时或不准时的应对策略 一、统计信息的收集：ANALYZE 命令 统计信息是优化器的“眼睛”。PostgreSQL 通过 ANALYZE 命令（包含在 VACUUM ANALYZE 或自动 autovacuum 中）收集表和索引的统计信息。 1.1 基本统计存储位置 pg_class：存储表级和索引级的全局统计，如： reltuples：表的总行数估计值 relpages：表的磁盘页数（1 页 = 8KB） relallvisible：可见性映射中标记为全部可见的页数 relfrozenxid：表的冻结阈值 pg_statistic：存储每个列的具体数据分布统计。为了安全，普通用户只能通过视图 pg_stats 查看，其内容经过脱敏（例如去除隐私数据）。 1.2 ANALYZE 的工作原理 ANALYZE 并不扫描全表（除非表很小），而是采用采样方法： 从每个表或索引中随机抽取约 30000 行（由 default_statistics_target 控制，默认 100，实际采样行数为 300 × 目标值，因为内部乘了 300 的因子）。 对每个目标列进行统计： null_frac：NULL 值比例 n_distinct：不同值的数量（如果为负数，表示比例；例如 -0.1 表示大约有 0.1 * 总行数） most_common_vals 和 most_common_freqs：最常见的值及其出现频率 histogram_bounds：等频直方图边界值（当值种类超过一定数量时，不存储 MCV 而使用直方图） correlation：物理行序与逻辑值的相关性（-1 到 1），影响索引扫描代价 采样完成后，将统计信息存入 pg_statistic 并更新 pg_class.reltuples 和 relpages。 1.3 统计信息收集参数 default_statistics_target：默认 100。增大该值会提高采样行数，得到更精确的统计，但 ANALYZE 时间和内存消耗会增加。 可以为特定列设置更高的目标：ALTER TABLE t ALTER COLUMN c SET STATISTICS 500; 自动 ANALYZE 由 autovacuum 触发，当表修改行数达到一定阈值时自动运行。 二、代价模型的基本概念 PostgreSQL 采用基于代价的优化（cost-based optimization），为每个可能的执行计划节点计算一个浮点数值代价。代价的单位并不是真实的时间，而是磁盘顺序页读取的耗时作为基准单位。其他操作（如 CPU 处理、随机页读取）的代价都相对于此进行量化。 2.1 代价的组成部分 每个计划节点都包含三个主要代价字段： startup_cost：获取第一条返回行之前需要付出的代价。例如对索引扫描，需要先读取索引找到第一匹配项。 total_cost：获取所有行（假设所有行都被检索）的总代价。 run_cost = total_cost – startup_cost，通常不直接显示，但内部计算会用到。 优化器最终选择 total_cost 最小的完整计划树，但当使用游标或限制子句时，startup_cost 可能会更重要（例如希望尽快返回第一行）。 2.2 代价参数 代价公式中可配置的成本因子参数（均位于 postgresql.conf）： 参数 默认值 含义 seq_page_cost 1.0 顺序页读取代价（基准） random_page_cost 4.0 随机页读取代价（通常设为 1.5~2.0 对于 SSD） cpu_tuple_cost 0.01 处理一个元组的 CPU 开销 cpu_index_tuple_cost 0.005 索引扫描时处理一个索引元组的开销 cpu_operator_cost 0.0025 执行一个操作符或函数的开销（如 =、+） parallel_setup_cost 1000 并行查询启动子进程的代价 parallel_tuple_cost 0.1 并行查询中传输一个元组的代价 这些参数可以根据硬件特性调整，例如在全闪存存储上降低 random_page_cost 可以提高索引扫描的竞争力。 2.3 代价计算公式举例 处理一个元组的 CPU 代价通常为 cpu_tuple_cost。处理一个 WHERE 子句中的操作符代价为 cpu_operator_cost 乘以操作符个数。读取一个数据页的代价根据顺序或随机读取而不同。 三、单表扫描的代价估算 3.1 顺序扫描（Seq Scan） 顺序扫描整个表，读取所有页面。代价公式： startup_cost = 0 run_cost = (pages × seq_page_cost) + (tuples × cpu_tuple_cost) total_cost = run_cost 其中 pages = pg_class.relpages，tuples = pg_class.reltuples。 […]
DBA
Clyde Jin
04-24
37 0 0
第三期：PG 19 新特性全景解读

第三期：PG 19 新特性全景解读

第三期：PG 19 新特性全景解读 从原生图查询到执行计划“锁死”，2026年最值得关注的数据库版本来了 2026年4月8日，PostgreSQL 19正式进入特性冻结阶段，意味着所有新功能已锁定，后续开发重心全面转向稳定化测试与Bug修复。目标发布时间为2026年9月，Beta测试预计于5月启动。随着Bruce Momjian完成PG 19发布说明的首个草稿，这个年度重磅版本的全貌正逐渐清晰。 PG 19延续了PG社区“插件验证→内核化收敛”的演进路径，多个曾在扩展生态中充分验证的能力正式进入内核——SQL/PGQ图查询、原生REPACK表重整、执行计划锁定等重磅功能同时落地，标志着PostgreSQL在“多模数据平台”的战略方向上迈出了关键一步。 一、SQL/PGQ图查询：关系型数据库的“图思维”革命 1.1 从扩展到内核：图查询的“毕业”时刻 PG 19最受瞩目的新特性，无疑是SQL/PGQ属性图查询的原生支持。此前，在PostgreSQL中实现图查询主要依赖Apache AGE扩展、AgensGraph分支或pgRouting算法库。PG 19将图查询能力直接纳入内核，用户无需安装任何扩展，即可使用标准SQL语法在PostgreSQL内部执行属性图查询。 SQL:2023标准引入了SQL/PGQ，首次允许关系型数据库将图遍历视为一等公民的声明式操作。PG 19对这一标准的落地，不仅是语法层面的支持，更是PostgreSQL从关系型数据库向多模数据平台演进的重要里程碑。 1.2 实际应用场景：知识图谱与社交网络 图查询的核心价值在于表达实体之间复杂的关联关系。一个典型的场景是知识图谱——如“查找A的关联人员中，谁与B有过直接交易”这类多层关联查询，在传统SQL中需要复杂的自连接与递归CTE，在图查询中则可以用一条清晰的路径表达式完成。社交网络关系分析、推荐系统的协同过滤、欺诈检测中的资金链路追踪等场景，都能从中直接受益。 1.3 与向量检索形成“语义+关系”双轮驱动 结合上一期讨论的pgvector向量检索能力，PG 19的图查询进一步丰富了数据库的表达范式。向量检索擅长“模糊语义匹配”（如“找出与这张图片相似的图片”），图查询擅长“精确关系遍历”（如“找出这张图片的所有上传用户的好友关系”）。两者结合，PostgreSQL在多模数据场景下的覆盖广度达到了前所未有的水平。 二、pg_plan_advice：执行计划的“终极掌控” 2.1 DBA的噩梦：执行计划突然跑偏 一条长期稳定运行的核心SQL，可能因为统计信息更新、数据库版本升级、配置参数调整，突然被查询规划器选择了错误的执行计划，导致性能从毫秒级暴跌至秒级甚至分钟级。此前，DBA只能通过第三方插件pg_hint_plan、重写SQL或调整全局参数来临时解决，不仅门槛高、兼容性风险大，还缺乏官方原生的稳定支持。 2.2 路径生成策略：扩展规划器的底层钩子 PG 19引入的路径生成策略（Path Generation Strategies）机制，为插件提供了在查询规划器最早阶段影响决策的能力。传统规划器的工作流程是先产生多条路径（如顺序扫描、索引扫描、Hash连接等），再通过成本比较淘汰劣质路径。但由于规划器可能在成本比较早期就丢弃一些路径，扩展插件在旧框架下很难强制保留特定计划。路径生成策略机制解决了这一根本性问题，使插件能够在内核层面稳定地影响规划决策。 2.3 pg_plan_advice使用方法 pg_plan_advice作为contrib模块随PG 19一同发布，提供原生的执行计划锁定能力。核心使用流程如下： 第一步：获取计划建议字符串 EXPLAIN (COSTS OFF, PLAN_ADVICE) SELECT * FROM join_fact f JOIN join_dim d ON f.dim_id = d.id; 系统会返回类似如下的建议字符串： JOIN_ORDER(f d) HASH_JOIN(d) SEQ_SCAN(f d) NO_GATHER(f d) 其中：JOIN_ORDER(f d)指定以f表为驱动表、d表为关联表；HASH_JOIN(d)指定d表作为哈希连接的内表；SEQ_SCAN(f d)指定对两表均使用顺序扫描；NO_GATHER(f d)指定不将两表置于并行Gather节点之下。 第二步：应用计划建议 通过GUC参数将建议字符串应用到后续查询中： SET pg_plan_advice.advice = 'JOIN_ORDER(f d) HASH_JOIN(d) SEQ_SCAN(f d) NO_GATHER(f d)'; 用户还可以编辑建议字符串，仅保留需要强制生效的部分。例如，仅需控制连接顺序时，可仅设置JOIN_ORDER部分。 2.4 对pg_hint_plan生态的影响 路径生成策略机制的最大受益者是pg_hint_plan等第三方提示插件。在新框架下，pg_hint_plan预计可减少约2500行代码，实现更简洁、更可靠的执行计划提示能力。这也标志着PostgreSQL从“抗拒查询提示”到“开放官方扩展接口”的重要转变。 三、分区管理的“平民化”：MERGE/SPLIT PARTITIONS 3.1 从复杂脚本到一行命令 分区表的动态管理一直是PostgreSQL DBA的痛点。在PG 19之前，将多个分区合并为一个，或将一个大分区拆分为多个，往往需要手动创建新分区、迁移数据、删除旧分区等一系列复杂操作，极易出错。PG 17曾尝试引入分区合并与拆分命令，但补丁在发布前不久被回退。PG 19以更稳健的实现方式完成了第二次尝试。 3.2 典型操作示例 以按月份分区的航班预订表为例，合并去年第四季度的三个分区： -- 合并三个月份分区为一个季度分区 ALTER TABLE bookings_range MERGE PARTITIONS (p2025_10, p2025_11, p2025_12) INTO p2025; -- 将季度分区重新拆分为月份分区 ALTER TABLE bookings_range SPLIT PARTITION p2025 INTO ( PARTITION p2025_10 FOR VALUES FROM ('2025-10-01') TO ('2025-11-01'), PARTITION p2025_11 FOR VALUES FROM ('2025-11-01') TO ('2025-12-01'), PARTITION p2025_12 FOR VALUES FROM ('2025-12-01') TO ('2026-01-01') ); 3.3 当前限制与未来展望 目前，MERGE和SPLIT PARTITIONS命令会在整个执行期间对父表加排他锁，因此不应在业务高峰期运行。但这一功能为未来的锁级别优化和并行执行奠定了坚实基础。对于需要定期调整分区策略的数据生命周期管理场景，这一特性显著降低了运维复杂度。 四、逻辑复制：告别“重启恐惧症” 4.1 动态WAL级别调整 长期以来，PostgreSQL逻辑复制和逻辑解码（CDC）的使用存在一个令人困扰的痛点：必须在数据库启动前将wal_level设置为logical并重启实例。这意味着即便没有任何逻辑复制任务运行，数据库也要持续承担logical级别WAL日志带来的额外I/O和存储开销。 PG 19彻底解决了这一问题。系统现在可根据逻辑复制槽的存在与否，自动动态调整WAL级别：创建第一个逻辑复制槽时，有效WAL级别自动提升至logical；当最后一个逻辑槽被删除或失效后，有效级别降回replica。新增的只读GUC参数effective_wal_level可用于监控当前实际生效的WAL级别。 4.2 发布订阅的精细控制 PG 19还允许在ALTER PUBLICATION中使用EXCEPT TABLE子句，实现对发布订阅中特定表排除的精细控制。这一改进在租户隔离和选择性数据同步场景中尤为实用。 五、pg_dump增强：统计信息的“完整闭环” 5.1 从PG 18到PG 19：统计信息能力的持续进化 PG 18引入了表级和列级统计信息的导出与恢复能力，解决了大版本升级后因统计信息丢失导致执行计划不准的“升级即事故”风险。PG 19在此基础上更进一步，新增了扩展统计信息（Extended Statistics）的完整支持。 5.2 扩展统计信息的导出与恢复 通过--statistics参数，pg_dump现在可以导出由CREATE STATISTICS创建的三种扩展统计类型（ndistinct、dependencies和MCV），并通过pg_restore_extended_stats函数在目标数据库中恢复。 使用示例： # 仅导出统计信息（不含表结构和数据） pg_dump --statistics-only -d production_db > stats.sql # 导出表结构+统计信息（用于测试环境搭建） pg_dump --schema-only --statistics -d production_db > schema_with_stats.sql 导出文件为纯SQL格式，包含三个还原函数pg_restore_relation_stats（表级）、pg_restore_attribute_stats（列级）和pg_restore_extended_stats（扩展级）的调用语句，可直接在目标环境执行导入。 5.3 生产环境对齐的“杀手级”能力 这一特性对生产环境问题复现和测试环境对齐具有极高价值。DBA可以从生产库导出精准的统计信息并在测试库中恢复，使查询规划器在两个环境中做出相同的决策，从根本上消除“生产复现不了”的困境。 六、REPACK内核化：表膨胀治理进入新时代 6.1 从外部工具到原生命令 pg_repack长期以来作为PostgreSQL社区最受欢迎的第三方运维工具之一，以“在线重整表数据、仅需最少锁”的能力解决了VACUUM FULL需要排他锁的痛点。PG […]
DBA
Clyde Jin
04-23
54 0 0
Clyde Jin
302 Articles
0 Comments
0 Like
Recent Posts
HiddenMerit Daily · Issue 59

HiddenMerit Daily · Issue 59

📊 HiddenMerit Daily · Issue 59 Focus on Database Frontiers, Practical Insights for DBAs July 21, 2026 ｜ 5 Selected Global Breaking News 01｜Oracle Issues Urgent Warning: July 21 Release Update to Fix Large Number of High‑Risk Vulnerabilities, Immediate Deployment Recommended On July 13, Oracle issued an urgent security warning, strongly recommending that all customers running supported Oracle Database versions (including Oracle Database 19c and Oracle AI Database 26ai) immediately test and deploy the Release Update (RU) after its release on July 21. Background: New frontier AI models are significantly lowering the barrier to discovering and exploiting software vulnerabilities – these models can identify weaknesses, analyse software changes, reverse‑engineer security patches, and develop potential attack paths at unprecedented speed and scale. AI models are also becoming increasingly adept at combining multiple weaknesses across the application and data stack into complex attacks, even when individual weaknesses do not themselves pose a serious risk. As a result, protecting systems solely at the network or application layer is no longer sufficient; enterprises must protect the entire technology stack. Fixes Included in This RU: Oracle has collaborated with state‑of‑the‑art models from Anthropic and OpenAI to proactively identify and fix potential security vulnerabilities. The upcoming […]
DailyIssue DBA
Clyde Jin
22 hours ago
5 0 0
HiddenMerit Daily · Issue 58

HiddenMerit Daily · Issue 58

📊 HiddenMerit Daily · Issue 58 Focus on Database Frontiers, Practical Insights for DBAs July 20, 2026 ｜ 5 Selected Global Breaking News 01｜CAICT: Domestic Databases Enter Core System “Deep Water,” AI‑Native Leads New Industry Landscape On July 9, at the 2026 Trustworthy Database Development Conference, CAICT released the “Database Development Research Report (2026).” The report notes that domestic databases have basically completed peripheral system replacement and have officially entered the critical business system breakthrough phase. Key Data: The global database market reached $131.6 billion in 2025 (approximately RMB 894.09 billion). The Chinese database market reached $9.49 billion in 2025 (approximately RMB 64.48 billion), and is expected to reach RMB 97.974 billion by 2028, with a CAGR of 13.06%. The number of domestic database vendors has shrunk from a peak of 167 to 94, with a clear head‑concentration effect and an intensifying “Matthew effect.” AI‑Native Becomes the Main Theme: The report points out that database technology is accelerating its evolution toward the AI‑native direction, and the global database industry is entering a new phase of landscape restructuring. The role of databases is upgrading from “underlying support systems” to “core engines enabling intelligent decision‑making and business innovation.” AI agents are becoming […]
DailyIssue DBA
Clyde Jin
1 day ago
11 0 0
HiddenMerit Daily · Issue 56

HiddenMerit Daily · Issue 56

📊 HiddenMerit Daily · Issue 56 Focus on Database Frontiers, Practical Insights for DBAs July 6, 2026 ｜ 5 Selected Global Breaking News 01｜Kingware Releases Manufacturing Scenario Database Evolution White Paper: SQL Server Replacement Enters “Deep Water” On July 5, CETC Kingware published a technical article titled “Database Evolution in Manufacturing Scenarios: How Kingware Replaces SQL Server,” pointing out that the data surge on industrial shop floors has exceeded the processing capacity of single‑node systems. Traditional database architectures that rely on vertical scaling are facing unprecedented performance challenges. Over the next 1‑3 years, manufacturing enterprises will no longer face only the “choice of replacement,” but must answer the strategic question: “How do we build an autonomous data foundation in the context of de‑IOE?” Three Paradigm Shifts: Hybrid Workloads Become the Norm: The IT architecture of modern factories is shifting from separated OLTP and OLAP to HTAP mode. The same data system must simultaneously handle tens of thousands of device instruction writes per second and minute‑level production report analysis. Distributed Architecture Becomes a Hard Requirement: When a single table exceeds 100 million rows with daily increments exceeding 1 million rows, the index maintenance cost of traditional single‑node databases rises exponentially. Autonomous […]
DailyIssue DBA
Clyde Jin
4 days ago
22 0 0
HiddenMerit Daily · Issue 57

HiddenMerit Daily · Issue 57

📊 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, […]
DailyIssue DBA
Clyde Jin
4 days ago
29 0 0
Tags
#Joke #Torn #life #Inspiration #Dairy #inspire #SQL #Server #网址搜集 #资源共享 #ChatGPT #Query Store #道德经 #读书 #apple music #dida #keep #GTD #题目 #纽曼 #腾讯课堂 #free #download #mp3 #Entertainment #SQL Server
生成中...
扫描二维码
扫描二维码