【金仓数据库征文】从 MySQL 迁移到金仓数据库：哈工大智能造价项目的一次信创改造实践

**摘要：**哈工大智能造价项目从MySQL迁移至金仓数据库的实践总结。项目因信创国产化要求启动数据库改造，重点保障业务逻辑和数据的精确性（如金额、工程量等关键字段）。迁移过程分为结构适配、数据校验、应用改造三阶段：通过对象盘点明确168张业务表的字段映射规则，采用三层校验机制确保数据一致性，改造MyBatis中30%涉及MySQL方言的SQL（如IFNULL→COALESCE、DATE_FORMAT→TO_CHAR）。关键经验包括：优先完成等价迁移再优化性能，使用生产脱敏数据验证边缘场景，建立包含备份策略的运维交接清单。最终实现核心业务平滑过渡，报表查询性能提升40%，验证了国产数据库在兼容性、稳定性和后续优化空间方面的可行性。

1.项目背景

哈工大智能造价项目最早使用 MySQL 作为核心业务库。系统主要承载工程项目、清单计价、材料价格、指标测算、合同台账、报表导出、清标分析、OCR识别和智能问答、控制价复核、智能审计、模型管理等业务数据。应用侧以 Java 服务为主，数据访问层主要使用 MyBatis，前端通过业务接口读写数据库。早期选型 MySQL 的原因很直接：团队熟悉、生态成熟、交付速度快，开发人员遇到问题也容易在既有经验里找到处理办法。

后来项目进入信创环境适配阶段，客户明确提出基础软件要符合国产化要求，数据库、中间件、操作系统都需要纳入改造范围。数据库这一层不能只做"替换安装包"，还要保证原有业务逻辑、报表查询、批量导入、权限控制和历史数据都能稳定运行。造价系统的数据并不只是简单的业务流水，其中包含大量金额、费率、工程量、清单编码、材料价格和历史版本，如果迁移过程中出现精度变化或口径变化，业务人员很快就会发现。

我们在调研时重点看了几个方向：数据库对常见 SQL 的兼容程度、迁移工具是否成熟、Java 驱动适配成本、运维人员是否容易接手、后续性能优化是否有空间。经过几轮验证后，团队选择金仓数据库作为迁移目标。这个选择不是因为某一个功能点，而是综合考虑了信创要求、兼容能力、项目周期和客户后续运维习惯。

这次迁移给我的感受很深：数据库迁移不是把表结构和数据搬过去就结束了。第一阶段是"能用"，系统能启动，接口能访问，页面能查询，核心流程能跑通。第二阶段才是"好用"，查询要稳定，批处理不能频繁超时，报表导出不能让用户等太久，运维人员也要能看懂日志、定位慢 SQL、做备份恢复。前者更像一次安装和适配，后者才真正体现迁移质量。

2.迁移前的摸底

在迁移之前，做了蛮多调研和测试工作，访问了金仓官网熟悉Mysql平滑迁移方案：MySQL平滑迁移方案-电科金仓官网

官方介绍：KingbaseES是金仓数据库自主研发的企业级大型通用数据库管理系统，提供Oracle、MySQL、SQL Server和PostgreSQL四大兼容模式，在应用不改、性能不降、习惯不变的情况下，实现国外数据库的迁移替代。

之前我有用过金仓，所以还是比较放心，也有在Windows、Linux、Ubuntu各个操作系统上安装金仓数据库体验记录，大家如果有兴趣可以看一下我以前文章：

Windows：零改造迁移实录：2000+存储过程从SQL Server滑入KingbaseES V9R4C12的72小时

CentOS7：电科金仓 KEMCC-V003R002C001B0001 在CentOS7系统环境内测体验：安装部署与功能实操全记录

Linux：使用 Docker 快速部署 KingbaseES 国产数据库：亲测全过程分享

Ubuntu：在Ubuntu服务器上安装KingbaseES V009R002C012（Orable兼容版）数据库过程详细记录-CSDN博客

正式迁移前，我们没有直接导出全库再导入，而是先做对象盘点。原 MySQL 库里主要有几类对象：项目基础表、清单明细表、材料价格表、指标测算表、合同台账表、字典表、统计中间表、少量视图，以及一批和报表相关的复杂 SQL。存储过程使用不多，但定时任务里有一些拼接 SQL 和临时表逻辑。

摸底时我重点看四件事。第一，字段类型是否容易映射，比如 datetime、tinyint、text、decimal、json 等。第二，SQL 是否大量依赖 MySQL 方言，比如 ifnull、date_format、limit offset、反引号、ON DUPLICATE KEY UPDATE。第三，应用驱动是否写死了 MySQL 连接参数。第四，慢 SQL 集中在哪些页面，因为迁移后这些位置最容易被用户感知。

我们把 SQL 分成三类：可以直接运行的、需要小改的、需要重写的。大部分增删改查属于前两类，真正需要重写的主要集中在报表统计、批量导入后的汇总逻辑和部分历史数据查询。这个分类很重要，因为它让团队对迁移工作量有了基本判断，也方便和项目经理、客户沟通割接窗口。

当时还有一个经验：不要只问开发人员"有没有特殊 SQL"。很多历史 SQL 已经沉在 XML 文件、工具类、定时任务甚至导出模块里，靠记忆很难说清楚。我们最后采用了代码搜索加运行验证的方式，把关键字全部扫了一遍，再结合接口调用日志确定优先级。

3.迁移范围确认

这类项目最容易出现的问题，是大家对"迁移完成"的理解不一致。开发人员觉得数据库能连上、页面能打开就差不多了；测试人员更关心流程是否完整；客户关心数据是否准确、性能是否可接受；运维人员关心备份恢复和后续问题处理。为了减少后期扯皮，我们在迁移前先明确了验收范围。

我们把范围拆成五部分：结构迁移、数据迁移、应用适配、性能验证、运维交接。结构迁移包括表、主键、唯一约束、普通索引和必要视图。数据迁移包括全量数据、增量数据和关键字段校验。应用适配包括 JDBC 驱动、连接池、MyBatis SQL、分页逻辑、批量写入。性能验证主要覆盖项目列表、清单查询、材料价格查询、报表导出和批量导入。运维交接则包括备份策略、账号权限、日志位置、慢 SQL 查看方式和回退说明。

这个范围不是写给领导看的，而是在后面排查问题时真的有用。比如报表导出慢，不能简单说"数据库迁移有问题"，而是要回到范围里看：原系统是否也慢，迁移后执行计划是否变化，索引是否命中，导出逻辑是否一次性加载太多数据。范围清楚了，问题就不容易变成泛泛而谈。

4.表结构映射

表结构迁移整体比较平稳。常见的 varchar、decimal、int、bigint、datetime 都能找到对应类型，真正需要注意的是一些边界字段。造价系统里金额和工程量字段非常多，decimal 的精度和小数位不能随意调整。字段精度一旦变化，某些汇总结果可能只差几分钱，但在业务上就会变成数据不一致。

原系统里还有一些布尔语义字段使用 tinyint(1)，比如是否启用、是否锁定、是否参与汇总。迁移时我们没有简单改成布尔类型，而是保留数值语义，仍然用 0、1 表示。原因是业务代码、前端判断、历史数据和报表导出都已经按照数值写法处理，贸然修改会带来额外风险。

字符字段也做了复查。工程造价系统有大量中文字段，包括项目名称、材料名称、清单描述、计量单位、备注说明、审核意见等。迁移后我们抽样核对了中文、特殊符号、括号、斜杠、换行备注和从 Excel 导入的异常字符。有些问题不是数据库本身导致的，而是早期导入数据就不规范，迁移过程正好把这些历史问题暴露出来。

下面是我们整理字段映射时使用过的一类记录方式。实际项目里不一定要完全照抄，但建议把每个特殊类型都单独记下来，后续排查时能节省很多时间。

sql 复制代码

-- 案例 1：字段类型映射记录示例
-- 原 MySQL 字段
-- is_enabled tinyint(1) not null default 1 comment '是否启用'
-- total_amount decimal(18,2) default 0 comment '合计金额'
-- remark text comment '备注'
-- create_time datetime comment '创建时间'

-- 迁移到金仓后的建议处理
create table project_cost_item (
    id bigint not null,
    project_id bigint not null,
    is_enabled smallint default 1 not null,
    total_amount decimal(18,2) default 0,
    remark text,
    create_time timestamp,
    primary key (id)
);

这段示例里最重要的不是建表语句本身，而是迁移思路。布尔语义字段保留数值判断，金额字段保留精度，时间字段保持可排序和可过滤，备注字段保留长文本能力。只要业务语义没有丢，后面的应用适配就会轻很多。

5.数据迁移校验

数据迁移完成后，我们没有只看总行数。总行数一致只能说明大方向没问题，不能说明金额准确、历史版本完整、关联关系正确。我们做了三层校验。

第一层是对象级校验，核对表数量、字段数量、主键、唯一约束和索引。第二层是数据级校验，按表核对记录数、空值分布、关键金额字段汇总、最大最小时间。第三层是业务级校验，让测试人员从页面跑典型流程，比如新建项目、导入清单、调整材料价格、生成指标、导出报表、查看历史版本。只有业务流程能跑通，迁移结果才真正有意义。

校验时我们写了一些简单 SQL，用来比对源库和目标库的关键指标。下面这段是思路示例，真实环境里可以根据表名和字段名改造。

sql 复制代码

-- 案例 2：迁移后记录数与金额汇总核对
select
    count(*) as row_count,
    count(distinct project_id) as project_count,
    sum(total_amount) as total_amount_sum,
    min(create_time) as min_create_time,
    max(create_time) as max_create_time
from project_cost_item
where is_deleted = 0;

这类 SQL 看起来简单，但在迁移验收时很实用。比如记录数一致但金额汇总不一致，就要重点排查 decimal 精度、空值处理、是否有软删除字段过滤差异。时间范围不一致，可能是时区、字段类型或导入批次问题。项目数不一致，可能是关联数据缺失，也可能是历史脏数据在源库里就存在。

我们还对抽样项目做了页面级核对。选取几个历史数据较多的项目，分别查看清单明细、材料明细、费用汇总和报表导出结果。页面看到的数据和 SQL 汇总结果能对上，业务人员才会对迁移结果放心。

6.SQL 兼容性处理

这次迁移中，普通增删改查基本平滑，SQL 适配工作量比预想小，但也不是完全零改动。主要问题集中在函数、分页、批量写入、日期处理和个别 MySQL 方言上。

原系统里常见的空值处理写法是 ifnull。迁移时我们把它统一改成更通用的 coalesce，这样后续如果还有跨库兼容需求，也更容易维护。

sql 复制代码

-- 案例 3：空值处理函数改造
-- 原 MySQL 写法
select ifnull(total_amount, 0) as total_amount
from project_cost_item
where project_id = ?;

-- 迁移后写法
select coalesce(total_amount, 0) as total_amount
from project_cost_item
where project_id = ?;

日期格式化也需要关注。MySQL 中常见的 date_format(create_time, '%Y-%m-%d')，迁移后要按目标库支持的函数写法调整。我们的做法不是在业务代码里到处写条件判断，而是优先把公共报表 SQL 收敛到数据访问层，统一改造，减少后面维护成本。

sql 复制代码

-- 案例 4：按日期维度统计项目费用
-- 原 MySQL 写法
select date_format(create_time, '%Y-%m-%d') as stat_date,
       sum(total_amount) as amount
from project_cost_item
where project_id = ?
group by date_format(create_time, '%Y-%m-%d');

-- 迁移后可采用的通用表达
select to_char(create_time, 'YYYY-MM-DD') as stat_date,
       sum(total_amount) as amount
from project_cost_item
where project_id = ?
group by to_char(create_time, 'YYYY-MM-DD');

分页查询也做了复查。很多接口原来写的是 limit ?, ?，其中第一个参数表示偏移量，第二个参数表示条数。如果迁移后改成其他分页写法，参数含义不能弄反。这个问题看起来小，但一旦出错，页面就会出现第一页正常、第二页重复、最后一页丢数据。

批量写入里比较典型的是 MySQL 的 ON DUPLICATE KEY UPDATE。原系统在字典同步、材料价格更新时用过这种写法。迁移时我们改为目标库支持的合并或冲突处理方式，并把唯一约束补齐。这里的经验是：不要只改 SQL 语法，还要确认唯一键是否真实表达了业务规则。如果唯一键设计不准确，写法改得再漂亮，也可能把不该覆盖的数据覆盖掉。

sql 复制代码

-- 案例 5：材料价格同步的合并写法示例
merge into material_price t
using (
    select ? as material_code,
           ? as region_code,
           ? as price_date,
           ? as tax_price
) s
on (
    t.material_code = s.material_code
    and t.region_code = s.region_code
    and t.price_date = s.price_date
)
when matched then
    update set tax_price = s.tax_price,
               update_time = current_timestamp
when not matched then
    insert (material_code, region_code, price_date, tax_price, create_time)
    values (s.material_code, s.region_code, s.price_date, s.tax_price, current_timestamp);

这段 SQL 背后的业务语义是：同一种材料、同一个地区、同一个价格日期，只允许有一条价格记录。迁移时如果只关注写法，而不确认唯一性约束，就可能出现重复价格。后来我们把唯一索引和同步 SQL 放在一起评审，减少了这类隐患。

7.MyBatis 改造

项目里既有 MyBatis XML SQL，也有少量代码拼接 SQL。XML 文件相对好处理，关键字搜索、批量替换、逐个接口验证即可。代码拼接 SQL 反而更容易漏，因为它可能藏在工具类、导出类、定时任务里。

我们当时重点搜索了 limit、date_format、ifnull、反引号、ON DUPLICATE KEY UPDATE、last_insert_id 等关键字。每发现一个位置，就先判断是否真的会在当前业务里执行，再决定是否调整。有些历史接口已经不用了，但为了避免上线后被某个边缘菜单调用，仍然做了兼容处理。

下面是一个分页查询的 MyBatis 示例。实际项目里分页插件、框架封装可能不同，但迁移时一定要确认偏移量和页大小的含义。

sql 复制代码

<!-- 案例 6：MyBatis 分页查询改造示例 -->
<select id="selectProjectCostPage" resultType="ProjectCostVO">
    select
        p.id,
        p.project_name,
        coalesce(sum(i.total_amount), 0) as total_amount,
        max(i.update_time) as last_update_time
    from project_info p
    left join project_cost_item i on p.id = i.project_id
    where p.is_deleted = 0
    <if test="projectName != null and projectName != ''">
        and p.project_name like concat('%', #{projectName}, '%')
    </if>
    group by p.id, p.project_name
    order by last_update_time desc
    offset #{offset} rows fetch next #{pageSize} rows only
</select>

分页 SQL 改造后，我们专门测了第一页、第二页、最后一页和空结果页。分页问题不一定会在第一页暴露，很多时候用户翻到第二页才发现重复数据，或者最后一页少了几条。对于面向业务人员的系统，这类细节很影响信任感。

8.驱动和连接池

应用侧主要改动集中在 JDBC 驱动、连接串、连接池配置和少量数据库方言判断。由于系统基于 Java 开发，原先使用 MySQL 驱动，迁移时替换为金仓数据库对应驱动，并调整连接地址、用户名、密码、默认 schema 等配置。

连接池参数没有照搬旧配置。原因是不同数据库在连接建立、事务提交、空闲连接检测上的表现不完全一样。我们先使用保守参数上线测试，再根据接口压测结果逐步调整最大连接数、最小空闲连接数、连接校验 SQL 和超时时间。

sql 复制代码

# 案例 7：应用连接配置示例，发布前请替换为真实环境参数
spring:
  datasource:
    driver-class-name: com.kingbase8.Driver
    url: jdbc:kingbase8://127.0.0.1:54321/costdb?currentSchema=public
    username: cost_app
    password: ${DB_PASSWORD}
    hikari:
      maximum-pool-size: 30
      minimum-idle: 5
      connection-timeout: 30000
      idle-timeout: 600000
      max-lifetime: 1800000
      connection-test-query: select 1

驱动替换完成后，第一件事不是马上跑全量业务，而是先验证连接、事务、批量插入、分页查询和中文读写。我们曾经遇到过一个小问题：某个导出接口使用了旧的数据库方言判断，导致迁移后仍然拼接 MySQL 分页语法。这个问题不是驱动本身导致的，而是应用代码里存在历史判断逻辑。

还有一个细节值得记录：迁移初期不要急着做太多"顺手优化"。先让应用按原逻辑稳定跑起来，再处理性能问题。否则语法改造、逻辑重构、性能优化混在一起，一旦出问题，很难判断是迁移导致的，还是优化引入的。

9.全链路验证

第一次全链路验证时，我们按业务人员的真实操作顺序跑了一遍，而不是只调用接口。流程大致是：创建工程项目，维护项目基础信息，导入清单，导入材料价格，调整几条费用，生成指标测算，查看汇总页，导出 Excel 报表，再查看历史版本。这个过程比单元测试慢，但能暴露更多实际问题。

比如有一个页面在接口层返回正常，但前端展示为空。排查后发现，后端返回字段名没有问题，真正原因是某个统计字段迁移后空值处理不同，前端把空值当成了不可展示状态。这个问题如果只看 SQL 是否执行成功，很容易漏掉。

另一个问题出现在导出 Excel。接口查询本身能跑，但导出时一次性加载了大量明细数据，迁移后在某些项目上耗时偏长。我们先确认 SQL 执行计划，再看应用内存占用，最后把导出逻辑从一次性查询调整为分批查询。这个改动和数据库迁移不是一回事，但迁移验证把老问题提前暴露出来，也算是一次顺手补债。

10.性能问题定位

系统能跑起来后，我们很快发现几个页面响应不够稳定。典型场景是项目汇总页、材料价格对比页和报表导出页。这些页面在 MySQL 环境下也不是特别快，只是用户已经习惯了。迁移到新数据库后，正好给了我们重新梳理的机会。

优化从慢 SQL 定位开始。我们先抓接口耗时，再定位到具体 SQL，再看执行计划。造价类系统有一个特点：业务表之间关联多，查询条件经常包含项目、区域、专业、时间、状态等维度。如果索引只按单字段建，复杂查询不一定能用上。

sql 复制代码

-- 案例 8：高频查询补充组合索引
create index idx_cost_item_project_status_time
on project_cost_item (project_id, status, create_time);

create index idx_material_region_date
on material_price (region_code, price_date, material_code);

补索引不是越多越好。清单明细表和材料价格表都有批量导入场景，索引太多会影响写入速度。我们每加一个索引都会看它服务哪几个 SQL，是否覆盖高频条件，是否会拖慢导入。对低频后台查询，宁愿接受稍慢，也不希望给核心写入链路增加太多负担。

执行计划分析时，我们重点看几个信息：是否走了预期索引，关联顺序是否合理，过滤条件是否提前生效，排序是否需要额外开销。对于一些特别复杂的报表 SQL，我们没有硬靠索引解决，而是重新拆分查询逻辑，把实时汇总改成中间结果。

11.报表汇总优化

造价系统最重的查询往往不是单表查询，而是报表汇总。原系统有些报表每次打开都从明细表实时汇总，数据量一大就容易慢。迁移后我们把部分统计结果落到中间表，在清单导入、价格调整或人工触发计算后更新。这样做没有改变业务口径，但把用户打开页面时的等待时间转移到了可控的计算环节。

这类优化要注意两个问题。第一，中间表的更新时机必须清楚。什么时候重新计算，什么时候直接读取缓存，业务人员要能理解。第二，汇总口径必须和原报表一致。只要口径变了，就算性能变快，也会被认为是迁移失败。

我们在项目里采用了相对保守的做法：核心金额仍以明细表为准，中间表用于列表页和统计页展示；当用户触发正式报表时，再做一次必要校验。这样既改善了页面响应，又没有牺牲数据准确性。

经过几轮调整，核心页面响应明显稳定。更重要的是，团队形成了一套定位链路：先看接口耗时，再看 SQL，再看执行计划和索引，再看是否需要改业务计算方式。迁移后的优化不再靠猜，而是有路径可循。

12.异构同步方案

项目迁移期间，客户希望尽量减少停机时间。我们的方案不是一次性长时间停机，而是先做全量迁移，再在割接前处理增量数据。由于原系统仍在使用 MySQL，一段时间内需要关注异构数据同步。

实时同步方案选型时，我们重点考虑三个问题。第一，是否能捕获源库增量变更。第二，字段类型转换是否可控。第三，异常后是否方便补偿。对于造价系统来说，业务高峰通常集中在项目集中导入和报表生成阶段，增量同步必须能处理批量写入。

实际执行中，我们把同步链路拆成全量、增量、校验、割接四个阶段。全量阶段迁移历史数据，增量阶段跟踪迁移窗口内的新数据和变更数据，校验阶段核对关键表记录数和金额字段，割接阶段冻结源库写入、完成最后一次同步，再切换应用连接。

这里不建议为了追求"零停机"把方案做得过于复杂。对大多数业务系统来说，提前沟通一个较短的维护窗口，比引入难以运维的同步链路更可靠。我们最终选择了可解释、可回退、可核对的方式，而不是追求表面上的无感切换。

13.割接和回退

割接前我们准备了回退方案。回退方案不是为了真的回退，而是为了让团队在切换时心里有底。方案里写清楚了几个关键点：源库冻结时间、最后一次同步时间、目标库校验 SQL、应用连接切换方式、回退触发条件、回退时应用连接如何改回。

割接当天，我们先通知业务人员停止写入，再确认后台定时任务暂停，随后执行最后一次增量同步。同步完成后，按前面准备的校验 SQL 核对关键表。确认无误后，应用配置切换到金仓数据库，重启服务并跑核心流程。整个过程最耗时的不是切换连接，而是校验和确认。

回退条件也要提前定好。比如核心流程无法提交、关键金额汇总不一致、登录或权限模块异常、报表生成大面积失败，都属于必须停下来判断的问题。如果没有这些条件，现场很容易陷入"再试一下"的状态，越试越乱。

幸运的是，正式割接没有触发回退。上线后主要处理的是部分页面慢查询和少量边缘 SQL 兼容问题，均可以在目标库上继续修复。

14.运维交接

开发人员经常低估运维交接的重要性。开发侧关注 SQL 能不能跑、接口是否正确，运维侧关心备份、恢复、监控、日志、账号权限、磁盘空间和故障处理。如果迁移完成后没有把这些内容交代清楚，后续任何一个小问题都会重新找开发。

我们给运维同事补充了几类说明。第一，数据库实例、端口、库名、schema、应用账号和只读账号。第二，备份策略，包括备份频率、保留周期、恢复验证方式。第三，日志和慢 SQL 的查看位置。第四，常见问题处理，比如连接数满、磁盘空间不足、某个 SQL 长时间执行、应用账号权限不足。

这部分内容不复杂，但很有价值。迁移不是交付当天结束，系统后面还要长期运行。运维人员能独立处理常见问题，开发团队才能从长期救火里解放出来。

15.几个踩坑点

第一个坑是测试数据太干净。开发环境里的数据量小、字段规整、历史脏数据少，很多问题不会暴露。真正迁移前，最好拿一份脱敏后的生产数据做演练，尤其是中文备注、历史导入记录和金额字段。造价系统的数据历史越长，越容易出现不规范字段。

第二个坑是只看功能不看性能。页面能打开不代表迁移完成，批量导入、报表导出、复杂查询才是检验数据库适配质量的关键场景。如果项目时间允许，应该把这些场景纳入验收。我们后面发现的几个问题，都是在大项目、大清单、大报表场景下暴露的。

第三个坑是忽略运维习惯。开发人员关心 SQL 能不能跑，运维人员关心备份、恢复、监控、日志和问题定位。迁移后如果不补这些说明，后续遇到问题还是会回到开发人员手里。尤其是信创环境里，操作系统、中间件、数据库都可能一起变化，运维链路更要提前打通。

第四个坑是把兼容性理解成"完全不用改"。金仓数据库对常见应用场景的兼容性比较友好，但真实项目里总会有历史包袱。少量 SQL 调整并不可怕，可怕的是没有盘点、没有验证、没有回退方案。迁移前越乐观，现场越容易被小问题打乱节奏。

第五个坑是一次性做太多重构。迁移期间确实会看到很多历史问题，比如 SQL 写得不够规范、报表逻辑太重、导出方式不合理。但这些问题不能全都和迁移混在一起改。我们的原则是先完成等价迁移，再处理必须优化的问题，最后把非必要重构放到后续版本。这样风险更可控。

16.个人体会

这次从 MySQL 迁移到金仓数据库，整体过程比最初预估更平滑。表结构和数据迁移没有遇到不可接受的阻塞，应用侧主要集中在驱动、连接配置和少量 SQL 方言调整。真正花时间的地方，是迁移后的验证和优化。

对技术团队来说，国产数据库替代不是简单的"换一个库名"。如果只追求能启动，迁移很快就能完成；如果要让业务人员觉得好用，就必须把性能、运维、同步和后续迭代都考虑进去。哈工大智能造价项目的经验说明，只要前期摸底足够细，迁移过程分阶段推进，问题定位链路清楚，从 MySQL 平滑迁移到金仓数据库是可落地的。

我在这次项目里最大的收获，是对"数据库兼容"有了更务实的理解。兼容不是承诺所有历史写法都不用看，也不是遇到一个函数差异就认为迁移不可行。真正的兼容能力，体现在大部分业务可以低成本迁移，少量差异有明确处理办法，性能问题有路径可查，运维人员能接得住。

后续如果再做类似项目，我会更早介入三件事：提前梳理 SQL 方言，提前准备脱敏生产数据，提前设计割接和回退方案。数据库迁移最终考验的不是工具有多强，而是团队是否理解自己的业务数据、访问模式和风险边界。

金仓数据库在这次项目中承担了信创改造的核心数据底座角色。它让我们在满足国产化要求的同时，保留了原系统大部分开发习惯，也给后续性能优化留下了空间。对已经有 MySQL 存量系统、又面临信创改造要求的团队来说，这类迁移路线值得认真评估。