SQL Server 2025 新技术系列介绍（第二期）
Clyde Jin
04-23
DBA
92
本系列第一期回顾：SQL Server 2025 通过原生向量数据类型、DiskANN 索引、T-SQL AI 函数和 ONNX 模型本地托管，将 AI 深度集成至数据库内核，实现了从“存储数据”到“理解数据”的范式革命。本期作为系列第二期，我们将目光投向企业级生产环境的另一核心命题——高可用性、混合架构与数据迁移，详细解读 SQL Server 2025 在这些关键领域带来的实质性革新。

一、高可用性与灾难恢复：不止于“可用”，更追求“智慧”

对于承载核心业务的生产系统而言，高可用性（HA）与灾难恢复（DR）是生命线。SQL Server 2025 在这一领域的进化，核心可概括为 “降低复杂度、缩短停机时间、提升自动化水平”。

1.1 Always On 可用性组（AG）：围绕 DBA 痛点的精准改良

Always On 可用性组是 SQL Server 高可用体系的基石，2025 版本并未对架构进行颠覆，而是精准回应了 DBA 在日常运维中长期积累的痛点。次要副本现支持完整备份和差异备份，而不仅限于仅复制备份（copy_only），这意味着企业可以将备份任务从主副本安全地卸载到辅助副本，从而释放主副本的资源压力，同时仍能维持完整备份链的连续性。

可读辅助副本的生产力也得到实质性提升——查询存储（Query Store）数据现已同步到可读辅助副本，DBA 在任何副本上都能获得统一的性能视图，无需跨节点切换即可完成性能诊断。在配置与管理体验上，更完善的监控工具、更易发现的设置选项以及更友好的用户界面，都降低了 AG 的日常运维门槛。

1.2 包含的可用性组（CAG）：元数据自治的高可用单元

如果说传统 AG 简化的是数据库层面的高可用，那么 Contained Availability Group（CAG）则将这一简化扩展到了实例层面。CAG 的设计目标是通过将系统数据库（master、msdb）封装在可用性组内部，实现高可用和灾难恢复的全方位简化。这意味着登录名、作业、凭据以及其他元数据都会在各副本之间自动复制，彻底告别手动同步的运维负担。

从 SQL Server 2025 CU1 开始，CAG 的能力进一步提升：管理员可直接通过 CAG 监听器创建或还原数据库，而无需连接到物理 SQL Server 实例。这一能力通过启用会话上下文键或调用自动化存储过程 sp_sysutility_cag_create_db 即可实现，对限制直接访问 SQL 实例的生产环境尤为实用。

CAG 的核心价值在于：每个 CAG 都拥有独立的 master 和 msdb 副本，使其成为不依赖于物理 SQL 实例的自包含高可用单元。当 AG 发生故障转移时，所有相关元数据都会随之迁移，确保应用无需人工干预即可继续运行；同时，由于操作范围可限定在 AG 上下文内，系统的安全暴露面也得到了有效控制。

1.3 分布式可用性组（DAG）与故障转移优化

SQL Server 2025 对分布式可用性组（DAG）的支持进一步成熟，为跨地域的容灾部署提供了更稳健的基础。在故障转移体验方面，SQL Server 2025 包含了故障恢复过程的性能改进，配合增强的监控能力，显著减少了故障转移期间的停机时间。配合分布式网络名称（DNN）侦听器的使用，故障转移速度进一步提升：由于无需等待网络负载均衡器检测失败事件和变更路由，使用 DNN 时的故障转移时间显著缩短。

1.4 备份与恢复的现代化演进

SQL Server 2025 在备份领域引入了多项重要革新：新增 ZSTD 压缩算法作为备份压缩选项，相比传统压缩算法提供更高的压缩比和更快的压缩速度；S3 兼容对象存储备份全面进入生产可用状态，企业可以直接将数据库备份到 MinIO、Dell ECS、Cloudian 等各类 S3 兼容存储，为备份策略提供了前所未有的灵活性；Azure Blob 不可变存储支持在指定保留期内防止备份被篡改或删除，对金融、医疗等强合规行业至关重要。此外，加速数据库恢复（ADR） 机制在 SQL Server 2025 中得到进一步增强，大幅缩短了崩溃恢复和事务回滚的时间，为高可用性提供了底层支撑。

二、混合架构与云集成：跨越边界的统一数据平台

现代企业的数据基础设施几乎必然跨越本地、云端和边缘。SQL Server 2025 在这一领域的核心命题是：如何让数据在不同环境之间自由流动，同时保持管理的统一性与安全性？

2.1 Fabric 镜像：无 ETL 的准实时数据同步

Fabric 镜像是 SQL Server 2025 在混合架构领域最具突破性的功能。它允许将本地 SQL Server 数据库近乎实时地镜像到 Microsoft Fabric 的 OneLake 中，让运营数据立即可供 Power BI、Synapse 等分析工具消费，彻底绕开了传统 ETL 管道的复杂性。

在 SQL Server 2025 中，Fabric 镜像的核心机制从传统的变更数据捕获（CDC）升级为全新的 Change Feed。相比 CDC 需要在源数据库维护变更表、通过两步过程（日志 → 变更表 → OneLake）完成数据同步，Change Feed 直接高频扫描事务日志并将已提交变更发布到 OneLake，消除了中间的写入步骤。

这一架构升级带来了多维度的收益：降低性能开销——没有变更表需要维护，没有 SQL Agent 作业需要管理，对于繁忙的 OLTP 系统是实质性的改善；更强的 DDL 适应性——检测到表结构变更时自动触发完整重新快照并重新播种，实现了自愈能力，避免镜像因一次部署而中断整个周末；更简洁的权限模型——不再要求 sysadmin 角色进行配置，满足了安全敏感型组织的合规要求。

需要注意的是，Fabric 镜像要求 SQL Server 实例启用 Azure Arc，通过本地数据网关配置安全连接。当前版本在架构演进、大表处理和初始化行为方面仍存在一定限制，生产环境部署前需进行充分评估。

2.2 Azure Arc：混合环境的统一管理平面

如果说 Fabric 镜像解决的是数据流动的问题，那么 Azure Arc 解决的则是混合环境的管理难题。通过 Azure Arc，企业可以将本地 SQL Server 实例扩展到 Azure 管理平面，获得统一的治理、监控和安全体验，无论 SQL Server 运行在 Windows、Linux 还是 Kubernetes 集群上。

SQL Server 2025 显著增强了与 Azure Arc 的集成深度：改进的遥测和修补自动化——除免费库存管理外，还提供自动备份和修补功能；Microsoft Entra ID 身份验证——支持集中式身份管理、多因素认证以及托管标识，简化了混合环境的安全访问控制；即用即付（Pay-As-You-Go）计费模型——为需要灵活许可管理的场景提供了经济高效的选项；最佳做法评估——提供针对混合架构定制的改进建议和扩展评估规则，帮助识别配置偏差和安全风险。在安全管理层面，Azure Arc 与 Microsoft Defender for Cloud 的集成提供了基于智能能力的实时威胁检测和响应。

2.3 托管身份与安全连接

安全是混合架构的基础前提。SQL Server 2025 引入了 Microsoft Entra ID 托管身份验证体系，PolyBase 现支持使用托管身份与 Azure Blob Storage 和 Azure Data Lake Storage 安全通信，实现了无密码的云访问。配合整个 SQL Server 生态向 TLS 1.3 和 TDS 8.0 协议的全面迁移（SQL Agent、链接服务器、复制、Always On 可用性组等组件均已默认启用 TLS 1.3），SQL Server 2025 为混合架构构建了覆盖全面、默认安全的通信保护体系。

三、数据仓库与分析：数据虚拟化的全面增强

3.1 PolyBase 革命：无需安装，原生查询

PolyBase 是 SQL Server 数据虚拟化的核心引擎。SQL Server 2025 对 PolyBase 进行了重大重构：现在可以直接通过 OPENROWSET 或 CREATE EXTERNAL TABLE 查询 Parquet、CSV、Delta 文件以及 Azure Blob、ADLS、S3 等对象存储中的数据，而无需额外安装 PolyBase 查询服务。这项简化的体验极大降低了数据湖查询的入门门槛。

3.2 S3 兼容对象存储全面支持

SQL Server 2025 原生支持 S3 兼容对象存储，采用 REST API 连接器框架，兼容所有支持 S3 框架的存储解决方案（MinIO、Dell ECS、Cloudian、PureStorage 等），无论其部署在本地、云中还是混合环境。这一能力同时服务于数据虚拟化查询和数据库备份两大场景，为企业构建统一的存储层提供了新的可能性。

3.3 Linux 平台功能对齐

对于 Linux 用户，SQL Server 2025 在 CU1 中正式支持 Red Hat Enterprise Linux（RHEL）10 和 Ubuntu 24.04 的生产环境部署。PolyBase 在 Linux 上现已支持 ODBC 数据源，实现了与 Windows 平台的功能对齐。但需注意，SUSE Linux Enterprise Server（SLES）自本版本起不再受支持。

四、迁移与升级指南：从评估到投产的完整路径

4.1 告别 DMA：SSMS 22 一体化迁移组件

SQL Server 2025 将升级评估与迁移能力整合进 SSMS 22 的全新 Hybrid & Migration Component，正式取代了已于 2025 年 7 月 16 日停用的 Data Migration Assistant（DMA）。

这一体化工具体现为：升级评估——检测中断性变更、已弃用功能和行为变更，标记 Master Data Services（MDS）和 Data Quality Services（DQS）等已移除组件，并提供默认设置替换和功能替代（如 Fabric 镜像）的修复指导；迁移向导——采用备份-复制-恢复模式迁移数据库，支持传输登录名和并排升级，兼容本地、Azure SQL 和混合部署场景。

4.2 版本兼容性与升级路径

SQL Server 2025 引入新的数据库兼容性级别 170，支持从 100（SQL Server 2008）到 170 的多个级别。就地升级支持从 SQL Server 2014 SP3 及更高版本直接进行，而并排迁移则适用于需要同时变更操作系统或硬件的复杂场景。

在规划升级时，需特别关注已弃用功能清单：机器学习服务器及捆绑的 R/Python/Java 运行时、Distributed Replay、Stretch Database 均已被标记为弃用或移除，SUSE Linux Enterprise Server（SLES）支持也自本版本起终止。

4.3 最佳实践升级流程

综合以上内容，标准升级流程可归纳为五个关键步骤：

步骤 说明
1. 盘点与发现 使用 SSMS 或 Azure Migrate 识别所有 SQL Server 实例及其依赖关系
2. 兼容性评估 运行 SSMS Migration Assessment 识别升级阻塞点和已弃用功能
3. 业务策略决策 根据硬件/操作系统变更需求选择就地升级或并排迁移
4. 目标环境准备 配置 SQL Server 2025 或 Azure SQL 目标，确保适当的性能层级和容量
5. 迁移执行与验证 执行迁移后验证数据库架构、权限和性能，激活 AI 驱动等新功能

需注意，SQL Server 2025 遵循固定生命周期政策，主流支持持续至 2030 年，扩展支持至 2035 年。

五、总结与预告

本期作为系列第二期，聚焦了 SQL Server 2025 在企业级生产环境中的三大核心支柱：高可用性与灾难恢复——通过包含的可用性组（CAG）、次要副本备份、ZSTD 压缩等能力，在降低运维复杂度的同时显著缩短停机窗口；混合架构与云集成——Fabric 镜像以 Change Feed 为基石实现准实时数据同步，Azure Arc 提供跨越边界的统一管理平面；数据仓库与分析——PolyBase 简化至无需额外安装，S3 兼容对象存储统一备份与虚拟化场景。

在第三期（也是本系列的收官之作）中，我们将全面展示 SQL Server 2025 在开发者与数据库管理员（DBA）日常工作中的实战应用，涵盖以下主题：

  • 开发者实战：JSON 原生类型、正则表达式（Regex）函数、REST API 集成与 GraphQL 支持、Jaro-Winkler 模糊匹配等新特性的代码级应用
  • DBA 运维实战：AI 驱动的智能查询处理、优化锁定机制、tempdb 资源治理、变更事件流配置与监控
  • 性能调优案例：实际工作负载场景下的性能对比与最佳实践
  • 综合建议：何时升级、何时观望的决策框架，以及从 SQL Server 2022 迁移到 2025 的差异化价值评估

敬请期待！

参考资源

下期预告： SQL Server 2025 新技术系列（第三期，完结篇）——开发者与 DBA 实战指南，从代码到运维的全方位深度解读，敬请关注！

Article copyright statement
Star
Donate
SQL Server 2025 新技术系列介绍（第一期）
Previous
SQL Server 2025 新技术系列介绍（第三期）
Next

Leave a comment

Registration is not required

Recommendation

HiddenMerit Daily · Issue 19

HiddenMerit Daily · Issue 19

📊 HiddenMerit Daily · Issue 19 May 14, 2026 ｜ 5 Selected Global Breaking News 01｜Vastbase Plans Private Placement of Over RMB 700M, 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, intending to issue A-shares to no more than 35 specified investors, raising up to RMB 702 million. After deducting issuance expenses, the net proceeds will be fully invested in two core technology 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. The company stated that the traditional OLTP+OLAP separated architecture can no longer meet the rigid requirements of real‑time data processing, integration, and high concurrency in core scenarios such as finance, retail, telecommunications, and manufacturing. Its shortcomings – high O&M costs, data synchronization latency, and difficulty ensuring consistency – have become key bottlenecks in digital transformation. The HTAP architecture, with its two core 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 focuses on core needs in industrial IoT and energy dispatch, aiming to solve […]
DailyIssue DBA
Clyde Jin
05-14
185 0 0
HiddenMerit Daily · Issue 46

HiddenMerit Daily · Issue 46

📊 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 […]
DailyIssue DBA
Clyde Jin
06-18
115 0 0
DBA晨报·第34期｜金仓核心系统替代实战、数据库大会重磅发布、HOW 2026留存DBA新路径

DBA晨报·第34期｜金仓核心系统替代实战、数据库大会重磅发布、HOW 2026留存DBA新路径

DBA晨报·第34期｜金仓核心系统替代实战、数据库大会重磅发布、HOW 2026留存DBA新路径 为你摘取技术圈值得关注的3件事。今天是2026年4月29日，星期三。 01 国产化实战｜2026金仓分布式数据库替代纪实：高并发下零中断，QPS突破12万 近日，电科金仓官方披露了某头部省级金融清算中心核心交易系统从国外商业数据库平滑迁移至金仓分布式数据库的全过程。该案例被认为是2026年金融核心系统国产化替代的标杆实践。 项目背景：春节前的“紧急危机” 2026年春节前夕，随着“开门红”理财产品抢购活动上线，该中心的旧架构遭遇严峻考验： 瞬时并发突破历史峰值，CPU使用率曲线垂直拉升 原设计支撑5万笔/秒的架构在15分钟内彻底瘫痪 核心交易接口响应时间飙升至数秒甚至超时 更严峻的是：旧架构基于国外商业数据库，授权费用高昂且扩展性已触天花板 “不能再等了，”项目DBA老张回忆道，“必须启动核心系统的分布式数据库平滑替换方案。” 核心挑战：金融系统的“不可能三角” 对于金融核心系统而言，数据一致性、高可用性与高扩展性往往被视为难以兼得的“不可能三角”。 本次替换的核心难点在于“平滑”二字： 金融交易数据容不得闪失 T+0实时清算要求业务中断时间趋近于零 如何在不停业务、不丢数据的前提下完成迁移？ 团队选择金仓分布式数据库，因其原生分布式架构可在保证ACID特性的同时实现线性扩展，且多副本同步与自动故障切换机制为业务连续性提供了坚实保障。 迁移实战：双轨运行+灰度切换 第一步：架构重构与评估 迁移前，团队对现有业务逻辑进行了长达两周的“体检”： 使用金仓评估工具对SQL兼容性、存储过程复杂度、数据量全方位扫描 结果显示：约95%的SQL语句无需修改即可直接运行 核心交易表采用“分库分表+全局索引”架构策略 第二步：双轨运行与实时同步 团队制定了“双轨运行”策略： 旧系统继续承载业务 通过金仓实时数据同步组件，将旧库增量数据毫秒级同步至新集群 设立“双写校验”机制，实时比对两端数据一致性 第三步：流量灰度与平滑切换 2026年3月1日凌晨，切换正式拉开帷幕： 阶段 流量比例 验证要点 灰度起步 1% QPS平稳上升，响应时间<5ms 逐步放大 5% → 10% → 50% 交易成功率、数据一致性严密监控 全量切换 100% 旧系统作为热备运行48小时验证 最终，100%流量成功切换，零业务中断。 成效见证：性能飞跃与架构新生 指标 迁移后效果 峰值QPS 12万笔/秒（旧架构2.4倍） 故障切换 3秒内主备切换，业务无感知 数据增长10倍 查询响应时间依旧毫秒级 运维人力成本 降低40%以上 DBA视角 金仓2026年的这场“开年硬仗”释放了几个核心信号： 高并发可控：金融级交易场景（12万QPS、毫秒响应）已验证平滑替代能力 95%兼容：通过评估工具提前识别高风险点，迁移不再是“重新造轮子” 双轨机制：全量+增量的实时同步结合灰度切流，是大型系统“无感替换”的标准答案 对于正在规划核心系统国产化迁移的DBA，该案例提供了可复用的实战方法论：评估先行→双轨同步→灰度切换→热备验证。 02 产业回顾｜2026中国数据库技术与产业大会：达梦四款新品齐发，国产厂商份额首超国外 4月22日，以“达梦筑基 智启新元”为主题的2026中国数据库技术与产业大会在北京举行。本次大会由中国电子指导、中国软件行业协会主办、中国计算机学会数据库专委会协办、达梦数据承办。 核心数据：2025年市场规模达430.2亿元 赛迪顾问副总裁宋宇在大会上披露： 指标 数据 2025年中国数据库市场规模 430.2亿元 国产厂商市场占有率 已超越国外厂商 国产厂商排名 达梦数据保持第一 北京大学教授梅宏评价称，以达梦为代表的企业已支撑起金融、电力、交通等核心场景的规模化应用，证明中国基础软件产业在关键业务中具备了“稳得住、扛得住”的实力。 达梦四款战略新品发布 产品 定位 核心亮点 达梦数据库管理系统DM9 AI时代旗舰产品 集中式与分布式一体化，450余项新特性升级 DAMENG PAI V2.0 新一代数据库一体机 单次I/O时延从400微秒降至80微秒，20亿行大表扫描性能提升50倍以上 达梦启云数据库V4.0 云原生数据库 破解“运维低效、容灾复杂、算力割裂”三大困局 图数据库GDMBASE V4.0 图数据库 图原生+向量一体化架构 标杆案例展示 大会集中展示了国产数据库在关键领域的落地实效： 客户 应用效果 中国联通ERP系统 全栈创新升级，性能提升40%-50%，全国31省全覆盖 福州市第一总医院 8个院区核心系统改造，CPU占用率仅3%，零重大宕机 香港政务平台 “无体感”替换及AI数据精准管控 生态建设新篇章 大会期间，国产数据库产学研创新联合体正式启动，同时发布网信生态共同体暨达梦数据生态品牌“梦享会”。达梦数据董事长冯裕才表示，公司核心源代码实现100%全自主研发，未来将持续深耕AI与数据库深度融合、云原生、分布式、图计算等前沿技术，打造中国的世界级数据库品牌。 03 社区回响｜HOW 2026济南落幕：DBA职业不会被AI终结，但价值边界将被重新定义 4月27-28日，以PostgreSQL为核心的开源技术大会HOW 2026在济南举办。作为第34期的特别观察，我们将目光投向大会关于“DBA职业未来”的深度对话。 AI正在“碾平”专用向量数据库赛道 2023年被视为PostgreSQL AI化的分水岭。ChatGPT发布后RAG浪潮兴起，pgvector扩展恰逢其时。 独立开源贡献者冯若航在大会上指出：“PG用扩展方式，以30年成熟内核+增量功能，实现了对专用向量数据库赛道的弯道超车。” “数据库不是海马体，而是AI的整体状态平面”——PG有向量、全文检索、地理空间、图、时序等引擎，共同构成AI的完整数据底座。 DBA职业的未来：淘汰与新生并存 关于DBA是否会被AI取代，大会嘉宾给出了更务实的答案： 佰晟智算CEO白鳝：DBA脑子里还有知识的时候，是不会马上被蒸馏完的。我们必须往前走，保有被持续蒸馏的价值。简单一线工作AI能做得很好，但DBA的价值正在从“执行”转向“经验沉淀”。前几天我看到一个公司，他们的运维团队都在写Skills，甚至做了KPI要求，叫知识资产化——这是AI给DBA带来的正向改变。 前PG中文社区主席萧少聪：DBA分两种。第一种从数据库底层架构学习过来，听到AI会兴奋——脏活累活不用干了，去解决更有意义的问题。第二种只会敲命令、做备份恢复，遇到问题就束手无策，这样的DBA肯定没活路了。面对AI不要慌，回到最基础的《数据库系统概论》，学清楚数据库底层逻辑。AI是最好的老师——可以天天陪伴，用我们能理解的语言来教。 冯若航：AI冲击最大的是中间这一部分。最顶尖的专家依然很有价值——品位、判断力无法替代。100%会被替代的是运营性的操作知识。如果我要招人，只招两类：一类是能驱动AI Agent去干活的老司机；一类是聪明的实习生，还是一张白纸，有无限可能。 结构性优势：DBA的“反攻”机会 冯若航还提出了一个犀利观点：DBA相比前后端工程师有一个结构性优势——在整个IT技术栈里，数据库是非常硬核的部分。一个对数据库有深度了解的DBA，现在用AI Agent去做前后端开发是相对容易的。 “我们应该抓住这个优势，在这个机会窗口利用好它，打造全栈产品。” DBA视角 HOW 2026对DBA生存现状的讨论给出了更清晰的路线图： 危险区：只掌握常规运维技能、无法解决复杂问题的DBA。AI已经能以5分钱到1毛2的成本分析一份AWR报告，此类岗位的溢价空间正在归零。 安全区： 从“操作型DBA”转向“架构型DBA” 学习知识资产化：把经验沉淀为Skills/工具 成为AI+DBA复合型人才 结构性机遇：DBA对底层数据库的深度理解，使其具备了用AI Agent做全栈开发的独特优势。 正如一位专家的总结：“AI不会完全取代DBA，但会使用AI的DBA将取代不会使用AI的DBA。” 📌 本期结语：金仓金融核心系统替代实战，12万QPS零中断迁移，验证国产数据库高并发承载能力；2026数据库大会发布430.2亿市场规模数据，达梦四款新品齐发，国产份额首超国外；HOW 2026济南落幕，DBA不会消失，但需从“操作型”向“架构型+AI复合型”转型。祝各位DBA今日工作顺利！ DBA晨报·第34期｜2026年4月29日
DBA
Clyde Jin
04-29
117 0 0
第七期：查询优化器与执行计划 —— 如何读懂与干预

第七期：查询优化器与执行计划 —— 如何读懂与干预

第七期：查询优化器与执行计划 —— 如何读懂与干预 1. 查询优化器的工作流程 SQL Server 执行一条查询的完整路径： T-SQL 语句 &#x20; ↓ 【解析】语法检查 → 生成解析树 &#x20; ↓ 【绑定】代数化（Algebrizer）→ 绑定到对象（表、视图、列），生成逻辑树（查询树） &#x20; ↓ 【优化】Query Optimizer → 基于代价生成多个候选计划 → 选择代价最低的 &#x20; ↓ 【生成】执行计划 → 存入计划缓存 &#x20; ↓ 【执行】Query Executor + Storage Engine → 返回结果 优化器的核心任务：在有限时间内找到“足够好”的执行计划（不是绝对最优，否则优化本身成本太高）。 三个阶段： | 阶段 | 策略 | 时间 | 搜索范围 | |——|——|——|———-| | 阶段0 | 事务处理（Trivial Plan） | 极快 | 只生成最简单的计划（如行数=1时直接扫描） | | 阶段1 | 探索阶段（Exploration） | 快 | 搜索部分有希望的变换规则 | | 阶段2 | 完全优化（Full Optimization） | 慢 | 搜索全部变换规则（并行计划也在此生成） | 现象解释： 为什么简单查询几乎瞬间返回执行计划？因为命中了阶段0，直接生成Trivial Plan。 为什么复杂查询第一次编译时间长？因为优化器需要搜索多个候选计划（阶段2）。 2. 执行计划基础：读懂图形化计划 三种获取执行计划的方式： | 方式 | 命令 | 特点 | |——|——|——| | 估计执行计划 | SET SHOWPLAN_XML ON | 不执行查询，基于统计信息估算 | | 实际执行计划 | SET STATISTICS XML ON | 执行查询，包含实际行数、运行时信息 | | 实时执行计划 | sp_WhoIsActive 或 DMV | 查看正在执行的计划的实时进度（2016+） | 核心运算符（从数据流向角度理解）： | 运算符 | 作用 | 图标特征 | |——–|——|———-| | Clustered Index Seek | 在聚集索引中精确查找 | 黄色箭头+放大镜 | | Clustered Index Scan | 扫描整个聚集索引（表扫描） | 黄色箭头+表格 | | Index Seek | 在非聚集索引中精确查找 | 绿色箭头+放大镜 | | Index Scan | 扫描整个非聚集索引 | 绿色箭头+表格 | | Key Lookup（Bookmark Lookup） | 从非聚集索引回到聚集索引/堆取行 | 小书签图标 | | Nested Loops | 循环嵌套连接（适用于小表驱动大表） | 两个圆套在一起 | | Hash Match | 哈希连接（适用于大表无索引） | 两个圆相交 | | Merge Join | 合并连接（适用于两个有序输入） | 齿轮状 […]
DBA
Clyde Jin
04-25
186 0 0
HiddenMerit Daily · Issue 55

HiddenMerit Daily · Issue 55

📊 HiddenMerit Daily · Issue 55 Focus on Database Frontiers, Practical Insights for DBAs July 6, 2026 ｜ 5 Selected Global Breaking News 01｜Kingware Releases White Paper on Database Evolution in Manufacturing Scenarios: 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 […]
DailyIssue DBA
Clyde Jin
15 days ago
63 0 0
PostgreSQL 存储与索引系列（一）：数据在磁盘上如何安放——表、页、TOAST 与 VACUUM

PostgreSQL 存储与索引系列（一）：数据在磁盘上如何安放——表、页、TOAST 与 VACUUM

PostgreSQL 存储与索引系列（一）：数据在磁盘上如何安放——表、页、TOAST 与 VACUUM 这是系列文章的第一期，专注 PostgreSQL 的存储核心：表与行的组织、磁盘页结构、大字段的 TOAST 技术，以及不可或缺的 VACUUM 机制。后文还会介绍表分区，为下一期索引专题打下坚实基础。 1. 从逻辑表到物理文件 在 PostgreSQL 中，每个用户表都对应着磁盘上的一个或多个文件。默认情况下，一张表的数据存储在以表 OID 命名的文件中（位于 $PGDATA/base/<数据库 OID>）。当表或索引超过 1GB 时，PostgreSQL 会自动分割为 文件.1、文件.2 等，绕开某些文件系统的限制。 每个表中的数据是无序存储的“堆”（Heap）：新插入的行通常追加到文件末尾，更新行时可能放置在同一页（如果空间够），也可能移动到新页并留下“转发指针”。这种设计让写入很快，但带来了后续的清理负担——这就是 VACUUM 存在的理由。 2. 页结构：PostgreSQL 的磁盘基本单位 PostgreSQL 磁盘 I/O 的最小单元是页（Page），默认大小为 8 KB（编译时可选）。页既是读写单位，也是内存缓存的单位（shared_buffers 中缓存的就是页）。一张表的所有页组成一个大小可变的数组，每个页有自己的页号（block number）。 一个表页的内部布局如下（从头部到尾部分配）： +-----------------------------+ ← 页起点 | PageHeaderData (24 bytes) | 页元数据：页校验和、空闲空间起始、特殊区域起点等 +-----------------------------+ | ItemIdData (数组) | 4 字节/条，指向具体数据的偏移和长度 | (指向行指针，从页尾逆向增长) | +-----------------------------+ | 空闲空间（未使用区域） | +-----------------------------+ | 实际行数据（从页尾正向填充） | +-----------------------------+ | Special Space (可选) | 索引访问方法专用，如 GiST 需要保存信息 +-----------------------------+ 关键点： ItemId 数组从页头之后开始，采用“从两头向中间”方式：行指针从页头向后增长，实际元组从页尾向前增长。这样空闲空间始终是连续的一段。 每个元组头部包含 t_xmin、t_xmax、t_cid、t_ctid 等 MVCC 字段，用于判断可见性。 页内的元组如果被更新或删除，不会立刻物理移除，而是标记为“死元组”，等待 VACUUM 回收。 3. TOAST：大字段的出路 PostgreSQL 页面只有 8 KB，当一行数据超过约 2 KB（通常是页面大小的四分之一）时，TOAST（The Oversized-Attribute Storage Technique）就会介入。TOAST 将大字段值压缩并切分成小块，存储在单独的系统表 pg_toast 中。原表的行内只留下一个指针（约 18 字节）。 触发条件与策略 任何列类型都可能触发 TOAST，但主要面向变长类型（text、varchar、bytea、jsonb 等）。 四种存储策略（可通过 ALTER TABLE ALTER COLUMN SET STORAGE 调整）： PLAIN：禁用 TOAST，强制行内存储（要求列不超过页大小）。 EXTENDED：允许压缩和行外存储（默认策略）。 EXTERNAL：允许行外存储，但不压缩。适合部分无法接受压缩代价的场景（如某些加密数据）。 MAIN：优先压缩，尽量留在行内，最后才移至行外。 TOAST 表的内部结构 每个拥有大字段的表会关联一个 pg_toast.pg<em>toast</em><OID> 辅助表，该表包含三个列： chunk_id：标识属于哪个大字段值。 chunk_seq：切块序号。 chunk_data：实际的数据块（长度 ~2 KB）。 查询时如果只需 SELECT 非 TOAST 列，PostgreSQL 会避免读取 TOAST 表，提升性能。 4. VACUUM：对抗膨胀的清洁工 MVCC 架构下，更新/删除操作会留下旧版本（死元组），如果不清理，表会无限膨胀。VACUUM 负责： 回收死元组占用的空间，使其能被新元组复用。 更新可见性映射（Visibility Map），告诉 PostgreSQL 哪些页面全部可见，从而让仅索引扫描（Index-Only Scan）可以跳过堆表访问。 冻结事务 ID，防止事务 ID 回卷导致数据丢失。 两种 VACUUM 模式 标准 VACUUM：并发执行，仅清除死元组、整理空闲空间映射（FSM），不压缩表。空闲空间被记录到每个表的 _fsm 文件中供后续插入使用。 VACUUM FULL：排他锁重写整个表，彻底整理碎片并压缩到最小，代价高，适合膨胀严重且可以接受长时间锁表的场景。 关键优化：Visibility Map (VM) 与 Index-Only Scan 每个表还有一个 _vm 文件，每个页在 VM 中用 2 个比特表示： all_visible：该页所有元组对所有事务都可见。 all_frozen：该页所有元组的事务 ID 都已冻结（早期版本只有一个标志）。 当 VM 标记某页 all_visible 后，VACUUM 可以跳过该页；更重要的是，仅索引扫描可以结合 VM 省去回表——先通过索引拿到 ctid，再检查对应页是否在 VM 中标记，若是则直接使用索引数据，否则仍需回表判断可见性。 Autovacuum 调优要点（简要） 避免表膨胀：设置合适的 autovacuum_vacuum_scale_factor（大表用比例）和 autovacuum_vacuum_threshold（小表用绝对值）。 监控 pg_stat_all_tables 的 n_dead_tup […]
DBA
Clyde Jin
04-24
47 0 0
Clyde Jin
303 Articles
0 Comments
0 Like
Recent Posts
HiddenMerit Daily · Issue 60

HiddenMerit Daily · Issue 60

📊 HiddenMerit Daily · Issue 60 Focus on Database Frontiers, Practical Insights for DBAs July 22, 2026 ｜ 5 Selected Global Breaking News 01｜Oracle Releases Largest Quarterly Patch in History: 1,449 Patches Fix 1,235 CVEs, 261 Critical On July 21, Oracle released its July 2026 Critical Patch Update (CPU), setting a record for the largest single patch release in the company’s history. This CPU contains 1,449 security patches fixing 1,235 independent CVEs across 32 Oracle product families, of which 261 patches are rated Critical. Patch Distribution by Product Family: Product Family Patches Remotely Exploitable Without Authentication Oracle E‑Business Suite 410 45 Oracle Fusion Middleware 355 219 Oracle Communications 168 122 Oracle MySQL 54 9 Oracle Database Server 15 6 Context for This Patch: Oracle had already issued an urgent “Prepare Now” warning a week earlier, emphasising that AI is fundamentally lowering the barrier to discovering and exploiting vulnerabilities – frontier AI models can analyse software changes, reverse‑engineer security patches, and develop attack paths at unprecedented speed. Oracle has collaborated with state‑of‑the‑art models from Anthropic and OpenAI to proactively identify and fix potential security vulnerabilities. Oracle strongly recommends that customers immediately test and deploy this update in their monthly patch cycles. […]
life
Clyde Jin
5 mins ago
0 0 0
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
23 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
2 days 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
Tags
#Joke #Torn #life #Inspiration #Dairy #inspire #SQL #Server #网址搜集 #资源共享 #ChatGPT #Query Store #道德经 #读书 #apple music #dida #keep #GTD #题目 #纽曼 #腾讯课堂 #free #download #mp3 #Entertainment #SQL Server
生成中...
扫描二维码
扫描二维码