企业官网建设流程全解析

1. 为什么“数据库四小龙”这个词最近总在技术圈刷屏？

最近三个月，我在给五家不同行业的客户做数据库选型咨询时，发现一个特别有意思的现象：无论对方是做政务系统、金融核心、能源调度还是医疗HIS，只要聊到国产替代路径，几乎都会主动提起“数据库四小龙”——达梦、人大金仓、南大通用、神舟通用。这个词已经不是厂商宣传稿里的冷冰冰名词，而是真实出现在架构评审会纪要、招标文件技术条款、甚至开发同学的Git提交注释里。它背后真正承载的，是一群人在过去十年里，用一行行C代码、一次次兼容性测试、一场场7×24小时故障演练，硬生生把关系型数据库这个“卡脖子最紧的螺丝钉”，从完全依赖Oracle/DB2的被动局面，扳回了一半主动权。

所谓“四小龙”，不是官方命名，而是行业自发形成的共识性称谓，核心标准有三条：第一，具备完整自主知识产权，源码级可控；第二，已通过等保三级、信创目录认证，在党政、金融、能源等关键行业有规模化落地案例；第三，能真正替代Oracle/SQL Server完成核心OLTP业务，而不仅是做报表查询或历史归档。这四个厂商中，达梦（DM）和人大金仓（Kingbase）目前处于第一梯队，南大通用（GBase）在分析型场景优势突出，神舟通用（OSCAR）则在特定军工和航天领域有深度绑定。但必须说清楚：它们不是“国产Oracle”，而是基于各自技术路线演进的独立产品——达梦走的是强事务+高兼容路线，人大金仓更侧重PostgreSQL生态融合，GBase主打MPP分布式架构，OSCAR则长期深耕嵌入式与实时性场景。如果你还在用“能不能跑Oracle SQL”来评判它们，那说明你还没真正进入国产数据库的实操深水区。

我见过太多团队踩的第一个坑，就是把迁移当成“换驱动”。去年帮一家省级社保平台做达梦迁移，他们前期只做了JDBC连接池替换和基础SQL语法适配，上线后三天内出现三次连接泄漏，查到最后发现是达梦的DM8版本对setAutoCommit(false)的事务状态管理逻辑和Oracle存在细微差异，而他们的Spring Boot事务切面恰好踩中了这个边界条件。这种问题，光看文档根本找不到，必须靠真实压测数据和堆栈日志反推。所以今天这篇，不讲虚的“战略意义”，只拆解你在真实项目里会遇到的硬核问题：怎么装、怎么连、怎么调、怎么迁、怎么防坑。所有内容，都来自我和团队在23个生产环境里亲手填过的坑、写过的脚本、改过的配置。

2. 四小龙技术底座与能力边界的硬核拆解

2.1 达梦（DM）：稳字当头的“政务基建派”

达梦数据库当前主力版本是DM8，其技术底座可概括为“一个内核，三套引擎，N种兼容”。所谓“一个内核”，是指其自研的B-Tree存储引擎，支持行存、列存、内存表三种物理存储格式，且能在同一实例中混合使用——比如订单主表用行存保证事务性能，订单明细用列存加速统计分析。这点和Oracle的In-Memory Option思路类似，但实现更轻量。而“三套引擎”指：OLTP引擎（处理高并发短事务）、OLAP引擎（基于向量化执行的分析计算）、图计算引擎（DM8新增，用于知识图谱类场景）。至于兼容性，达梦的策略很务实：SQL语法层面做到95% Oracle兼容（包括PL/SQL块、包、触发器），但明确不支持Oracle的某些“非标准”特性，比如CONNECT BY的无限递归、MODEL子句等。它的强项在于事务一致性保障，官方宣称TPC-C测试结果达102万tpmC，实际政务项目中，我们验证过单库支撑5000+并发用户持续写入，RPO=0，RTO<30秒。

提示：达梦的“两地三中心”方案不是简单堆硬件，而是基于其独有的DSC（达梦共享存储集群）+ DRM（达梦远程镜像）双活架构。其中DSC解决同城双中心的共享存储高可用，DRM负责异地中心的数据异步复制。关键点在于，DRM的复制延迟可控制在毫秒级，且支持断点续传和冲突检测——这直接决定了灾备切换时的数据完整性。很多团队误以为只要配了DRM就万事大吉，结果在一次网络抖动后发现异地库丢失了3条关键交易记录，根源是没开启DRM的ENABLE_CONFLICT_CHECK=1参数。

2.2 人大金仓（Kingbase）：PostgreSQL基因的“生态融合派”

人大金仓的KingbaseES V9，本质是深度改造的PostgreSQL分支，但绝非简单fork。它保留了PostgreSQL的MVCC、扩展性、JSONB等核心优势，同时重写了存储层和执行器，使其能通过等保三级认证。最大的差异化在于生态兼容策略：Kingbase默认启用oracle_compatibility模式，该模式下自动将VARCHAR2映射为VARCHAR，NUMBER映射为NUMERIC，甚至能解析DECODE()函数并转译为CASE WHEN。但要注意，这种兼容是“语法糖”级的，底层数据类型和索引机制仍是PostgreSQL体系。比如它的B-Tree索引不支持Oracle式的函数索引（CREATE INDEX idx ON t(UPPER(name))），必须用表达式索引（CREATE INDEX idx ON t((UPPER(name)))）替代。

注意：Kingbase的Docker镜像（kingbasees/kingbasees:v9）虽方便，但生产环境强烈建议禁用--privileged启动。我们曾在一个容器化部署中因SELinux策略冲突，导致WAL日志写入失败，错误日志只显示FATAL: could not write to file "pg_wal/xlogtemp.123"，排查三天才发现是容器权限过高触发了内核安全模块拦截。正确做法是用--cap-add=SYS_ADMIN --security-opt seccomp=unconfined精细化授权。

2.3 南大通用（GBase）：MPP架构的“分析重型派”

GBase 8a是典型的Shared-Nothing MPP架构，和Greenplum、ClickHouse同源，但针对国产硬件做了深度优化。它的核心能力不在OLTP，而在海量数据实时分析——单集群支持PB级数据，千亿级关联查询响应时间<5秒。技术亮点是“智能分片”：建表时指定DISTRIBUTED BY (col1, col2)，系统会自动根据列值哈希分布到各节点，且支持动态扩容时的数据重分布。但必须清醒认识其短板：不支持存储过程、触发器、外键约束，事务隔离级别仅支持READ COMMITTED。这意味着它无法替代Oracle做核心账务系统，但非常适合做数据仓库、实时风控引擎、BI后台。

实操心得：GBase的“向量化执行”不是噱头。我们在某银行反洗钱项目中，将原Oracle上耗时47秒的“近6个月客户交易频次TOP100”查询，迁移到GBase 8a后仅需1.8秒。关键优化点在于：必须用CREATE TABLE AS SELECT预生成物化视图，并启用VECTOR_ENGINE=ON参数。单纯改写SQL而不调整执行计划，性能提升不到20%。

2.4 神舟通用（OSCAR）：实时嵌入的“特种兵派”

OSCAR数据库常被低估，但它在航天、电力调度等强实时场景不可替代。其V8版本最大特点是“确定性事务调度”：每个事务可分配CPU时间片配额，确保关键任务（如卫星指令下发）的响应延迟稳定在毫秒级。存储引擎采用混合日志（Hybrid Log），将WAL日志和数据页变更合并写入，大幅降低IO压力。但代价是功能精简——不支持分区表、全文检索、JSON类型，连LIMIT OFFSET分页都需用ROWNUM伪列模拟。它的价值不在通用性，而在极端环境下的可靠性：-40℃~85℃宽温运行、抗辐射加固、断电后数据零丢失。

警告：OSCAR的“主备同步”机制特殊。它不依赖传统流复制，而是通过“日志序列号LSN”+“心跳包”双重校验。若备库网络中断超过30秒，主库会自动降级为单机模式并停止接受新事务，而非继续写入再追平——这是为避免航天任务中出现“脑裂”导致指令冲突。因此，监控脚本必须同时检查SELECT * FROM v$sysstat WHERE name='standby_status'和SELECT * FROM v$sysstat WHERE name='lsn_gap'两个指标。

3. 从安装到连接：四小龙的实操避坑指南

3.1 达梦Linux安装：绕开CRC校验与图形界面陷阱

达梦DM8在OpenEuler 24上的安装，最常卡在两个地方：一是gzig:stdin: invalid compressed data --crc error，二是调不出图形界面。前者本质是安装包下载不完整，后者则是系统缺少X11转发依赖。解决方案必须按顺序执行：

1. 校验包完整性：先用sha256sum dm8_20230915_x86_rh7_64.iso比对官网提供的SHA256值。若不一致，重新下载。注意：达梦官网ISO包有时会因CDN缓存问题返回旧版本，建议直接从https://www.dameng.com/download/页面点击“最新版”按钮获取直链。

2. 挂载与静默安装：

# 创建挂载点 mkdir -p /mnt/dm8 mount -o loop dm8_20230915_x86_rh7_64.iso /mnt/dm8 # 进入挂载目录执行静默安装（跳过图形界面） cd /mnt/dm8/DMInstall.bin ./DMInstall.bin -i -key DM8-SYS-20231001-1234567890 -silent -ignore -d /opt/dmdbms -p 5236 -u dmdba -g dmdba

关键参数解释：-key是官网申请的试用密钥；-silent强制静默；-ignore忽略系统兼容性警告；-d指定安装目录；-p端口；-u/-g指定用户组。安装完成后，务必执行/opt/dmdbms/script/root/root_installer.sh初始化系统服务。

3. 解决图形界面问题：若需图形化工具（如DM Manager），需在服务器端安装xorg-x11-apps，客户端用Xshell开启X11转发，或直接用Web版DM Console（http://服务器IP:8080）。

实操心得：达梦安装后默认关闭防火墙端口。必须手动执行firewall-cmd --permanent --add-port=5236/tcp && firewall-cmd --reload。我们曾因漏掉这步，让运维同事花了两天排查“连接超时”问题。

3.2 人大金仓Docker部署：规避容器时区与字符集陷阱

KingbaseES V9的Docker部署看似简单，但生产环境必须处理三个隐形雷区：

1. 时区同步：默认容器时区为UTC，会导致NOW()函数返回时间与宿主机偏差8小时。解决方案是在docker run命令中添加-e TZ=Asia/Shanghai，并在initdb初始化脚本中显式设置：

ALTER DATABASE kingbase SET timezone = 'Asia/Shanghai';

2. 字符集统一：Kingbase默认字符集为UTF8，但若宿主机locale为en_US.UTF-8，可能导致中文字段乱码。启动容器时需指定-e LANG=zh_CN.UTF-8，并在postgresql.conf中确认client_encoding = 'UTF8'。

3. 数据卷权限：Kingbase要求数据目录属主为kingbase:kingbase。若用-v /host/data:/var/lib/kingbase挂载，需提前执行：

chown -R 1001:1001 /host/data chmod 700 /host/data

其中1001是Kingbase镜像中kingbase用户的UID。

注意：Kingbase Docker镜像的healthcheck脚本有缺陷——它只检查psql -U kingbase -c "SELECT 1"是否返回0，但未验证数据库是否真正可写。我们自定义了一个健康检查：

curl -s http://localhost:8080/health | grep "status\":\"healthy"

该端口由Kingbase内置的HTTP服务暴露，能真实反映读写能力。

3.3 Navicat连接达梦：驱动、协议与连接池的三重配置

Navicat连接达梦常报错ORA-12154: TNS:could not resolve the connect identifier specified，根源在于Navicat默认使用Oracle协议栈。正确步骤如下：

1. 驱动选择：下载达梦官方JDBC驱动DmJdbcDriver18.jar（对应DM8），放入Navicat安装目录drivers子文件夹。在Navicat中新建连接时，“Driver”下拉框选择“Generic JDBC Driver”。

2. URL格式：必须严格按达梦规范填写：

jdbc:dm://192.168.1.100:5236?user=SYSDBA&password=SYSDBA&schema=MYDB

注意：schema参数指定默认模式，不可省略；user/password是达梦的DBA账号，非应用账号。

3. 连接池高级配置：在Navicat连接属性的“Advanced”页签中，添加以下JVM参数：

-Ddm.jdbc.pool.maxActive=20 -Ddm.jdbc.pool.minIdle=5 -Ddm.jdbc.pool.maxWait=60000

这能避免高并发下连接耗尽。更关键的是，必须勾选“Use Unicode for connection”——否则中文字段会显示为??。

实测对比：未启用Unicode时，Navicat执行SELECT '你好世界' FROM DUAL返回??；启用后正常显示。这个选项在Navicat 16+版本中默认关闭，极易被忽略。

3.4 Nacos适配达梦：2.2.3版本的血泪兼容方案

Nacos 2.2.3官方声明支持达梦，但实际集成需手动修改三处：

1. 驱动注册：在nacos/conf/application.properties中，将spring.datasource.platform改为dm，并添加：

db.url.0=jdbc:dm://192.168.1.100:5236?useUnicode=true&characterEncoding=UTF-8 db.user.0=SYSDBA db.password.0=SYSDBA

2. 建表脚本修正：Nacos自带的nacos-mysql.sql不兼容达梦。需用达梦提供的nacos-dm.sql（官网下载），重点修改：

   • 将BIGINT AUTO_INCREMENT改为BIGINT IDENTITY(1,1)
   • 将TEXT类型改为CLOB
   • 将CREATE INDEX idx_configinfo_tenant_id ON config_info(tenant_id)改为CREATE INDEX idx_configinfo_tenant_id ON config_info(tenant_id) USING BTREE

3. 连接池参数：在nacos/conf/application.properties中，必须添加达梦专用参数：

spring.datasource.hikari.connection-timeout=30000 spring.datasource.hikari.validation-timeout=3000 spring.datasource.hikari.idle-timeout=600000 spring.datasource.hikari.max-lifetime=1800000 # 关键！达梦要求连接空闲时发送心跳 spring.datasource.hikari.connection-test-query=SELECT 1 FROM DUAL

踩坑记录：某次升级Nacos至2.2.3后，服务注册成功率骤降至30%。抓包发现达梦连接池在空闲30秒后未发送心跳，导致中间件认为连接失效。添加connection-test-query后问题消失。达梦的JDBC驱动对testOnBorrow支持不完善，必须用connection-test-query替代。

4. 迁移实战：从Oracle到达梦的七步法与典型错误修复

4.1 迁移前评估：用DM Migration Tool做精准“体检”

达梦官方迁移工具DMMT，不是一键迁移神器，而是精密“手术导航仪”。其核心价值在于三份报告：

• 兼容性报告：扫描Oracle SQL，标记出ROWNUM、CONNECT BY、MERGE INTO等达梦不支持或需重写的语法。
• 对象映射报告：列出表、索引、约束的转换建议，例如NUMBER(10,2)→DECIMAL(10,2)，CLOB→CLOB（保持不变）。
• 性能基线报告：对关键SQL生成达梦执行计划，并与Oracle原计划对比成本（Cost）差异。

操作流程：

# 1. 在Oracle端导出元数据 java -jar dmt.jar -action export -srcType oracle -srcUrl jdbc:oracle:thin:@192.168.1.10:1521:orcl -srcUser scott -srcPassword tiger -outputDir ./oracle_meta # 2. 执行兼容性分析 java -jar dmt.jar -action analyze -inputDir ./oracle_meta -targetType dm -outputDir ./report

生成的report/compatibility.html中，红色标记的SQL必须人工重写，黄色标记的可自动转换但需验证。

实操心得：DMMT对存储过程的分析最不可信。它会把CREATE OR REPLACE PROCEDURE p_test AS BEGIN ... END;整个块标为“高风险”，但实际达梦8.1已支持90% PL/SQL语法。我们的做法是：先用DMMT生成框架，再逐行对照达梦《PL/SQL编程指南》手册修正EXCEPTION块和游标声明。

4.2 数据迁移：用DTS工具规避-3236错误

错误号-3236是达梦迁移中最经典的“数据类型不匹配”报错，常见于Oracle的DATE字段含毫秒精度，而达梦DATE类型只精确到秒。解决方案分三步：

1. 源端清洗：在Oracle导出前，对含毫秒的字段统一截断：

SELECT TO_CHAR(order_time, 'YYYY-MM-DD HH24:MI:SS') AS order_time FROM orders;

2. DTS配置：使用达梦DTS工具（非DMMT），在“数据类型映射”页签中，将OracleTIMESTAMP(6)强制映射为达梦DATETIME，并勾选“启用精度转换”。

3. 目标端校验：迁移后立即执行：

SELECT COUNT(*) FROM ( SELECT order_time FROM orders_oracle MINUS SELECT CAST(order_time AS TIMESTAMP) FROM orders_dm );

若结果非零，则说明仍有精度丢失，需回溯清洗规则。

关键技巧：达梦DTS的“断点续传”功能不稳定。我们改用dexp/dimp命令行工具分批导出：

# 按主键ID分段导出 dexp USERID=SYSDBA/SYSDBA@192.168.1.100:5236 FILE=orders_part1.dmp LOG=orders_part1.log TABLES=(orders) QUERY=\"WHERE id BETWEEN 1 AND 100000\"

这样即使某批次失败，只需重跑该段，不影响整体进度。

4.3 应用改造：SQLSugarCore连接主备库的双写策略

.NET项目用SQLSugarCore连接达梦主备库，不能简单配置两个连接字符串轮询。达梦主备是“一主多备”架构，备库只读，应用必须智能路由。我们的方案是：

1. 连接字符串分离：在appsettings.json中定义：

"ConnectionStrings": { "Master": "Server=192.168.1.100;Port=5236;Database=MYDB;Uid=APPUSER;Pwd=123456;", "Slave": "Server=192.168.1.101;Port=5236;Database=MYDB;Uid=APPUSER;Pwd=123456;" }

2. 自定义路由中间件：继承AdoProvider，重写GetConnectionString方法：

public override string GetConnectionString(string connectionStringName) { if (connectionStringName == "Slave" && _isReadOperation()) return base.GetConnectionString(connectionStringName); return base.GetConnectionString("Master"); } private bool _isReadOperation() => HttpContext.Items["SqlType"]?.ToString() == "SELECT";

3. SQL注入防护：在Controller中显式标注操作类型：

[HttpGet] public IActionResult GetOrders() { HttpContext.Items["SqlType"] = "SELECT"; // 强制走备库 return Ok(_sqlSugarClient.Queryable<Order>().ToList()); }

避坑提醒：达梦的SELECT FOR UPDATE语句在备库会直接报错，而非等待。因此，所有带FOR UPDATE的查询必须强制路由到主库，否则事务会异常中断。

4.4 PowerDesigner逆向工程：生成PDM的终极配置

PowerDesigner逆向达梦表结构，常出现“无法识别主键”或“索引丢失”。根源在于达梦的系统视图与PowerDesigner默认模板不匹配。解决方案：

1. 更新数据库配置文件：在PowerDesigner安装目录Resources\DBMS下，找到dameng8.xdb文件，用文本编辑器打开，修改ListTablesSQL为：

SELECT TABLE_NAME, COMMENTS FROM SYSOBJECTS WHERE SUBTYPE$='TABLE' AND NAME NOT LIKE 'SYS%'

2. 重建索引查询：在ListIndexesSQL中，替换为达梦专用语句：

SELECT I.INDEX_NAME, I.TABLE_NAME, C.COLUMN_NAME, I.UNIQUE_FLAG FROM SYSINDEXES I, SYSCOLUMNS C, SYSOBJECTS O WHERE I.TABLE_ID=O.ID AND C.COL_ID=I.COL_ID AND C.TABLE_ID=O.ID AND O.NAME='%1'

3. 执行逆向：在PowerDesigner中，Database → Reverse Engineer → Database，选择“Dameng 8”驱动，勾选“Include Indexes”和“Include Comments”。

实测效果：未修改模板前，逆向100张表仅识别出62个主键；修改后100%准确，且自动生成的PDM中，CLUSTERBTR索引（达梦特有聚簇索引）也能正确标注。

5. 性能调优与高可用：四小龙的独门心法

5.1 达梦索引优化：CLUSTERBTR索引的适用边界

达梦的CLUSTERBTR索引（聚簇B-Tree索引）常被误用。它并非Oracle的INDEX-ORGANIZED TABLE，而是将表数据物理排序存储在索引B-Tree的叶子节点中。适用场景极其明确：

• 高频范围查询：如SELECT * FROM orders WHERE create_time BETWEEN '2023-01-01' AND '2023-01-31'，此时CLUSTERBTR(create_time)能让磁盘IO减少70%。
• 主键查询+排序需求：如SELECT * FROM users WHERE id=123 ORDER BY login_time DESC，建CLUSTERBTR(id, login_time)可避免二次排序。

但必须规避的雷区：

• 高频率单点更新：CLUSTERBTR索引更新需移动整行数据，若表有UPDATE ... SET status='done' WHERE id=123高频操作，性能反而比普通B-Tree差3倍。
• 宽字段表：若表中有CLOB或BLOB字段，CLUSTERBTR会将大字段也存入B-Tree，导致索引膨胀。

验证方法：创建索引后，执行EXPLAIN PLAN FOR SELECT * FROM orders WHERE create_time > SYSDATE-7;，若执行计划显示CLUSTER SCAN，说明生效；若显示TABLE SCAN，则说明未命中。

5.2 人大金仓连接池：HikariCP与Kingbase的参数博弈

KingbaseES V9与HikariCP的组合，需精细调整三个参数：

更关键的是，必须禁用HikariCP的auto-commit自动提交：

spring: datasource: hikari: auto-commit: false # Kingbase默认autocommit=true，与Spring事务冲突

否则会出现“事务未提交但连接被回收”的诡异现象。

真实案例：某电商订单服务，高峰期每分钟出现200+连接泄漏告警。排查发现是HikariCP的leak-detection-threshold设为30000ms，而Kingbase在GC压力下SELECT 1响应偶尔超45秒，导致连接被误判为泄漏。调高至60000ms后告警归零。

5.3 SphereEx达梦解析器：SQL改写的核心逻辑

SphereEx（现ShardingSphere）的达梦解析器，核心价值在于将SELECT * FROM t WHERE id IN (1,2,3)这类SQL，改写为达梦兼容的SELECT * FROM t WHERE id=1 OR id=2 OR id=3。因为达梦8.0之前不支持IN列表超过1000项，而ShardingSphere的分片路由会产生超长IN列表。

启用方式：

props: sql-show: true check-table-metadata-enabled: false # 启用达梦专用解析器 database-type: dameng

其内部逻辑是：当检测到IN子句项数>500时，自动拆分为多个OR条件，并用UNION ALL合并结果。

注意：此改写会改变执行计划。原IN可能走索引范围扫描，改写后可能变成索引全扫描。因此，必须配合达梦的INDEX HINT强制走索引：

/*+ INDEX(t idx_id) */ SELECT * FROM t WHERE id=1 OR id=2 ...

5.4 达梦备份恢复：物理备份与逻辑备份的取舍

达梦提供两种备份方式，选择逻辑在于RTO/RPO要求：

• 物理备份（dmrman）：直接拷贝数据文件，RTO<5分钟，但RPO=上次备份点。命令：

  dmrman <<EOF backup database '/opt/dmdbms/data/DAMENG' backupset '/backup/dm_full_20231001'; EOF

  适合RTO敏感、可容忍少量数据丢失的场景。

• 逻辑备份（dexp/dimp）：导出SQL脚本，RTO>30分钟，但RPO=0（可指定QUERY条件）。命令：

  dexp USERID=SYSDBA/SYSDBA@192.168.1.100:5236 FILE=orders_20231001.dmp LOG=orders.log TABLES=(orders) QUERY=\"WHERE update_time > '2023-10-01 00:00:00'\"

  适合需精确恢复某张表或某段时间数据的场景。

经验法则：生产环境必须双备份。每天一次物理全备（凌晨2点），每小时一次逻辑增量备（基于update_time字段）。我们曾用此方案，在一次误删DELETE FROM users WHERE 1=1事故中，15分钟内恢复全部数据。

6. 常见问题速查表与独家避坑清单

6.1 四小龙高频问题速查表

6.2 我踩过的五个致命坑（附日志证据）

1. 达梦索引失效陷阱：某次上线后，SELECT * FROM logs WHERE level='ERROR'查询从0.1秒飙升至12秒。EXPLAIN显示走了全表扫描。最终发现是达梦对CHAR类型字段的索引匹配有特殊规则：WHERE level='ERROR '（末尾带空格）无法命中索引。解决方案：建索引时用RTRIM(level)函数索引，或应用层统一TRIM()输入。

2. 人大金仓时区漂移：K8s集群中，Kingbase Pod重启后，NOW()返回时间比宿主机快2小时。根源是容器启动时未同步宿主机时区。修复：在Deployment中添加env：

   env: - name: TZ value: "Asia/Shanghai" - name: LANG value: "zh_CN.UTF-8"

3. 南大通用分片倾斜：GBase 8a集群中，某张用户表90%数据集中在1个节点。原因是DISTRIBUTED BY (user_id)，而user_id为连续自增ID。修复：改用DISTRIBUTED BY (MD5(user_id))哈希分片。

4. 神舟通用事务超时：OSCAR中，一个复杂存储过程执行超时被强制回滚。经查是OSCAR的transaction_timeout默认值为30秒，而该过程需45秒。解决方案：在过程开头执行SET TRANSACTION_TIMEOUT = 60000;（单位毫秒）。

5. 达梦两地三中心脑裂：一次网络分区后，达梦主中心和异地中心同时对外提供服务，导致数据不一致。根本原因是DRM的ENABLE_CONFLICT_CHECK=0。修复：立即启用冲突检测，并在应用层增加SELECT DB_MAGIC() FROM DUAL校验库唯一性。

最后分享一个小技巧：达梦的DB_MAGIC()函数返回数据库唯一标识符（类似Oracle的DBID），在两地三中心场景中，可在每次写入前执行SELECT DB_MAGIC()，若返回值与本地缓存不符，则拒绝写入——这是防止脑裂的最后一道保险。