企业官网建设流程全解析

1. 项目概述：从MySQL到DM的国产化迁移之路

最近几年，身边不少朋友和客户都在聊一个话题：国产化替代。尤其是在一些对数据安全、技术自主可控要求比较高的领域，把核心业务系统从国外的数据库（比如我们熟悉的MySQL）迁移到国产数据库，已经从一个可选项变成了必选项。我手头就刚完成了一个中型电商系统的数据库迁移，从MySQL 5.7整体迁到了达梦数据库（DM8）。整个过程踩了不少坑，也积累了一些实战心得，今天就来详细聊聊这件事。

所谓“MySQL迁移DM”，核心目标就是把运行在MySQL上的数据库结构（表、视图、索引、存储过程等）和数据，完整、准确、高效地搬迁到达梦数据库上，并确保迁移后的应用系统能无缝衔接、稳定运行。这不仅仅是换个数据库软件那么简单，它涉及到两种不同数据库产品在语法、功能、性能特性乃至底层理念上的差异。达梦作为一款成熟的国产关系型数据库，在语法上高度兼容Oracle和MySQL，这为迁移降低了门槛，但魔鬼藏在细节里，数据类型映射、函数替换、SQL方言调整这些地方才是真正考验人的地方。

这次迁移的驱动因素很明确：满足政策合规与安全可控的要求。对于金融、政务、能源等关键行业，使用自主可控的数据库技术是硬性规定。达梦数据库在这些领域有广泛的应用基础和良好的口碑。从技术角度看，DM提供了完善的迁移工具链和兼容模式，理论上路径是通的。但实操起来，你会发现从开源生态丰富的MySQL，切换到一个相对“封闭”的国产环境，需要调整的地方远比想象的多。这篇文章，我就以一个过来人的身份，把从评估、准备、迁移、验证到上线的全流程拆解清楚，希望能给正在或即将面临同样任务的你，提供一份可落地的参考手册。

2. 迁移前的核心评估与方案设计

动手之前，盲目开干是大忌。一次成功的迁移，70%的功夫要花在前期评估和方案设计上。你需要像医生一样，先给现有的MySQL系统做一次全面的“体检”。

2.1 源端（MySQL）环境深度剖析

首先，你得彻底摸清家底。我习惯从以下几个维度入手，并记录成清单：

1. 数据库规模与对象统计：

   • 数据量：不是简单的“有几个G”，而是要分库分表统计。用SELECT table_schema, table_name, ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb FROM information_schema.TABLES ORDER BY size_mb DESC;这样的语句，列出所有表的大小。这直接决定了迁移耗时和资源规划。
   • 对象清单：统计数据库、表、视图、存储过程/函数、触发器、事件的数量。特别是存储过程和触发器，它们是迁移的重难点。
   • 字符集与排序规则：MySQL常用的utf8mb4和utf8mb4_general_ci，需要与达梦的字符集（如UTF-8）做好映射。不一致可能导致乱码。

2. SQL与代码依赖扫描：

   • 专属语法识别：MySQL有很多“方言”，比如`反引号包裹对象名、LIMIT子句、ON DUPLICATE KEY UPDATE语句、GROUP_CONCAT函数等。这些在达梦中可能没有直接对应，或语法不同。
   • 应用程序SQL审计：如果条件允许，收集一段时间内应用执行的所有SQL语句（可通过慢查询日志或数据库审计插件）。这能发现那些在表结构里看不到，但实际在用的复杂查询、子查询、连接方式等。
   • ORM框架与连接池配置：检查应用使用的框架（如MyBatis, Hibernate, JPA等）及其配置。不同的数据库驱动和方言（dialect）需要调整。

3. 性能基线建立：

   • 在迁移前，对核心业务场景的关键SQL进行性能采样，记录其执行时间、资源消耗。迁移后以此作为对比基准，确保性能没有劣化。

注意：这一步千万别偷懒。我曾经遇到一个项目，迁移后才发现某个报表功能巨慢，排查后发现是应用代码里用了一个MySQL特有的日期计算函数DATE_SUB(…, INTERVAL 1 DAY)，在达梦里不直接支持，而迁移工具没处理到。事后补救的成本远高于事前发现。

2.2 目标端（DM）环境规划与选型

摸清MySQL的情况后，就要规划达梦这边怎么接了。

1. 版本选择：目前达梦主推DM8。建议选择最新的稳定版，通常修复了更多已知问题，对MySQL的兼容性也更好。要确认是x86还是ARM架构，这与服务器硬件匹配。
2. 部署模式：是单机、主备集群还是读写分离集群？对于大多数中型系统，先从单机或主备模式开始迁移是比较稳妥的。资源规划（CPU、内存、磁盘）最好比MySQL现有环境预留20%-30%的余量，因为初期优化可能不到位。
3. 兼容模式设置：这是达梦的一大特色。你可以在初始化数据库实例时，或通过后置参数，将其兼容模式设置为MYSQL。这会让DM在解析SQL时，更贴近MySQL的行为，比如将双引号识别为字符串，而不是对象名（Oracle风格）。但切记，兼容模式不是万能的，它主要解决的是解析层面的问题，很多函数和底层行为差异仍需手动处理。
4. 工具准备：
   • 达梦数据迁移工具（DTS）：这是官方图形化工具，位于安装目录下的tool/dts中。适合中小规模数据迁移和结构迁移，可视化操作比较友好。
   • DMDBA命令行工具：dimp（导入）和dexp（导出），适合大批量数据迁移和自动化脚本集成。
   • 第三方工具：也可以使用DataX、Kettle等开源ETL工具，搭配达梦的JDBC驱动进行迁移，灵活性更高。
   • 驱动：准备好对应版本的达梦JDBC驱动（DmJdbcDriver18.jar），用于应用连接。

2.3 制定详尽的迁移方案与回滚计划

评估完成后，需要形成书面方案。

1. 迁移策略：
   • 一次性迁移：适用于允许长时间停机的系统。在某个业务低峰期（如深夜），停机、迁移、验证、切换。
   • 增量迁移：适用于要求停机窗口极短或零停机的系统。先全量迁移历史数据，然后在切换前，通过捕获并应用MySQL的binlog（或使用第三方工具同步增量数据）到达梦，最终实现平滑切换。这方案复杂，但对业务影响最小。
2. 人员与职责：明确DBA、开发、测试、运维各角色的任务和时间点。
3. 回滚计划：没有回滚计划的迁移就是耍流氓。必须明确，在哪个时间点之前，如果出现无法解决的问题，可以快速切回MySQL。这通常意味着在迁移过程中，原MySQL系统必须保持完好，直到新系统稳定运行一段时间后再考虑下线。回滚步骤要像迁移步骤一样清晰可操作。
4. 测试方案：设计单元测试（SQL功能验证）、集成测试（应用接口验证）和压力测试（性能验证）的用例和标准。

3. 迁移实操：结构迁移与数据迁移

方案定好，就进入真刀真枪的实操环节。迁移的核心两步：先搬“房子”（结构），再搬“家具”（数据）。

3.1 使用达梦DTS工具进行结构迁移

达梦数据迁移工具（DTS）是首选。启动dts，新建一个“MySQL到达梦”的迁移工程。

1. 连接配置：

   • 源库MySQL：填写IP、端口、数据库名、用户名、密码。关键是JDBC连接串，确保网络通畅，且MySQL用户有足够的权限（SELECT,SHOW VIEW,TRIGGER,PROCESS等）。
   • 目标库DM：同样填写连接信息。这里建议使用专门为迁移创建的、具有DBA权限的用户。

2. 迁移对象选择：

   • 在树状列表中勾选需要迁移的数据库、表、视图等。这里有个技巧：不要一次性全选。建议先迁移几个核心表或一个独立的业务模块进行试迁移，验证流程和结果。
   • 特别注意勾选“迁移表结构”、“迁移约束”（主键、外键、唯一约束）、“迁移索引”。对于“迁移数据”，在结构迁移阶段可以先不勾选。

3. 类型映射配置：

   • 这是结构迁移的关键。点击“类型映射”或类似按钮，你会看到一个预定义的映射表。大部分基础类型（INT,VARCHAR,DATETIME）的映射是准确的。
   • 需要重点检查的类型：
     • TINYINT(1)：在MySQL中常被ORM框架（如JPA）默认为布尔类型（Boolean）。在达梦中，默认会映射为TINYINT。如果你的应用代码依赖其布尔语义，可能需要手动将其映射为达梦的BIT类型，或者在应用层处理。
     • BLOB/TEXT类型：注意其长度限制。达梦的BLOB和CLOB与之对应，但行为可能有细微差别。
     • 自增列：MySQL的AUTO_INCREMENT，在达梦中对应的是IDENTITY(1,1)。DTS通常能正确转换，但迁移后务必检查表结构，确认自增属性已生效。
   • 字符集映射：确保源端的utf8mb4正确映射到达梦的UTF-8（或GB18030，根据实际情况定）。

4. 转换与执行：

   • 配置好后，点击“转换”。DTS会分析MySQL的DDL，并将其转换为达梦的DDL。务必仔细查看转换日志！日志中会列出所有不兼容的语句、无法自动转换的对象（尤其是视图、存储过程、触发器）以及警告信息。
   • 对于无法转换的复杂视图或存储过程，日志会给出原因，你需要根据这些信息进行手动重写。
   • 确认无误后，再点击“执行”，将结构真正创建到达梦数据库中。

实操心得：结构迁移阶段，我强烈建议将DTS生成的达梦DDL脚本保存下来。方法是在转换后，不直接执行，而是选择“生成SQL脚本”。这样你得到的是一个纯SQL文件，可以在达梦的DM管理工具或disql命令行中反复执行、审查和修改，也便于纳入版本管理。

3.2 数据迁移的两种主流方式

结构建好了，接下来就是灌数据。根据数据量大小，选择不同策略。

方式一：使用DTS工具全量迁移对于百GB以下的数据量，DTS的图形化界面迁移比较直观。

• 步骤：在刚才的迁移工程中，重新配置，这次只勾选“迁移数据”，并选择所有表。
• 配置项：
  • 提交条数：控制每次事务插入的数据量，比如设置为1000条。太大可能导致回滚段膨胀，太小则事务开销大。根据服务器性能调整，5000-10000是个不错的起点。
  • 错误处理：建议选择“忽略错误，继续迁移”，并勾选“记录错误数据”。这样不会因为某条脏数据卡住整个进程，迁移完成后统一处理错误记录。
  • 性能调整：可以调整并发线程数。但注意，并非线程越多越快，需要观察目标库的CPU和IO负载。
• 优缺点：简单易用，能直观看到进度。但对于超大数据表，可能会比较慢，且中途失败可能需要重头再来。

方式二：使用dexp和dimp命令行工具对于TB级数据或需要自动化、分批次迁移的场景，命令行工具更强大、更稳定。

• 思路：先用MySQL的mysqldump或其他工具将数据导出为通用格式（如CSV、SQL插入语句），然后利用达梦的dimp导入。但更高效的方式是，使用达梦提供的dmfldr（快速装载工具）直接导入CSV文件。
• 示例流程：
  1. 从MySQL导出CSV：

     # 在MySQL服务器上，使用SELECT ... INTO OUTFILE (需要FILE权限) mysql -h主机 -u用户 -p密码 数据库名 -e "SELECT * FROM 大表 INTO OUTFILE '/tmp/大表.csv' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '\"' LINES TERMINATED BY '\n';"

     或者使用客户端工具如mysqldump --tab导出为文本文件。
  2. 准备达梦控制文件ctl.ctl：

     # ctl.ctl 内容示例 LOAD DATA INFILE '/tmp/大表.csv' INTO TABLE 模式名.大表 FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' TRAILING NULLCOLS ( 列1, 列2, ... )

  3. 使用dmfldr导入：

     /opt/dmdbms/bin/dmfldr 用户名/密码@主机:端口 CONTROL=\'ctl.ctl\'

• 优缺点：性能极高，尤其适合海量数据；易于集成到自动化脚本中。但步骤稍复杂，需要处理文件传输和格式对应。

方式三：使用DataX等ETL工具如果团队熟悉DataX，这也是一个很好的选择。它支持丰富的读写插件，通过JSON配置文件定义任务，可以实现MySQL Reader -> DM Writer的流水线。

• 优点：灵活，可定制化程度高，支持增量同步、脏数据清洗等复杂逻辑。
• 缺点：需要一定的开发配置能力，且性能调优需要经验。

注意事项：无论用哪种方式，数据迁移务必在业务低峰期进行。迁移过程中，源库最好设置为只读，防止新旧数据不一致。迁移后，立即进行数据一致性校验，可以通过对比记录总数、对关键字段求和（checksum）等方式进行抽样或全量核对。

4. 应用代码与SQL适配改造

数据和结构过去了，但要让应用跑起来，代码层面的改造是工作量最大、也最容易出问题的一环。这就像给汽车换了发动机，油路、电路也得跟着调。

4.1 数据库连接配置调整

这是最简单的第一步。

1. JDBC驱动：将应用依赖中的MySQL驱动（如mysql-connector-java-xxx.jar）替换为达梦驱动（DmJdbcDriver18.jar）。
2. 连接URL：
   • MySQL:jdbc:mysql://localhost:3306/dbname?useUnicode=true&characterEncoding=utf8
   • DM:jdbc:dm://localhost:5236/DAMENG?compatibleMode=mysql（注意端口默认是5236，compatibleMode=mysql参数有时能解决一些兼容性问题）
3. 连接池配置：检查连接池（如HikariCP, Druid）的配置。达梦的连接测试查询（validationQuery）通常用select 1即可，但有些连接池可能需要设置特定的驱动类名。

4.2 SQL语句与函数适配详解

这是改造的核心战场。你需要系统性地扫描和修改应用代码中的SQL。

1. 分页查询：

   • MySQL:SELECT * FROM t ORDER BY id LIMIT 20 OFFSET 40;(或LIMIT 40, 20)
   • DM (兼容Oracle语法):SELECT * FROM (SELECT t.*, ROWNUM rn FROM (SELECT * FROM t ORDER BY id) t WHERE ROWNUM <= 60) WHERE rn > 40;
   • 更优解（DM也支持）：达梦从较新版本开始，也支持LIMIT ... OFFSET ...语法（特别是在MYSQL兼容模式下）。但最保险的做法，是使用MyBatis等ORM框架的分页插件，它们能根据数据库方言自动生成正确的分页SQL。

2. 常用函数替换： 下面这个表格是我整理的部分常见函数映射，能解决80%的问题：

   MySQL 函数/语法	达梦 (DM) 对应方案	说明
   DATE_ADD(col, INTERVAL 1 DAY)	DATEADD(day, 1, col)或col + 1	日期加减
   DATE_FORMAT(col, '%Y-%m-%d')	TO_CHAR(col, 'yyyy-mm-dd')	日期格式化
   IFNULL(expr1, expr2)	NVL(expr1, expr2)	空值处理
   CONCAT(str1, str2, ...)	str1 || str2 || ...或CONCAT(str1, str2)	字符串连接，DM的CONCAT只支持两个参数
   GROUP_CONCAT(col)	WM_CONCAT(col)或LISTAGG(col, ',') WITHIN GROUP(ORDER BY ...)	列转行聚合，LISTAGG是标准SQL，更推荐
   ON DUPLICATE KEY UPDATE ...	MERGE INTO ...语句	实现“存在则更新，不存在则插入”
   `column`(反引号)	"column"或 直接写column	对象名引用，在兼容模式下双引号可用
   AUTO_INCREMENT	IDENTITY(1,1)	自增列定义

3. 存储过程与触发器重写： 这是难度最高的部分。MySQL的存储过程语法（如DELIMITER,DECLARE ... HANDLER）与达梦的PL/SQL风格差异很大。

   • 策略：对于复杂的存储过程，建议重写而非翻译。仔细分析其业务逻辑，用达梦的PL/SQL语法重新实现。达梦的PL/SQL更接近Oracle，结构为CREATE OR REPLACE PROCEDURE ... AS BEGIN ... END;。
   • 工具辅助：DTS可以尝试转换简单的存储过程和触发器，但复杂的基本都会失败。转换日志会给出原始语句和错误信息，这是你重写的起点。
   • 测试：重写后，必须进行严格的单元测试，覆盖所有分支逻辑，确保输入输出与MySQL版本完全一致。

4.3 ORM框架配置调整

以MyBatis为例：

1. 方言（Dialect）：如果你使用了PageHelper等分页插件，需要将方言设置为达梦。可能需要自定义一个Dialect类，或者使用插件社区提供的支持。
2. SQL映射文件：检查所有*.xml文件中的SQL。将其中使用MySQL特有函数或语法的地方，按照上述规则进行替换。可以使用IDE的全局搜索功能，搜索LIMIT,GROUP_CONCAT,DATE_ADD等关键词。
3. 类型处理器（TypeHandler）：如果自定义了针对MySQL特定类型（如TINYINT(1)到Boolean）的TypeHandler，可能需要调整或确保其在达梦下工作正常。

5. 迁移后验证、优化与上线切换

迁移完成不是终点，验证和优化决定了最终的成功率。

5.1 多层次验证策略

1. 数据一致性验证：

   • 数量校验：对比每个表的行数是否一致。SELECT COUNT(*) FROM table;
   • 内容校验：对关键业务表，抽样或全量比对数据。可以编写脚本，对两边的表计算一个校验和（如对所有字段拼接后取MD5），进行对比。达梦也提供了一些数据对比工具。
   • 约束与索引验证：检查主键、唯一约束是否生效，索引是否正常创建。

2. 功能回归测试：

   • 核心业务流程走查：覆盖登录、下单、支付、查询等所有关键路径。
   • 报表与统计功能：这类功能往往涉及复杂的多表关联和聚合查询，最容易出性能问题和结果错误。
   • 后台任务：检查定时任务、批处理作业是否正常运行。

3. 性能与压力测试：

   • 使用迁移前记录的性能基线，对相同场景进行测试，对比响应时间和资源消耗。
   • 进行压力测试，观察达梦数据库在并发场景下的表现（CPU、内存、IO、锁等待）。达梦的监控视图（如V$SYSSTAT,V$SESSION）与Oracle类似，需要学习一下。

5.2 达梦数据库针对性优化

迁移后，性能不如预期是常事，因为两个数据库的优化器、执行计划完全不同。

1. 统计信息收集：数据导入后，达梦的优化器对新表一无所知。必须立即收集统计信息，这是最重要的优化步骤。

   -- 收集单个表的统计信息 DBMS_STATS.GATHER_TABLE_STATS('模式名', '表名'); -- 收集整个模式的统计信息 DBMS_STATS.GATHER_SCHEMA_STATS('模式名');

2. 执行计划分析：对慢SQL，使用达梦的EXPLAIN查看执行计划。

   EXPLAIN SELECT * FROM your_slow_table WHERE ...;

   关注是否有全表扫描（CSCN）、索引是否有效利用（SSEK）。达梦的执行计划格式需要学习，重点关注COST（代价）和OPERATION（操作类型）。

3. 索引优化：根据执行计划分析结果，考虑在达梦上创建新的、更合适的索引。注意，达梦的索引类型（如B树、位图、函数索引）和MySQL有区别，需要根据查询条件设计。

4. 参数调优：根据服务器硬件和业务特点，调整达梦的初始化参数（dm.ini）。常见调整项包括内存相关参数（MEMORY_POOL,BUFFER等）、并发连接数（MAX_SESSIONS）等。修改前务必备份原文件，并在测试环境充分验证。

5.3 上线切换与回滚演练

1. 制定切换检查清单（Checklist）：列出切换前后需要做的每一个动作，如停止应用、修改配置、刷新DNS、重启服务、执行数据最终同步等，并明确负责人和时间点。
2. 进行预演：在准生产环境完整演练整个切换和回滚流程，确保所有人员熟悉步骤，所有脚本运行无误。
3. 正式切换：选择业务影响最小的时段（如深夜），严格按照清单执行。切换后，立即进行核心业务功能的快速验证。
4. 监控与观察期：上线后，进入紧密监控期（如24-48小时）。监控数据库性能指标、应用错误日志、业务指标是否正常。准备好随时应对可能出现的问题。

6. 常见问题与故障排查实录

迁移过程中，你一定会遇到各种报错。这里记录几个我踩过的典型“坑”及其解决方案。

6.1 连接与驱动类问题

• 问题：应用启动时报ClassNotFoundException: dm.jdbc.driver.DmDriver或No suitable driver found。
• 排查：
  1. 检查达梦JDBC驱动JAR包是否已正确放入应用的类路径（如WEB-INF/lib）。
  2. 检查连接字符串是否写错。特别注意端口号（默认5236）和数据库名（默认DAMENG或你创建的实例名）。
  3. 在某些应用服务器中，可能需要显示地加载驱动类。尝试在连接URL前加上jdbc:dm://。
• 解决：确保驱动版本与达梦数据库版本匹配。最好从达梦安装目录的/drivers/jdbc下获取官方驱动。

6.2 SQL语法兼容性问题

• 问题：应用执行SQL时报错，提示“第X行第Y列附近存在语法错误”。
• 排查：
  1. 将出错的SQL语句直接在达梦的DM管理工具或disql中执行，看是否报同样错误。
  2. 仔细检查SQL中是否包含未适配的MySQL特有函数（如FIND_IN_SET,IF函数用作流控制）或语法（如\转义符）。
  3. 检查SQL中的字符串是否使用了单引号（‘），达梦中字符串必须用单引号，双引号用于标识对象名（如表名、列名）。
• 解决：根据错误信息定位具体函数或语法，参照第4.2节的表格进行替换。对于复杂SQL，可以将其拆解，分步调试。

6.3 数据类型与精度问题

• 问题：数据迁移或插入时，报“数值溢出”、“无效的日期”或“字符串截断”错误。
• 排查：
  1. 数值溢出：检查MySQL中INT或DECIMAL的精度和标度是否与达梦映射后的类型一致。例如，MySQL的DECIMAL(10,2)到达梦可能映射为DECIMAL(10,2)，但达梦的数值范围定义可能略有不同。
  2. 日期问题：MySQL的DATETIME范围是 ‘1000-01-01’ 到 ‘9999-12-31’，而达梦的DATETIME类型（或TIMESTAMP）范围可能不同。检查是否有超出范围的日期数据（如‘0000-00-00’这种非法日期）。
  3. 字符串截断：检查VARCHAR的长度定义。虽然都是VARCHAR(255)，但字符集不同，实际能存储的字节数可能不同。特别是包含中文等多字节字符时。
• 解决：在迁移前，利用脚本检查源库中的极值数据。在DTS的类型映射中，可以手动调整目标类型，例如将可能溢出的INT映射为更大的BIGINT。对于非法日期，需要在迁移前进行数据清洗。

6.4 性能问题：迁移后SQL变慢

• 问题：同一个查询，在MySQL上很快，在达梦上却非常慢。
• 排查：
  1. 首要检查统计信息：99%的慢SQL问题源于统计信息缺失或过时。确认是否在数据迁移后执行了GATHER_TABLE_STATS。
  2. 查看执行计划：使用EXPLAIN分析慢SQL，对比MySQL的执行计划（EXPLAIN FORMAT=JSON）。看是否走了全表扫描，索引是否被正确选择。
  3. 索引差异：达梦的索引机制和MySQL的InnoDB不同。检查在达梦上是否创建了与MySQL相同或等效的索引。有时需要为达梦创建额外的复合索引或函数索引。
  4. 参数配置：检查达梦的BUFFER（缓冲区）大小是否设置合理。如果内存设置过小，会导致大量物理IO。
• 解决：收集统计信息是第一步。然后根据执行计划创建缺失的索引。如果涉及复杂查询，可以尝试使用达梦的HINT语法来引导优化器，例如/*+ INDEX(table_name index_name) */。对于参数调优，建议参考达梦官方性能调优手册，从小处开始调整。

迁移完成并稳定运行一周后，我最大的体会是：国产化迁移，技术上的挑战固然存在，但更多是工程管理和细致程度的考验。它不是一个简单的“导出-导入”动作，而是一个涉及评估、改造、测试、验证的系统工程。前期花在梳理、评估和方案设计上的时间，最终都会在后期以更少的故障和更平滑的切换回报给你。达梦数据库在兼容性和工具链上已经做了很多工作，只要你能静下心来，像解谜一样逐个攻克语法、函数、性能这些具体问题，最终的成功就是水到渠成。最后一个小建议，建立一个属于你们项目的“迁移知识库”，把遇到的每一个报错、每一个解决方案都记录下来，这不仅是本次项目的财富，也会成为团队未来面对其他国产化替代任务的宝贵资产。