数智时代这个词喊了好几年今年明显感觉到不再只是口号。身边很多团队的数据架构在同时承受两种压力一边是业务数据分析脚本、AI推理任务越来越多直接跑到数据库旁边来另一边是传统交易系统在海量并发冲击下频繁暴露性能瓶颈。openGauss Summit 2025 在这个节骨眼上召开社区和商业用户关注的点其实高度一致——数据库能不能继续往上顶能不能真正把数智化这件事从 PPT 变成可交付的工程能力。作为长期跟进 openGauss 内核和周边工具的开发者我想在峰会之前把我看到的几条技术主线梳理清楚也把几个容易被忽略的实操问题一起讲透。这篇文章不打算做那种“大会预告式”的罗列而是想聊点更实际的东西数智时代到底对数据库提出了什么新要求openGauss 在内核、智能、生态、运维这几个方向上可能有哪些破局点以及我们作为使用者在存储过程、连接管理这些日常场景里应该提前做哪些功课。看完之后你至少能形成一张自己的验证清单而不是等发布会结束才去翻录播。1. 数智时代对数据库的真实要求openGauss 直面的是什么1.1 业务形态变了数据量、混合负载和 AI 一体先说一个直观变化。以前一个典型的业务系统是“OLTP 跑交易OLAP 跑报表数据仓库凌晨再跑批”各干各的互不干扰。现在不行了业务方要的是实时风控、实时推荐、实时库存分析同一个库上同时压着大量短事务和长查询。这种负载模型叫 HTAP 也好叫混合事务分析负载也好本质上是让数据库在并发处理和复杂分析之间做动态平衡。openGauss 这几年一直在推的“行存列存融合”“资源池化”其实都在回答同一个问题一套数据多种负载怎么做到不互相踩踏。另一个变化来自 AI 工作负载。以前数据库跟 AI 的关系是“AI 用数据数据库出数据”现在变成了“AI 推理要在数据库里跑向量检索要跟关系查询一起做”。你做一个智能客服系统用户的订单查询、商品检索、向量相似度匹配可能全在一个 SQL 事务里完成。这意味着数据库必须原生支持向量数据类型、索引结构和 AI 算子而不是靠外部应用拼拼凑凑。数智时代的“智”字对数据库而言不是附加题而是必答题。1.2 数据库角色的翻转从存储底座到智算中枢我有个比较鲜明的观点在数智时代数据库的定位正在从“被动存储”转向“主动计算”。过去我们常说数据库是底座业务逻辑写在应用层。但是当数据量达到 PB 级当实时性要求从秒级压到毫秒级把所有数据搬到应用层算是不现实的。谁能把计算下推到存储附近谁能让 SQL 直接驱动机器学习模型谁就能在性能上拉开代差。openGauss 提出的一些方向比如算子下推、UDF 算子的向量化执行、数据库内置机器学习框架都是在强化这个“主动计算”属性。说白了数智化不是让数据库变得更重而是让它把脏活累活干得更聪明优化器知道怎么选索引执行器知道怎么用 CPU 的向量指令存储引擎知道怎么让冷热数据自动分层。这套组合拳打下来用户感知到的就是“同样的 SQL反应快了一个量级”。2. Summit 2025 上我判断会出现的几条技术主线2.1 智能优化器AI4DB 从实验走向生产优化器一直是数据库的“灵魂”。传统优化器靠成本模型和统计信息猜执行计划猜得准不准很大程度上依赖 DBA 手动收集统计信息、调整参数。openGauss 社区过去几年在 AI4DB 上有不少积累我判断此次峰会会重点展示基于机器学习的选择率估计、基数估计和自调优能力。说白了就是让优化器不再依赖人工喂统计信息而是根据历史执行反馈自动校正模型。这条路如果走通收益是实打实的。举个例子复杂多表 Join 的查询基数估计偏差 10% 就可能导致执行计划从哈希连接退化成嵌套循环性能差距可能达到几十倍。传统数据库靠直方图、采样来缓解但样本总是滞后的。智能优化器的逻辑是用上一批查询的真实执行数据训练模型让下一次同类查询的预判更准。这属于用数据管数据很符合数智时代的调性。我比较期待 Summit 上能公布一些真实业务的性能对比数据而不只是 TPC-H 这种标准测试集。2.2 存算分离资源池化的下一站openGauss 在资源池化上已经布局了很久从最初的共享存储到后来的分布式中继再到对多节点写能力的支持。2025 年的破局点我判断有两个一个是对 S3 对象存储的原生支持另一个是基于 RDMA 网络的分布式内存池。这两个方向其实指向同一个目标——让计算节点可以随时弹性伸缩而不需要关心数据在哪个盘上。这个变化对运维的影响非常大。过去扩容一个数据库集群要担心数据重分布、主备切换、磁盘配额。如果存算分离做彻底了扩容就是加计算节点数据访问走统一的存储抽象层。应用层甚至不需要感知底层存储形态。这对数智时代典型的“数据量暴涨、计算需求波动大”场景特别契合。峰会如果放出资源池化和湖仓一体对接的实测数据建议重点看延迟和吞吐两项指标。2.3 多模数据与向量检索AI 应用的“最后一公里”数智时代绕不开的另一块是多模数据处理。业务数据既有结构化表格又有 JSON 文档、时序数据、地理位置信息还有 AI 应用必需的向量数据。如果一个数据库能在一套 SQL 体系里把这些类型全部托管应用开发会轻松很多。openGauss 在时序场景、空间场景已经有拓展向量检索则是最近几个版本明显发力的方向。我判断 Summit 2025 会在向量索引上拿出更完整的产品化方案比如 HNSW 索引的持久化、向量与标量的混合过滤、GPU 加速的向量距离计算。对企业用户来说关键是看它在千万级向量规模下的召回率和 QPS。另外一个关注点是向量类型是否能跟关系表做标准的 JOIN这决定了向量能力能不能真正嵌进业务逻辑而不是孤岛式的插件。3. 容易被忽略的引擎级能力存储过程与 PL/pgSQL 实践3.1 存储过程在 openGauss 里的真实定位很多开发者觉得存储过程是“老古董”但在金融、政务、制造业的信息系统里存储过程依然是核心业务的承载者。原因是合规要求高、逻辑敏感、不能频繁变动只能用数据库侧封装。openGauss 对存储过程的支持源于 PostgreSQL 兼容路线所以 PL/pgSQL 语法天然亲和。社区里搜索“openGauss 存储过程”的热度一直很高说明大量迁移用户正在把原有 Oracle 或 PostgreSQL 的存储过程搬过来。在峰会技术发布之外我建议开发者先把手头的存储过程能力摸清楚。openGauss 支持普通的函数、存储过程、触发器也支持游标、异常处理、自治事务等高级特性。不同版本对 PL/pgSQL 的方言兼容程度有差异迁移时最容易踩坑的不是语法本身而是隐式类型转换、集合类型、包Package的模拟方式。如果你是从 Oracle 迁移过来尤其要留意%TYPE、%ROWTYPE、顺序序列这些细节。3.2 一个可复现的存储过程示例订单折扣计算与其空谈特性不如直接看代码。下面是一个简单的示例演示 openGauss 里存储过程的基本结构、异常处理和游标用法。-- 创建测试表 CREATE TABLE order_detail ( order_id INT PRIMARY KEY, customer_id INT, total_amount NUMERIC(10,2), discount NUMERIC(10,2) DEFAULT 0 ); -- 存储过程根据订单金额计算折扣并更新 CREATE OR REPLACE PROCEDURE sp_calc_discount(p_min_amount NUMERIC) LANGUAGE plpgsql AS $$ DECLARE v_order_id INT; v_amount NUMERIC(10,2); v_discount NUMERIC(10,2); cur CURSOR FOR SELECT order_id, total_amount FROM order_detail WHERE total_amount p_min_amount FOR UPDATE; BEGIN OPEN cur; LOOP FETCH cur INTO v_order_id, v_amount; EXIT WHEN NOT FOUND; CASE WHEN v_amount 10000 THEN v_discount : 0.15; WHEN v_amount 5000 THEN v_discount : 0.10; ELSE v_discount : 0.05; END CASE; UPDATE order_detail SET discount v_discount WHERE CURRENT OF cur; END LOOP; CLOSE cur; COMMIT; EXCEPTION WHEN OTHERS THEN ROLLBACK; RAISE NOTICE Update failed: %, SQLERRM; END; $$; -- 调用 CALL sp_calc_discount(1000);这个存储过程做了三件事用游标遍历符合条件的订单按金额区间设置折扣率然后更新原表。注意我用了FOR UPDATE锁行和WHERE CURRENT OF定位更新这在批量加工场景能有效避免并发改同一行导致的更新丢失。异常块里加了事务回滚和错误信息输出生产环境建议把RAISE NOTICE换成表日志记录方便排查。openGauss 里存储过程的编译执行逻辑比较接近原生 PostgreSQL首次调用会进行语法分析和计划生成后续执行使用缓存计划。不过如果你用了动态 SQLEXECUTE IMMEDIATE拼接语句计划缓存就失效了。高并发场景下能写成静态 SQL 就不要用动态 SQL这个习惯比调任何参数都管用。3.3 从存储过程到函数什么时候用哪种存储过程PROCEDURE和函数FUNCTION在 openGauss 里的核心差异是函数必须返回一个值可以在 SELECT 里直接调用存储过程不要求返回值主要用 CALL 调用适合执行事务性操作。实际工程里我的经验是需要被报表查询调用的计算逻辑用函数需要独立执行批量维护任务用存储过程。还有一个细节事务控制语句COMMIT/ROLLBACK不能在函数里出现但可以在存储过程里出现。如果你做系统迁移建议先做一次方言兼容性扫描。社区有一个思路值得借鉴把原有数据库的存储过程拉出来在 openGauss 上跑一遍静态语法检查再看运行时行为。很多时候语法能过但数据类型长度、隐式转换、时间精度处理会导致数据写出差异。这种问题排查起来特别耗时间最好在迁移方案里留出专门兼容性测试的阶段。4. 连接管理、超时和运维的“小问题大麻烦”4.1 探索新闻中的连接报错问题深入解析“opengauss# \l warning: session unused timeout. fatal: terminating connection”很多人在连接 openGauss 时遇到过类似的提示opengauss# \l warning: session unused timeout. fatal: terminating connection。第一次看见这个报错心里容易咯噔一下——是不是数据库崩了其实不是。这是连接空闲超时机制在起作用。数据库为了不占用无效连接资源默认会回收空闲时间过长的会话。psql 客户端空闲太久没发语句服务端主动断开客户端再敲下一条命令时才发现“连接没了”。这个机制本身是好事但如果你用连接池或者长连接跑批处理就会被打个措手不及。我遇到过最典型的场景一个 Java 应用从连接池拿了一个连接因为业务空闲了 5 分钟再执行 SQL 时已经断掉了。应用层如果没有做连接有效性检查就会抛出偶发性的连接异常。这不是 openGauss 独有的问题任何数据库都有类似的空闲回收机制关键是你要知道三个参数怎么配。4.2 三个核心参数排查指南先看 openGauss 里影响会话超时的几个关键参数我在实际运维中经常检查参数名默认值范围作用session_timeout10min 左右空闲会话总超时时间超时后终止连接statement_timeout0无限制单条语句的执行超时防止慢查询占死资源idle_in_transaction_session_timeout依赖默认配置事务内空闲超时防止事务长时间挂起排查思路很简单先SHOW session_timeout;看服务端期望的空闲时长再看连接池维护的“连接最大空闲时间”是否小于它。如果连接池空闲时间比数据库小池子会自动先回收连接不会触发数据库端的断连如果相反池子里的连接会先被数据库干掉。所以业界普遍建议连接池配置的maxLifetime要小于数据库session_timeoutidleTimeout也同理。除了参数还要看一层\l这个命令本身是在客户端执行“查看数据库列表”。如果客户端和数据库之间有防火墙、LVS 或者云负载均衡这些中间组件也可能有自己的空闲超时。我排查过不少类似问题最后发现数据库没问题是中间 LB 把空闲连接静默丢掉了。遇到“连接老是掉”的情况别急着怀疑数据库链路每一跳都要测。4.3 连接池与高并发下的最佳实践高并发场景下连接管理可以直接决定系统稳定性。我给你几个已经验证过的配置思路。第一连接池大小不是越大越好。很多新手觉得并发高就多开连接结果把数据库线程池打满。openGauss 的默认max_connections够用但每个连接都有内存和上下文开销。我一般建议连接池上限控制在数据库连接数的 70% 左右给运维操作留出余量。第二启用keepalive。在数据库端开启 TCP keepalive 参数可以让内核及时发现僵死连接。配合连接池的testOnBorrow或testWhileIdle可以在拿到连接之前先做一次心跳查询避免把坏连接发给业务。第三监控空闲会话。在运维侧我会定期查询系统视图找出长时间state idle的会话SELECT pid, usename, application_name, client_addr, state, now() - state_change AS idle_for FROM pg_stat_activity WHERE state idle ORDER BY idle_for DESC;排查出来的长连接如果不是业务必须的要么让连接池主动回收要么调小session_timeout。线上环境里最怕的是连接泄漏应用获取连接后没有归还积少成多把连接池耗尽。通过上面这个查询很容易暴露问题配合日志能看到具体是哪个应用在持续积压。5. 回到 Summit 本身作为使用者该关注哪些发布物5.1 版本里程碑和内核特性峰会发布的技术创新最终会落到具体版本里。我的建议是不要只看宣传口号要看三样东西功能清单、兼容性列表和性能测试报告。如果某个新特性声称“支持资源池化”“支持向量检索”你要看它支持到什么程度——是实验特性还是生产可用是仅限特定硬件还是适配普通服务器有没有配套的运维工具和生产案例。openGauss 这几年一个比较清晰的产品逻辑是内核能力、周边工具、生态兼容同步推进。内核释放的每一代特性都会配套迁移工具、监控平台和开发者文档。所以逛 Summit 的时候重点听“迁移工具链”和“运维自动化”相关的分会场。对存量用户来说平滑升级的吸引力往往比单个性能点更大。5.2 迁移与兼容性从 MySQL/PG 生态平滑过来数智时代的现实是很多团队的存量业务跑在 MySQL 和 PostgreSQL 上。openGauss 的破局绕不开兼容性这个硬任务。我了解到社区在兼容性上一直在补课比如数据类型对齐、保留字差异、自增主键写法、SQL 方言差异。你在听技术分享时可以重点记一下官方是否推出了“语法差异自动改写”工具这个能极大降低迁移的人工成本。实践上我建议先做一个小范围迁移验证。选一个读多写少的业务模块把表结构、存储过程、定时任务整体搬过去跑一周对比查询结果。对比维度包括返回行数、字段精度、金额合计、日期处理、NULL 值处理。这五个点最容易出隐性差异短期的功能测试反而不容易暴露问题。我见过不少项目在迁移“看起来成功”之后真正跑月度报表时发现金额差了几分钱——最后定位到浮点数舍入规则不一致。这类坑提前对比就没事等到生产才发现就非常被动了。5.3 给开发者的三个验证动作如果你准备跟着 Summi发布的技术方向试水我建议先在本地做三个验证动作。第一个动作用一条典型的复杂 SQL 验证执行计划质量。把优化器和执行器的参数调成默认值看复杂查询是否自动选择了正确的 Join 算法。再对比新旧版本的执行计划差异这能直观感受优化器改进的效果。第二个动作写一个包含游标、异常处理、动态 SQL 的存储过程在目标版本上跑通。不要只测语法通过要测边界输入、异常输入、事务回滚。因为存储过程迁到新版本最容易出的问题就是错误处理路径不同导致事务没回滚数据一致性和原始库截然不同。第三个动作把连接池参数全部调成生产建议值然后模拟 10 分钟空闲、5 分钟空闲、1 分钟高并发交替压力。观察数据库日志里会不会出现session unused timeout或者terminating connection的告警。这一步能提前帮你把连接层的坑排掉而不是等上线后再被业务方找上门。数智化的潮流已经走到深水区数据库作为整个数据处理链路的地基每一次版本升级和架构演进都值得认真对待。我个人的体会是峰会上的技术亮点只是冰山一角真正的挑战永远在如何平稳落地。与其纠结“哪个特性最酷”不如关心“哪个改进能让我明天的系统更省心”。openGauss 2025 的技术方向已经显露出很强的实用主义气息——无论是智能优化、资源池化还是存储过程的工程化打磨都是在回答一个根本问题数智时代用户需要一台更聪明、更稳、更省心的数据库。这一点值得每一个关注数据库的开发者持续盯下去。