数据库课结束时，我翻了下这学期的笔记本，没想到关于达梦 DM8 的内容占了快一个本子。最初选《国产数据库技术》这门课，动机很单纯：想补一点国产数据库的实践经历，顺便看看它和主流开源数据库到底差多远。结果学完才发现，之前对国产数据库的判断有些想当然。DM8 是一款能从公开渠道拿到开发版、按文档也能完整搭出环境的关系型数据库，和平时用的开源数据库相比，它有自己的安装方式、对象模型和运维套路。这篇文章算是我这门课的全流程学习笔记，从零装实例开始，到写 SQL、做备份恢复、查性能、接应用，把走过的弯路和最终跑通的步骤都记下来，给正在接触国产数据库的同学做一个参考。
1. 从选课到搭环境：一门课如何让我重新审视国产数据库
1.1 选课前的偏见与第一堂课的冲击
选课前我听过很多关于国产数据库的讨论，心里多少带着三个偏见：一是觉得“国产”就是开源数据库换了个皮，底层没什么自主的东西；二是觉得生态不成熟，出了问题连个问的人都没有；三是觉得学习曲线会很陡，文档要么太厚要么太薄。第一堂课听完，前两个偏见动摇了。
课程里没有直接吹嘘功能，而是先给了 DM8 的整体架构图，从数据库实例、表空间、数据文件、控制文件到归档日志，讲得和主流关系型数据库一样成体系。课后作业是装一个单机实例，我当时就觉得，与其花时间争论“国产数据库行不行”，不如先把环境跑起来。真正动手之后才发现，它的安装包、初始化工具、管理工具和备份工具是一套完整闭环，不是随便拼出来的。这门课给我的第一个收获，就是人只能对自己亲手跑过的东西下判断。
1.2 课程主线与我的学习节奏
课程安排大致分成六段：体系结构、环境安装、SQL 与对象管理、备份恢复、性能诊断、应用对接。每段都配实验，不是只看 PPT。我每周大概拿出两个晚上，在虚拟机里把所有实验重新做一遍，比课堂上多走一步：记录下每个命令的报错和解决办法。
我的学习节奏比较固定。周一看文档对应章节，周二做实验，周末把笔记整理成自己的话。整理资料时发现，官方文档内容很全，但有些细节藏得深，例如初始化实例的参数影响、备份恢复的选择，这些在实验里被触发之后才真正理解。整门课下来，最花时间的不是写 SQL，而是“出问题后定位问题”的过程。这也是我把这篇笔记命名为“全流程深度笔记”的原因——深度不在功能遍历，而在遇到坑之后怎么爬出来。
1.3 工具清单：一台虚拟机加一份官方文档就够
实际跟下来，没有想象中那么重的工具依赖。我用的是一台 2 核 4G 内存、50G 磁盘的 Linux 虚拟机，装的是这个学期的实验环境。需要的软件其实不多：
- DM8 开发版安装介质，下载后是一个镜像文件
- 准备一个 Linux 用户专门跑数据库，比如
dmdba - 达梦自带的
disql、管理器（manager）、备份工具（dmrman）、逻辑导入导出工具（dexp/dimp） - 一份官方《DM8 管理员手册》和《DM8 SQL 使用手册》，遇到问题先翻手册
不需要特殊网络环境，也不需要额外图形桌面；安装时选择命令行模式就能完成。很多同学担心“文档看不懂”，我的体感是：手册更像工具书，不需要从头读，但要学会按目录查。等做到第四五周的时候，查手册的速度已经比上网搜快很多，因为语境是对的。
2. 安装部署是最先给我上课的地方
2.1 安装介质与预安装检查：顺序错了会撞墙
安装这一步看起来简单，实际隐藏着很多前置检查。我第一次安装就把顺序搞反了：直接解压介质然后运行安装脚本，结果图形界面起不来，报错信息里提示缺少依赖库，当时还不知道去哪看日志。
现在的标准流程是先做预安装检查。磁盘空间要保证/opt或安装目标目录有足够余量，内存至少 2G 以上，临时目录/tmp也要留空间。系统层面需要创建专用用户dmdba，并且给安装目录授权。很多文档说“建议创建 dmdba 用户”，我一开始图省事用 root 装，实验课老师提醒后才换掉。用 root 安装不是一定失败，但后续服务启动、文件权限容易乱，尤其是需要多个实例并行时，权限边界不清晰非常痛苦。
预安装检查清单大概是这样：
- 确认操作系统版本和位数，DM8 支持主流 Linux 发行版
- 检查 free -m 内存，至少 2G
- 检查 df -h，安装目标分区至少 10G 空闲
- 创建用户：
useradd -d /home/dmdba -m dmdba - 创建安装目录并授权：
mkdir -p /dm8 && chown -R dmdba:dmdba /dm8 - 检查依赖库，有的最小化系统缺
libncurses等，用包管理软件装上
这些检查看着琐碎，但每一步都有对应的事故。我自己经历了“图形界面闪退”“日志文件权限不足”“初始化时报内存不足”三个问题，最后全部回到预检清单，才意识到大部分问题都不是产品本身的问题，而是环境没准备好。
2.2 命令行安装比图形安装更可控
DM8 安装支持图形和命令行两种方式。第一次实验我坚持用命令行，不是不想看图，而是虚拟机里图形界面总出问题。命令行安装的核心命令是DMInstall.bin -i，按提示选择语言，然后输入安装路径。整个过程没有太多交互项，基本是“下一步”的文本版本。
装到中间会显示一个路径，请仔细确认。安装程序结束后，通常会提示“请以 root 用户执行某个脚本”。这里非常关键：如果少了这一步，数据库服务注册、dmserver 启动脚本可能不完整。我第一遍装的时候忽略了提示，后来手动补跑脚本才把服务串起来。
命令行安装的实际过程类似：
# 切换用户 su - dmdba # 进入介质目录 cd /mnt/dm8_setup # 执行命令行安装 ./DMInstall.bin -i过程中需要输入安装路径/dm8，选择是否初始化数据库，我选择了“否”，先把软件装好，再用dminit单独初始化，这样便于理解每一步的作用。推荐新手也这样拆开做，不要把安装和初始化混在一次向导里，否则出了问题不知道是哪一步的配置导致的。
2.3 dminit 初始化实例：几个必须提前想清楚的参数
装好软件之后，下一步是初始化实例。DM8 用dminit创建数据库实例，初始化后会在数据目录下面生成一套数据文件。这个工具在使用上很简单，参数却要提前想清楚，因为很多参数初始化后不能随便改。
我初始化时使用的大致命令如下：
cd /dm8/bin ./dminit PATH=/dm8/data/DMDB \ DB_NAME=DMDB \ INSTANCE_NAME=DMSERVER \ PORT_NUM=5236 \ PAGE_SIZE=16 \ CHARSET=1 \ CASE_SENSITIVE=1这里每个我都会展开讲。PAGE_SIZE是页大小，决定数据页的单位，小的业务 8K 或 16K 都常见，初始化后要想调大通常需要重建库。CHARSET=1表示字符集，按实际需求选 UTF-8 或 GBK，项目中如果有多语言需求建议 UTF-8。CASE_SENSITIVE控制标识符大小写是否敏感，这个直接影响后续建表时表名大小写的写法，最坑的是很多人建表时用双引号包了表名，之后每次查询都要带双引号。
还有PATH和DB_NAME：PATH是数据文件产生的目录，DB_NAME是数据库名。默认端口 5236，生产环境如果要用其他端口，最好在初始化时就定好。我第一次初始化为了省事全部用默认值，后面想改端口，虽然也能改，但涉及连接串、防火墙规则和应用配置，整套联动变化，代价不小。
2.4 从启动服务到登录 disql：搭建起第一个可用实例
初始化完成后，数据库还处于“没启动”的状态。启动方式有两种：手动前台启动 dmserver，或者注册为系统服务。实验阶段我建议先手动启动，因为能看到日志输出：
su - dmdba cd /dm8/bin ./dmserver /dm8/data/DMDB/dm.ini看到类似“SYSTEM IS READY”的日志，实例就起来了。服务启动后，再开一个终端用disql登录：
cd /dm8/bin ./disql SYSDBA/SYSDBA@127.0.0.1:5236登录进去能看到SQL>提示符，执行SELECT * FROM V$VERSION;可以查版本。这一步成功，我才觉得“环境搭好了”。不过要注意环境变量，如果不设置DM_HOME=/dm8和PATH=$DM_HOME/bin:$PATH，每次都要敲完整路径。把环境变量写进/home/dmdba/.bash_profile里，后面所有命令都会舒服很多。
还有一个容易漏的步骤:注册服务。如果希望开机自动启动，需要在 root 用户下执行安装时提示的脚本，把 dmserver 注册成服务。我在实验阶段没有做这一步，因为手动启动方便观察日志；但期末项目为了省事，还是补上了服务注册，毕竟让数据库手工启动不是长久之计。
3. 从 SQL 语法到对象管理：兼容性背后的“自己的脾气”
3.1 用 MySQL 习惯写 DM8 的第一天
因为平时最常用 MySQL，我一开始写 DM8 的 SQL 时充满自信，觉得“都是关系型数据库，SQL 还能差多少”。第一天实验就把我拉回现实：大小写敏感、空串和 NULL 的处理、日期函数的写法、字符串拼接符号，这些细节全都可能不一样。
举几个我自己踩过的差异点：
- 字符串拼接：MySQL 常用
CONCAT()或||，DM8 在默认情况下更接近 Oracle 风格，用||是顺手写法，但用CONCAT()也要看参数个数。 - 空串与 NULL：在 DM8 中两者的区分比 MySQL 严格，做
WHERE判断时结论可能不同。 - 自增列：MySQL 一个
AUTO_INCREMENT解决问题，DM8 里我习惯用IDENTITY，或者建序列配合触发器。
有一个更值得提醒的点：DM8 提供多种兼容模式，例如兼容 Oracle、兼容 MySQL，不同模式下部分语法表现不一样。我刚接触时以为安装后默认就是 MySQL 模式，实际不是。正确的做法是，先确认当前实例的兼容模式，再决定 SQL 写法。课程实验里我们大部分时间在默认模式下操作，所以遇到 MySQL 特有语法时不能直接照搬。
3.2 表空间、用户和权限：绕不开的三座山
在 MySQL 里，“建库”和“建用户”是两件事，但写起来很直接。DM8 里的概念更接近 Oracle：数据是存在表空间里的，用户拥有自己的 Schema，用户访问对象时和权限绑定。这个结构一开始让我很别扭，因为“建库”这件事不再是简单的CREATE DATABASE，而是“先建表空间，再建用户并指定默认表空间”。
我实验里常用的一套创建逻辑：
CREATE TABLESPACE APP_DATA DATAFILE '/dm8/data/DMDB/APP_DATA.DBF' SIZE 1024; CREATE USER APP_USER IDENTIFIED BY "P@ssw0rd" DEFAULT TABLESPACE APP_DATA; GRANT DBA TO APP_USER;这里有一个明显的习惯变化：GRANT DBA TO APP_USER相当于给了较大权限。实验环境图省事没问题，但如果是项目实战，不应该一上来就给普通业务账号 DBA 权限。更合理的做法是按需授权：能查的库给查询权限，能写的表给增删改权限，需要执行存储过程的再单独授权。
权限地图要搞清楚三张表/视图：DBA_USERS查用户，DBA_TABLESPACES查表空间，DBA_TAB_PRIVS查权限。遇到“用户看着存在但连不上库”或者“有账号但看不到表”的问题，先查这三处，基本能定位。
3.3 表、索引、序列和视图：实际建库时最常用的对象
建表本身没有太大悬念，但数据类型要注意。常用写法：
CREATE TABLE APP_USER ( ID INT IDENTITY PRIMARY KEY, NAME VARCHAR(64) NOT NULL, STATUS TINYINT DEFAULT 1, CREATED_TIME TIMESTAMP DEFAULT SYSDATE );IDENTITY相当于自增列；SYSDATE是当前时间；VARCHAR需要给长度。真实业务里如果从 MySQL 迁过来，字段类型映射是个独立任务，不能直接照搬int(11)这种写法。
索引这一块，DM8 支持 B 树索引、位图索引、函数索引。最常见的还是普通 B 树索引：
CREATE INDEX IDX_APP_USER_NAME ON APP_USER(NAME);序列用于生成业务编号，和 Oracle 的SEQUENCE写法一致：
CREATE SEQUENCE SEQ_USER_ID START WITH 1 INCREMENT BY 1; SELECT SEQ_USER_ID.NEXTVAL FROM DUAL;视图也很常规，CREATE OR REPLACE VIEW可以直接用。课堂上老师特意强调过：视图只是封装逻辑，不能带来性能收益，查询视图和执行底层 SQL 是等价的。很多同学以为建了视图就会快，这个误解要尽早纠正。真正影响性能的是索引、统计信息和执行计划。
3.4 存储过程调试：被 PL/SQL 惯性坑了一把
因为我之前写过一些存储过程，以为到了 DM8 只是换个语法。真正调试时才明白，它的存储过程风格和 Oracle 更接近，不是 MySQL 那种BEGIN...END就完事。
一个最简单的示例：
CREATE OR REPLACE PROCEDURE P_HELLO AS BEGIN PRINT('HELLO DM8'); END;执行时用：
CALL P_HELLO();或者放到语句块里：
BEGIN P_HELLO(); END;我第一次写的时候把AS忘了，又用了 MySQL 的DELIMITER习惯，结果管理工具一直报语法错误。后来在管理工具里打开存储过程调试功能，设置断点，看变量值，才慢慢摸清套路。调试存储过程的体验很接近 Oracle PL/SQL，变量赋值、游标、异常处理都是相似的。
看到这里，如果你只是把 DM8 当成“又一个关系型数据库”，会发现它不复杂；但如果你想用“MySQL 的思维”套上去，就处处别扭。这一点是整个学习过程中最需要花时间接受的地方：先承认它有自己的习惯，再谈兼容和迁移。
4. 备份恢复实战：把误删当成一次岗位培训
4.1 从 dexp/dimp 开始做逻辑备份
备份恢复是数据库运维的核心动作，这门课在这个环节安排了几次实验，其中一次“误删数据恢复”给我留下的印象最深。
先说逻辑备份。DM8 提供dexp导出和dimp导入，命令风格类似主流数据库的 exp/imp。实际使用的命令大概长这样：
cd /dm8/bin # 整库逻辑导出 ./dexp SYSDBA/SYSDBA@127.0.0.1:5236 \ FILE=/dm8backup/full.dmp \ LOG=/dm8backup/full.log \ SCHEMAS=APP_USERSCHEMAS=APP_USER表示导出某个用户下所有对象。dimp则反过来导入。逻辑备份的优点是粒度灵活，可以按用户、按表导出，跨环境迁移数据时很好用；缺点是不能替代物理备份，因为它不是数据库文件级别的镜像，恢复时如果遇到损坏的数据页，逻辑层面往往无能为力。
我自己的判断是：逻辑备份适合“数据搬家”和“恢复个别对象”，比如从一个测试库导出某张表到生产库；但日常备份策略必须以物理备份为主。课程里很多同学只学会了 dexp，没学 dmrman，后来做恢复实验时才发现两者针对的场景完全不同。这一点在真实运维中非常关键。
4.2 dmrman 物理备份：生产环境的首选
物理备份使用达梦的备份恢复工具dmrman。这个工具可以进入交互模式：
cd /dm8/bin ./dmrman然后执行全量备份：
BACKUP DATABASE FULL BACKUPSET '/dm8backup/backup_20250610';备份成功后，在备份目录下会生成备份集目录，里面包含备份文件本身，以及记录备份元信息的文件。做任何恢复操作前，都应该先用SHOW BACKUPSET确认备份是否存在且完整。课程老师反复强调：“备份不算完成，除非你验证过能恢复。”所以我在每次全量备份后，都会在另一台虚拟机或另一目录里做一次恢复演练，看着麻烦，但真出事的时候能救命。
物理备份分为全量、增量、归档备份。全量是从头一份完整副本，增量依赖上一次备份，归档备份以归档日志为对象。对新手来说，先把全量备份和归档打开，形成一套“每天全量+实时归档”的组合，是最稳妥的起步方案。
4.3 开启归档与时间点恢复
要支持时间点恢复，数据库必须运行在归档模式。DM8 开启归档有两种思路：一是用 SQL 命令动态添加归档配置，二是直接改dm.ini。我实验里用的是 SQL 动态配置，步骤是：
ALTER DATABASE ADD ARCHIVELOG 'DEST=/dm8arch/TYPE=LOCAL/FILE_SIZE=256/SPACE_LIMIT=0'; ALTER DATABASE ARCHIVELOG;执行完后重启实例让参数生效。归档日志目录需要提前创建好，并且给dmdba用户写入权限。我自己第一次做时忘了建目录，命令报错后去翻日志才明白，这类“小前置条件”往往比命令本身更容易被忽略。
配置归档后，物理备份恢复能做到“按时间点”回放。比如某个业务表在 10:15 被误删，而昨晚有一次全量备份，归档日志完整保留到 10:20。那么恢复思路是：用昨晚全量备份还原数据库，再把归档日志回放到 10:14，最后把该表数据导出并导回生产库。这个流程听起来清晰，实操时要反复验证，因为归档日志的完整性和连续性一旦断裂，时间点恢复就做不准。课程里做四次恢复实验，有两次失败在“归档不连续”上。
4.4 一次误删数据后的完整恢复复盘
期末前我误删了一张测试表的全部数据。场景不复杂：我在一个测试环境里执行清理脚本，条件写反了，本意是删除过期数据，结果把整张表清空。第一时间我没有继续操作，而是把现场保护住，然后按课堂流程走了一遍恢复。
整个恢复过程记录如下：
- 停止应用对这张表的访问，避免新的写入污染现场。
- 检查最新全量备份和归档日志是否连续。
- 在另一台机器上用备份副本做还原演练，不在生产环境直接恢复。
- 确认演练成功之后，在生产环境执行还原，恢复到一个时间点。
- 导出恢复出来的目标表数据，再导入生产环境，做行数校验。
复盘时我发现，真正让我从容的不是“知道 restore 命令怎么敲”，而是提前验证过备份可用。备份文件躺在那里三个月没恢复过，和生产数据有没有一致性，谁也不敢保证。这轮实验之后，我把自己的习惯改成：每次全量备份后立刻做一次“恢复练习”，哪怕只是恢复到测试库用来验证行数。这个习惯花不了太多时间，却能把最危险的“备份不能用”风险提前拦住。
5. 性能诊断与参数调优：把慢 SQL 和配置参数一起处理
5.1 怎么找到真正拖慢查询的 SQL
性能部分是课程后半程的重头戏。一开始我以为性能调优就是“加索引”，后来发现第一步是定位问题，第二步才是优化。
DM8 提供了一堆监控视图，例如V$SESSIONS可以看到当前会话，V$SESSION_LONGSQL或日志可以看慢 SQL。我实验里最常用的方法是把 SQL 日志打开，在dm.ini中找到日志相关参数，打开慢 SQL 记录开关，设置一个阈值（比如超过 2 秒的 SQL 就记录）。然后模拟一批查询，回来看日志文件里到底哪些 SQL 最慢。
有同学会直接到网上搜“DM8 慢 SQL 查询 SQL”，这种思路不如自己构造场景理解深。我先故意写几个没索引的关联查询，把慢 SQL 日志刷出来，再对比加了索引后的执行时间和日志输出，整个过程非常直白。定位慢 SQL 的本质不是背命令，而是建立“业务慢 -> 数据库日志 -> 具体 SQL -> 执行计划”这条排查链路。遇到问题顺着链路走，比盲目调参有效得多。
5.2 执行计划和统计数据：分析慢 SQL 的两只手
定位到慢 SQL 后，下一步是看执行计划。DM8 里可以用EXPLAIN直接看某条 SQL 的执行计划，例如：
EXPLAIN SELECT * FROM APP_ORDER WHERE ORDER_NO = '20250610001';执行计划会显示这个查询走了什么样的访问路径。最常见的问题是“没有走索引用全表扫描”，尤其是数据量大之后，全表扫描代价非常高。这时候要考虑：索引是不是建了但没被选到，统计信息是不是过期，WHERE 条件中的字段是不是发生了隐式类型转换。
统计信息这个点我在学习初期完全忽略。后来期末项目里遇到一条 SQL，数据量从 10 万涨到 200 万之后突然变慢，查执行计划发现还是全表扫描。原因是统计信息还停留在小数据量阶段，优化器判断“反正表很小，扫描更快”。手动收集统计信息后，执行计划就切到了索引。DM8 中常用DBMS_STATS.GATHER_TABLE_STATS这类包来收集统计信息，具体表名可以按需求传入。无论用哪个函数，核心逻辑都一样：让优化器掌握最新的数据分布。
5.3 常见参数调整思路与我的实际改法
DM8 的运行参数集中在dm.ini文件里，很多参数能在线查看。我实验时主要关注内存、并发、IO 三类参数。内存方面常见的有缓冲区大小、缓存池大小、缓冲池个数；并发方面有最大会话数、工作线程数。注意，不同版本参数名可能存在细微差异，实践时先通过V$PARAMETER视图查看当前值，再决定改哪些。
调整步骤上，我习惯先在测试环境修改并观察，再上生产。比如最大会话数明显不够时，应用会报无法创建新的连接。这种问题在应用日志里看得清楚，修改后重启实例即可。缓冲区相关参数如果调得过大，会大量占用操作系统内存，甚至触发 swap，所以不能盲目“越大越好”。
课程上也强调了一个观念：参数调优是最后一步，不是第一步。SQL 索引没做，统计信息没收集，直接去改几十个参数，属于无的放矢。正确的顺序是：先确认业务 SQL 是否合理，再确认索引和统计信息，最后才看系统参数。很多“数据库卡顿”其实是某个 SQL 写得太差，不是数据库本身不行。
5.4 一次“内存占用异常”排查：大页和参数确认
期末项目里我遇到一次“数据库进程内存占用异常高”的情况。一个单机实例，业务量很小，数据库进程却占用了大量物理内存，连同一台机器上的其他服务都开始变卡。我一度怀疑是内存泄漏，后来按照排查链路走才发现，不是泄漏，是内存参数设置和系统大页配置叠加的结果。
现象如下：free -m看到剩余内存很低，top里数据库进程的RES很大；但通过系统信息查看大页配置时，发现大页被预占了，数据库并没有真正频繁使用这些大页。换句话说，操作系统把内存留给大页，数据库却在用自己的缓冲区逻辑申请普通内存，两边没有配合好。
解决方案并不复杂：根据实例的内存需求重新配置大页，或者关闭不必要的预分配，再结合dm.ini中缓冲区相关参数调整。调整后重启实例，观察内存占用回落。这次排查最有价值的不是那个具体参数，而是我发现自己原来对“数据库进程占内存”想得太简单。内存占用不只是缓存数据，还和参数配置、操作系统内存管理方式强相关。排查问题要有全局视角，不能只盯数据库这一个进程。
6. 应用接入与实战：把 DM8 真正放进项目里跑
6.1 JDBC 连接串、驱动类和常见连接报错
课程最后一阶段是应用对接，这也是很多人关心的“实战”部分。DM8 提供 JDBC 驱动，接入方式和传统数据库类似。Spring Boot 项目里的配置大致如下：
spring: datasource: driver-class-name: dm.jdbc.driver.DmDriver url: jdbc:dm://127.0.0.1:5236/DMDB username: APP_USER password: P@ssw0rd我第一次连接时报的是“无法加载驱动类”，原因是项目中没有引入 DM8 的 JDBC 驱动 jar 包。把 jar 打进依赖后，又遇到“连接被拒绝”，检查才发现端口号写错。最后是“用户名或密码错误”，因为我在初始化实例时设置了大小写敏感，密码里的字母大小写被严格区分。
还有一点值得注意：DM8 的 JDBC URL 中DMDB是库实例名，而应用连接后用户默认 schema 是用户名对应的 schema。很多从 MySQL 迁移过来的同学会下意识把DMDB当成 MySQL 里的 database 名，其实这里语义不同。如果应用里用schema.table的方式访问，表名前要加对 schema 名称，否则会报“无效的表名”。第一次接入项目时，这类概念差异最容易引发连接串配置混乱。
6.2 ORM 框架对接时容易踩的坑
项目里用 MyBatis 比较多，对接 DM8 时主要问题是方言和分页。MyBatis 的LIMIT写法在 DM8 不同兼容模式下表现不同，直接用 MySQL 模式下的分页 SQL 有概率报错。比较稳妥的做法是：先确认实例模式，再选择对应的数据库方言；如果项目里使用了分页插件，要确保插件支持 DM8。
另一个常见坑是自动生成主键的返回方式。在 MySQL 里插入数据后拿自增主键很顺滑，DM8 中如果使用IDENTITY列，JDBC 驱动也支持getGeneratedKeys方式返回主键，但前提是建表语句和插入语句的写法能被驱动正确识别。我在实验里出现过“插入成功但主键返回 0”的情况，后来调整了主键生成策略才解决。避免踩坑的方法是：用一个最小化表先做增删改查冒烟测试，确认主键返回、时间字段、空值处理都符合应用预期后，再全面铺开改造。
此外，Boolean映射、金额字段的精度、时间类型的时区处理，这些在 ORM 映射里都可能和 MySQL 不一致。我的建议是先做一张“映射测试表”，把所有项目中用到的数据类型放进去，专门用来验证框架层面的映射，能省去后期大量排查时间。
6.3 数据迁移：从 MySQL 搬到 DM8 的那些坑
课程项目里有一项任务是把一个模拟业务系统的数据从 MySQL 迁移到 DM8。我们用的是达梦自带的数据迁移工具，图形界面，流程是“新建工程 -> 新建迁移 -> 配置源端 -> 配置目标端 -> 选择对象 -> 执行迁移”。顺利的话，小表几分钟就迁移完，但过程中有几个坑值得记下来。
第一，表名大小写。如果源库表名是小写，而 DM8 初始化时设置了大小写敏感，迁移后查询时可能要加双引号。第二，字段类型映射不是完美对应，比如 MySQL 的tinyint(1)可能被映射成 BIT，应用层拿到后行为不一致。第三，自增列、默认值、注释信息有时会丢，迁移后必须逐表核对。
我的处理流程是：先做全量结构迁移，再对比字段和主键；然后迁移数据，用SELECT COUNT(*)做行数校验；最后在 DM8 上跑应用的核心 SQL，重点看那些用了 MySQL 特有函数的语句，比如GROUP_CONCAT、DATE_FORMAT。这类函数在 DM8 中不一定有同名实现，需要改写。数据迁移不是“搬运”，而是一个包含映射、校验、回归测试的完整工程。如果跳过校验，很容易出现“数据行数对上了，但业务 SQL 跑不出来”的尴尬局面。
6.4 一个报表查询从改造到上线的完整记录
期末项目里我负责的模块是一张统计报表。原系统在 MySQL 上，报表 SQL 用了几处 MySQL 习惯写法，迁移到 DM8 之后怎么改，是我这门课最大的综合演练。
第一步，把原始 SQL 在 DM8 测试库跑一遍，收集所有报错。第二类问题集中在函数兼容性上：例如日期格式化函数名称不一致，字符串聚合函数的写法不同。第二步，逐条改写。字符串聚合在 MySQL 里常用GROUP_CONCAT，DM8 默认模式下不直接支持同名函数，我改写成兼容 Oracle 风格的LISTAGG语法。日期格式化从DATE_FORMAT改成 DM8 支持的写法。第三步，验证结果集行数。改写后最担心的是表连接条件中字段类型隐式转换导致结果集变化，所以我把改写前后的查询结果导出成文件做对比，确认行数和关键列一致。
这轮改造对我的收获很大：数据库兼容性不是一个“能跑就行”的话题，而是语法、类型映射、函数行为多层面的适配工作。上线前我还要在测试环境执行一遍完整报表刷新流程，确认它能稳定产出结果。整个过程做完，我才真正觉得“从入门到实战”这一课完整闭环了。
7. 学完这门课，留在我工作习惯里的几件事
学期结束后，我不只在笔记里多了几百条记录，工作习惯也变了一些。第一，无论用什么数据库，我都会把“备份恢复”放在优先级最高的位置。以前用 MySQL 时我很少做恢复演练，现在每次备份完都会在测试环境恢复一次，这个习惯就是从 DM8 的误删恢复实验养成的。第二，初始化参数变得非常郑重。以前我建库随手选默认值，现在会先把页面大小、字符集、大小写敏感这几个关键参数确定下来，再动手，因为后面改动的代价可能很大。第三，遇到性能问题先看执行计划和统计信息，而不是急着加内存。
如果让我给后来者一句实在建议，那就是：不要只在文档层面了解国产数据库，也不要只在图形工具里点几个按钮就当自己会了。真正把安装、备份、恢复、调优、应用接入这条链路完整走一遍，遇到几个报错并解决掉，才算有基础。对我自己来说，这门课之后至少再遇到达梦 DM8 能坦然坐下排查，而不是先问身边的人“这环境该怎么搭”。以后如果再接触其他国产数据库，我也会用同样的方式去验证：先装环境，再做恢复演练，最后让一条真实业务 SQL 在自己的库上跑出结果。
