一根 URL 引发的线上事故

“连接字符串写好了吗？““写好了，跟 MySQL 差不多吧。"——这段对话出现在无数信创迁移项目的初期。等到上线第三天凌晨，值班工程师对着满屏的 Connection is not available 和 Socket closed 异常日志，才会意识到"差不多"三个字有多昂贵。

信创替代推进了几年，达梦 DM8 和华为 GaussDB 已经成为政企场景里部署量最大的两款国产关系型数据库。它们的 JDBC 驱动都遵循标准协议，看起来"能连上"并不困难。但连接建立只是起点——连接池如何管理这些连接的生命周期、超时边界如何与数据库服务端协调、故障转移时连接如何重建，这些问题的答案全部藏在 URL 参数和连接池配置的交叉地带。

本文不讲宏观架构选型，只聚焦一件事：把达梦和 GaussDB 的 JDBC URL 拆开，逐个参数讲清楚它到底在干什么、配错了会怎样、生产环境该怎么写。

两份真实的连接 URL

先亮出在生产环境中实际使用的连接字符串，后续所有分析都围绕这两份 URL 展开。

达梦 DM8

1

jdbc:dm://192.168.10.100:5236?schema=PROD_APP&loginEncrypt=false&socketTimeout=60000&loginTimeout=5000&compatibleMode=mysql&charSet=UTF-8&batchNotOnCall=true

GaussDB 主备版（基于 openGauss）

1

jdbc:opengauss://192.168.10.200:5432/prod_app?currentSchema=prod_app&sslmode=disable&socketTimeout=60&loginTimeout=5&tcpKeepAlive=true&ApplicationName=order-service&reWriteBatchedInserts=true

初看之下，二者都遵循 jdbc:协议://主机:端口/库名?参数=值 的基本格式，但差异已经浮现：达梦没有库名路径段（schema 通过参数指定）、GaussDB 沿用 PostgreSQL 风格的库名路径；达梦用驼峰命名参数，GaussDB 用全小写；超时单位一个是毫秒、一个是秒。这些表面差异背后，是两套完全不同的连接生命周期管理哲学。

连接池核心参数：从 URL 到池化的全链路

连接池参数分为两层：一层在 JDBC URL 或 DataSource 属性中设置，影响单个物理连接的行为；另一层在连接池框架（HikariCP、Druid）中设置，影响连接集合的管理策略。两层参数必须协调一致，否则就会出现"池子说连接还活着、数据库说连接已经断了"的经典矛盾。

池大小与并发模型

一个常见的错误是把 maximum-pool-size 设得很大（比如 200），理由是"并发高”。实际上连接池的大小与 CPU 核数的关系远比与请求并发数的关系紧密。某金融客户将池大小从 200 降到 50 后，TPS 反而提升了 15%——因为数据库端的锁竞争和上下文切换大幅减少。

经验公式：连接数 = ((CPU 核数 × 2) + 有效磁盘数)，这是某数据库领域资深架构师在多个项目中验证过的经验。对于 16 核数据库服务器，理论最优值在 34–48 之间。

连接池选型对 URL 参数的影响

使用 HikariCP 还是 Druid，会直接影响哪些参数需要在 URL 层面设置。HikariCP 倾向于"连接池层管一切”，而 Druid 提供了更多透传到 JDBC 驱动的通道。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# HikariCP：URL 参数是唯一的驱动层配置入口
spring:
  datasource:
    url: jdbc:dm://host:5236?socketTimeout=60000&loginTimeout=5000
    hikari:
      maximum-pool-size: 60
      connection-test-query: SELECT 1 FROM DUAL

# Druid：可以通过 data-source-properties 传递额外参数
spring:
  datasource:
    url: jdbc:opengauss://host:5432/db
    druid:
      max-active: 60
      validation-query: SELECT 1
      connect-properties:
        socketTimeout: 60000
        loginTimeout: 5000

超时参数：三层防线必须对齐

超时配置是连接池踩坑的重灾区。问题的根源在于：应用层、连接池层、数据库服务端层、网络层（防火墙/LB）各有自己的超时设置，且它们之间没有自动协调机制。

达梦的超时体系

达梦 DM8 的超时参数分散在 URL、驱动属性和数据库服务端三个位置：

• loginTimeout（URL 参数，毫秒）：TCP 连接建立 + 认证的总超时。生产建议 5000ms。
• socketTimeout（URL 参数，毫秒）：已建立连接上等待服务端响应的超时。生产建议 60000ms。
• SESS_IDLE_TIMEOUT（数据库服务端参数，秒）：空闲会话超时。很多部署环境默认 300 秒。

坑就出在第三个参数。某政务系统的 DBA 按照安全基线将 SESS_IDLE_TIMEOUT 设为 300 秒，而连接池的 idle-timeout 设为 600000ms（10 分钟）。结果每 5 分钟就有一批连接被数据库端静默断开，连接池浑然不知，直到下一个请求拿到"死连接"才报 Connection reset。

1
2
3
4

-- 达梦：查看当前空闲超时设置
SELECT PARA_NAME, PARA_VALUE 
FROM V$DM_INI 
WHERE PARA_NAME = 'SESS_IDLE_TIMEOUT';

对齐原则：连接池 idle-timeout < 数据库 SESS_IDLE_TIMEOUT < 防火墙 session-timeout。 三层超时形成递进关系，让连接池永远比数据库和防火墙先一步回收连接，从而避免被动断开的不可预期行为。

GaussDB 的超时体系

GaussDB 主备版的超时参数继承了 PostgreSQL 的体系，但有几个关键差异：

• socketTimeout（URL 参数，秒）：注意单位是秒而非毫秒，这与达梦不同。
• loginTimeout（URL 参数，秒）：同样是秒。
• idle_in_transaction_session_timeout（服务端参数，毫秒）：事务内空闲超时。
• statement_timeout（服务端参数，毫秒）：单条 SQL 的最大执行时间。

单位混用是最容易出错的地方。曾有团队在 GaussDB 的 URL 里写了 socketTimeout=60000，本意是 60 秒，实际上是 60000 秒（约 16 小时）——等于形同虚设。

1
2
3

达梦超时单位：毫秒（ms）
GaussDB URL超时单位：秒（s）
GaussDB 服务端超时单位：毫秒（ms）

超时参数对照表

字符集配置：看不见的性能杀手

字符集问题通常不会直接报错，而是以性能退化或数据损坏的形式悄悄发作。

达梦的字符集协商

达梦 DM8 在创建数据库时就确定了字符集（CHARSET 参数），支持 UTF-8（值为 1）和 GB18030（值为 2）。JDBC URL 中的 charSet 参数用于告知驱动客户端使用的字符集：

1

jdbc:dm://host:5236?charSet=UTF-8

如果客户端声明的字符集与数据库端不一致，驱动会进行透明转换。这个转换过程在大批量数据写入时开销显著——某报表系统从 GB18030 库读取数据写入 UTF-8 库，因字符集转换导致批量插入吞吐下降了 40%。

踩坑案例：某团队的达梦库创建时选了 GB18030（早期遗留），但 Java 应用层全程使用 UTF-8。URL 中没有指定 charSet 参数，驱动默认用数据库端字符集。结果中文字段在部分边界字符上出现了乱码——不是全部乱码，而是特定生僻字乱码。这种"部分损坏"比"全部乱码"更难排查，因为它不会触发明显的异常，只会在数据校验环节偶尔冒出来。

GaussDB 的字符集处理

GaussDB 主备版默认使用 UTF-8 编码（继承自 PostgreSQL），URL 中通常不需要显式指定字符集。但有一个隐蔽的问题：client_encoding。

1

jdbc:opengauss://host:5432/db?clientEncoding=UTF8

如果客户端通过连接池初始化后执行了 SET client_encoding = 'GBK' 之类的语句（某些 ORM 框架会在连接初始化时自动执行），后续所有数据的编码协商就会偏离预期。这类问题在信创迁移场景中尤其常见——从 Oracle 迁移过来的应用可能残留了设置 NLS_LANG 的初始化逻辑。

最佳实践：在连接池的 connection-init-sql 中显式锁定字符集，避免被框架或中间件的默认行为干扰。

故障转移与高可用：连接池必须参与

单机部署的连接池配置相对简单。但生产环境几乎一定是主备或集群架构，这时候连接池需要感知拓扑变化，在故障转移时快速重建连接。

达梦的集群连接方式

达梦支持两种集群模式：**数据守护（主备）**和 DSC 共享存储集群。前者的连接 URL 支持多地址配置：

1

jdbc:dm://host1:5236,host2:5236?schema=PROD_APP&doSwitch=1&loginEncrypt=false

关键参数 doSwitch 控制故障转移行为：

踩坑案例：某政务平台使用 doSwitch=2，在一次计划内维护后，主节点恢复上线，驱动自动回切。但回切过程中存在短暂的连接中断（约 2–3 秒），而连接池没有感知这个中断，继续复用旧连接，导致一波请求集中报错。最终解决方案是将 doSwitch 改为 1，由运维手动控制回切时机。

GaussDB 的主备切换

GaussDB 主备版的 JDBC 驱动本身不内建故障转移逻辑（与 PostgreSQL 驱动行为一致）。主备切换后，已有连接不会自动重定向到新主节点。这意味着连接池必须承担起故障感知的责任。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# GaussDB 主备场景下的 Druid 配置要点
spring:
  datasource:
    url: jdbc:opengauss://primary:5432,standby:5432/prod_app?targetServerType=primary
    druid:
      # 快速探测失效连接
      test-while-idle: true
      time-between-eviction-runs-millis: 10000   # 10秒探测一次
      # 连接失败不中断获取流程
      break-after-acquire-failure: false
      connection-error-retry-attempts: 3
      # 主备切换后强制重建连接
      phy-timeout-millis: 300000                  # 5分钟强制刷新物理连接

targetServerType=primary 这个参数至关重要。它让驱动在建立新连接时自动检测目标节点的角色，避免将写操作发往只读的备节点。但要注意：它只在建立新连接时检查，不会在连接已经建立后动态感知角色变化。 这就是为什么连接池的探测间隔必须足够短。

故障转移恢复能力对比

从故障转移的自动化程度看，达梦驱动层面的 doSwitch 机制比 GaussDB 更成熟。但这也意味着达梦的连接行为更"不透明”——连接池框架对底层连接的切换过程缺乏可见性，排查问题时需要同时看驱动日志和连接池日志。

性能调优实战：从 URL 参数挤出吞吐

达梦的批处理优化

达梦 URL 中的 batchNotOnCall 参数是一个容易被忽略的性能开关：

1

batchNotOnCall=true

默认情况下，达梦驱动在执行 executeBatch() 时会逐条调用存储过程来执行批量操作。开启此参数后，驱动会绕过存储过程调用路径，直接走协议层的批量写入通道。某订单系统在批量插入场景中，开启后 TPS 从 2800 提升到 5200。

GaussDB 的批量重写

GaussDB URL 中的 reWriteBatchedInserts=true 同样是一个高性能参数。它让驱动将多条 INSERT INTO t VALUES (?) 重写为单条 INSERT INTO t VALUES (...),(...),(...) 的多值插入语法。在 PostgreSQL 体系下，这种重写可以将批量插入效率提升 3–5 倍。

1

reWriteBatchedInserts=true

但要注意一个前提条件：使用 reWriteBatchedInserts 时，SQL 语句必须以分号结尾且不能包含 RETURNING 子句，否则重写会静默失败（不报错，但退化为逐条执行）。

TCP 保活：防止静默断连

在内网环境中，交换机和防火墙通常会清理长时间无数据传输的 TCP 连接（典型超时 5–30 分钟）。如果数据库连接在保活窗口内没有 SQL 交互，TCP 层面的连接就会被中间设备丢弃，而应用层完全无感知。

GaussDB 的 URL 支持 tcpKeepAlive=true，这会启用操作系统层面的 TCP Keep-Alive 探测（默认 2 小时间隔，可通过内核参数调整）。达梦没有直接的 URL 参数，需要在操作系统层面配置或通过 Druid 的 keep-alive 机制在应用层模拟。

1
2
3
4
5
6
7

# 达梦环境：通过 Druid 应用层保活替代 TCP Keep-Alive
spring:
  datasource:
    druid:
      keep-alive: true
      keep-alive-between-time-millis: 30000   # 30秒发一次心跳
      validation-query: SELECT 1 FROM DUAL

连接建立耗时：URL 参数数量的隐性代价

一个值得注意的现象：URL 中的参数越多，连接建立耗时越长。 这不是因为参数解析本身慢，而是因为每个参数都可能触发额外的协商步骤。

在某次性能分析中，对比了精简 URL 和全参数 URL 的连接建立耗时：

GaussDB 的 SSL 握手开销尤为明显。在纯内网环境中，很多团队会选择 sslmode=disable 来消除这部分开销。但需要评估安全风险——如果数据库流量经过不可信网段（哪怕是内网中的共享交换机），禁用 SSL 等于明文传输所有数据。

一个折中方案是使用 sslmode=require 配合 sslfactory=org.opengauss.ssl.NonValidatingFactory，既加密传输又跳过证书验证，将握手耗时控制在 28ms 左右。

汇总：生产环境推荐 URL 模板

经过上述逐项分析，以下是两款数据库在生产环境中经过验证的 URL 模板：

达梦 DM8 生产 URL

1
2
3
4
5
6
7
8

jdbc:dm://primary:5236,standby:5236
  ?schema=PROD_APP
  &loginEncrypt=false
  &socketTimeout=60000
  &loginTimeout=5000
  &charSet=UTF-8
  &batchNotOnCall=true
  &doSwitch=1

配合 Druid 连接池：keep-alive=true、keep-alive-between-time-millis=30000、test-while-idle=true、pool-prepared-statements=false（关闭 PSCache，达梦驱动对此兼容不佳）。

GaussDB 主备版生产 URL

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

jdbc:opengauss://primary:5432,standby:5432/prod_app
  ?currentSchema=prod_app
  &sslmode=require
  &sslfactory=org.opengauss.ssl.NonValidatingFactory
  &socketTimeout=60
  &loginTimeout=5
  &tcpKeepAlive=true
  &ApplicationName=your-service-name
  &reWriteBatchedInserts=true
  &targetServerType=primary

配合 Druid 连接池：test-while-idle=true、time-between-eviction-runs-millis=10000（主备场景缩短探测间隔）、phy-timeout-millis=300000。

踩坑总结速查

连接池配置从来不是一次性工作。每次数据库版本升级、网络拓扑变更、中间件替换，都可能需要重新审视这些参数。建立一份活的配置基线文档，记录每个参数的选择理由和验证数据，比记住某个"最佳值"更重要。在信创替代的长周期里，这种可追溯的配置管理习惯，才是避免重复踩坑的根本保障。