MySQL迁移到国产数据库实战指南(以金仓为例)

说起来这事儿，我是真被问过太多次了——“MySQL换国产数据库难不难？”。说实话，这事儿比换Oracle简单多了，但也不是改个连接地址就能完事儿的。我去年带团队搬过一个中型电商的数据库，MySQL切到金仓KingbaseES，花了两周多，踩了不少坑。今天就把真正干活儿要用的东西讲清楚，少走弯路。

先搞清楚：金仓是什么定位

很多人第一次接触金仓会有个疑问：这数据库跟MySQL差得多吗？实际上，金仓KingbaseES是国产数据库里对MySQL兼容做得比较成熟的一款。它默认端口是3306，跟MySQL一样，支持MySQL的协议和大部分语法。对应用来说，确实可以"只改连接串"直接跑起来。但注意，只是"可以"，不代表所有SQL都不用动——真正迁移过的人都知道，坑往往藏在那些"看起来一样"的地方。

所以迁移前心态要放正：金仓是一个独立的数据库产品，不是MySQL的马甲，它有自己的语法规范和行为逻辑，只是对MySQL做了大量兼容适配。想清楚这一点，后面的迁移思路才不会跑偏。

迁移工具：金仓给你备了一套

金仓官方有完整的迁移工具链，实际项目里主要用这三个：

• KDMS：负责结构迁移，扫描MySQL里的表、索引、存储过程，生成金仓兼容的DDL脚本，还会给出一份兼容性报告，告诉你哪些地方要手动改。
• KDTS：负责数据迁移，全量迁移一把梭，支持断点续传。
• KFS（Kingbase FlySync）：负责增量同步，实时捕获MySQL的binlog，追到最后一刻再做切换。

实际项目里建议用KDMS先扫一遍，把不兼容的语法点列出来，再动手改，不要闷头直接上。

动手迁移前的评估：这一步别省

正式迁移前，先用KDMS连上源MySQL，做一个完整的兼容性评估。报告里重点关注这几类问题：

数据类型差异。MySQL的TINYINT(1)在金仓会被识别为布尔类型，TRUE/FALSE而不是0/1，这个差异会直接影响Java代码里的判空逻辑。DATETIME和TIMESTAMP的处理也不太一样，建议迁移后重点跑一遍涉及时间字段的查询。

字符串处理差异。MySQL里双引号""默认是字符串，但金仓在标准模式下会把双引号当作标识符引用，跟MySQL的行为相反。解决这个问题有两种方式：要么在应用代码里统一用单引号表示字符串；要么在金仓端开启兼容模式。我更建议前者，改代码更彻底。

标识符大小写。MySQL默认大小写不敏感，而金仓默认是敏感的。如果表名、字段名在MySQL里用的是驼峰命名，迁移后查询要小心，大小写不匹配会直接报"列不存在"。可以在建库时指定enable_ci = on来解决这个问题，但更推荐的做法是——迁移前把字段名统一成小写+下划线格式。

语法差异：高频踩坑点

下面这些是我实际迁移中遇到频率最高的差异，不是"理论上可能有问题"，是真的改过线报过错的：

自增主键。MySQL的AUTO_INCREMENT在金仓里要换成序列（SERIAL），或者用兼容模式下的自增语法。

-- MySQL
CREATE TABLE orders (
    order_id INT AUTO_INCREMENT PRIMARY KEY,
    total_amount DECIMAL(10,2)
);

-- 金仓（兼容MySQL模式也可以直接写AUTO_INCREMENT，但更规范的是用SERIAL）
CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    total_amount DECIMAL(10,2)
);

字段类型修改。MySQL用MODIFY COLUMN，金仓用ALTER COLUMN ... TYPE。

-- MySQL
ALTER TABLE user MODIFY COLUMN username VARCHAR(100);

-- 金仓
ALTER TABLE user ALTER COLUMN username TYPE VARCHAR(100);

空字符串。金仓默认把空字符串''当作NULL来处理，这会导致WHERE parent_id = ''这种查询直接查不到数据。在kingbase.conf里可以改ora_input_emptystr_isnull=off，但更好的做法是提前清洗数据，把业务层面的空值统一处理。

隐式类型转换。MySQL对类型比较宽松，WHERE user_id = 12345（字符串字段配整数）能跑，金仓会直接报错。需要在应用代码里补上显式转换：

WHERE user_id = '12345'  -- 或者
WHERE user_id = CAST(12345 AS VARCHAR)

日期函数。MySQL里DATE_FORMAT(now(), '%Y-%m-%d')在金仓标准语法下要换成TO_CHAR(now(), 'YYYY-MM-DD')。不过金仓MySQL兼容版也支持DATE_FORMAT，但注意格式符有差异，迁移后最好跑一轮时间相关的测试用例。另外，INTERVAL 1 DAY的写法也有细微差异，金仓需要INTERVAL '1' DAY（加引号）。

-- MySQL
SELECT DATE_SUB(CURDATE(), INTERVAL 1 MONTH);

-- 金仓（MySQL兼容版）
SELECT DATE_SUB(CURDATE(), INTERVAL '1' MONTH);

Upsert语法。MySQL的REPLACE INTO和INSERT ON DUPLICATE KEY UPDATE在金仓里要用MERGE INTO替代，这个改法我一开始也绕了一下：

-- MySQL
REPLACE INTO device_status (device_id, status) VALUES (1001, 'online');

-- 金仓
MERGE INTO device_status AS t
USING (VALUES (1001, 'online')) AS s(device_id, status)
ON t.device_id = s.device_id
WHEN MATCHED THEN UPDATE SET t.status = s.status
WHEN NOT MATCHED THEN INSERT (device_id, status) VALUES (s.device_id, s.status);

GROUP BY严格模式。MySQL在非ONLY_FULL_GROUP_BY模式下，SELECT列表里可以写非聚合列，金仓默认不允许。关掉这个限制可以改配置：

ALTER SYSTEM SET sql_mode = '';
SELECT sys_reload_conf();

但我建议还是老老实实改SQL，把SELECT里的非聚合列加到GROUP BY里，或者用聚合函数包起来，这是更规范的做法。

数据迁移：实操细节

全量迁移用KDTS，配置好源端和目标端连接串之后，执行迁移任务。对于大表（比如订单表超过50GB的），建议先按时间字段做分区，金仓对分区表的性能优化比全量大表好很多：

-- 在金仓端按时间分区
CREATE TABLE orders (
    order_id BIGINT,
    create_time TIMESTAMP,
    amount DECIMAL(10,2)
) PARTITION BY RANGE (create_time);

CREATE TABLE orders_2024_01 PARTITION OF orders
    FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');

迁移完成后，用行数校验和MD5校验双重确认数据一致性。KDTS自带比对功能，但最好自己也写一个轻量脚本跑一遍核心表。

增量切换阶段，用KFS实时同步binlog，切换前再追一次增量，确认两边数据一致再切。

迁移后别忘了：性能调优

迁过去能跑只是第一步，性能不掉才是及格线。金仓的参数和MySQL差异很大，shared_buffers（相当于MySQL的innodb_buffer_pool_size）默认128MB，上来就要根据服务器内存调高，否则查询会卡在磁盘IO上。

还有个容易忽视的问题——执行计划差异。同一句SQL在MySQL和金仓上的执行计划可能完全不同，尤其是多表JOIN和含OR条件的查询。一定要在金仓上跑一遍EXPLAIN ANALYZE，检查有没有全表扫描、嵌套循环等性能杀手。

写在最后

说了这么多，并不是要吓唬你。MySQL到金仓的迁移，工程量确实比Oracle到金仓小很多，大多数CRUD应用改动量有限。关键是前期评估要做扎实，语法差异要逐条过，不要心存侥幸。切完之后双轨并行跑一段时间，用真实业务流量来验证，比任何测试用例都有说服力。

国产化是大趋势，早动手、早踩坑、早积累经验。等大家都迁移完了，你就是团队里最懂的那个人了。

以上就是MySQL迁移到国产数据库实战指南(以金仓为例)的详细内容，更多关于MySQL迁移到国产数据库的资料请关注脚本之家其它相关文章！

最新评论