KingbaseES 数据库 MySQL 兼容性解析与自动化迁移方案

像 FOUND_ROWS() 这种 MySQL 特有的函数，KingbaseES 也能做到完全兼容，迁移后直接执行 SELECT FOUND_ROWS(); 就能得到和 MySQL 一致的结果。

值得一提的是，KingbaseES 对 MySQL 语法的兼容并非简单的文本替换，而是其解析器能直接识别并理解 MySQL 的语法树，这从根本上保证了兼容的稳定性。

在函数兼容层面，我们做了全维度的适配验证：

有个客户的业务系统里大量用到了 JSON_EXTRACT、JSON_ARRAYAGG 等 MySQL JSON 函数，原本还担心迁移要改大量代码，结果迁移到 KingbaseES 后，20 万行的业务代码一行没改就直接运行，而且 JSON 相关查询的性能还提升了近 50%，这也印证了我们函数兼容的实际效果。

SELECT user_id, user_name, COUNT(*) FROM orders GROUP BY user_id;

MySQL 的日期自动转换

SELECT * FROM logs WHERE create_time > '2023-01-01'; -- 字符串自动转日期

MySQL 的零日期处理

INSERT INTO users (birthday) VALUES('0000-00-00'); -- 特殊零日期

KingbaseES 通过模拟引擎确保这些 MySQL 特有的东西得到完整保留。

2.2 存储引擎

数据类型的兼容，像下面这条语句，MySQL 的 TINYINT(1) 布尔类型

CREATE TABLE users ( id INT PRIMARY KEY, is_active TINYINT(1), created_at DATETIME DEFAULT CURRENT_TIMESTAMP);

2.3 事务模型

MySQL 的默认隔离级别 REPEATABLE READ 有其特有的行为特征。KingbaseES 通过'隔离级别模拟器'，确保事务行为完全一致。

MySQL 特有的间隙锁行为，确保锁定范围与 MySQL 完全一致。

SELECT * FROM users WHERE age > 25 FOR UPDATE;

在保证兼容性的同时，又对 KingbaseES 对锁机制进行了优化。

根据数据访问模式自动调整，同时比 MySQL 快 5 倍的死锁检测算法，并且可配置的精细化超时策略。

第三章：迁移工具链 KDTS+KFS

3.1 KDTS

从 TB 到 PB 的'秒级'体验，KDTS 的核心优势在于其并行处理架构。

KDTS 全量迁移，示例

kdts-full-migration --source mysql://user:pass@source-host:3306/source_db \
--target kingbasees://user:pass@target-host:54321/target_db \
--parallel 16 --batch-size 10000 --verify checksum

性能对比

KDTS 的增量同步基于 MySQL binlog 解析，实现实时同步。

启动增量同步

kdts-incremental-sync --source mysql://user:pass@source-host:3306/source_db \
--target kingbasees://user:pass@target-host:54321/target_db \
--start-position mysql-bin.000001:4 --heartbeat-interval 1s --conflict-resolution timestamp

3.2 KFS

KFS 工具的结构迁移能力，核心亮点在于能自动识别源端数据库的结构变更，并实时同步到目标端，不用人工逐表核对、修改，大幅降低了结构迁移的工作量和出错概率。

实际使用时，我们可以通过 KFS 的结构同步命令快速完成 MySQL 到 KingbaseES 的表结构迁移，比如这段常用的执行命令：

kfs-schema-sync --source mysql://user:pass@source-host:3306/source_db \
--target kingbasees://user:pass@target-host:54321/target_db \
--include-table 'user*,order*' --exclude-table 'temp*,log*' \
--sync-indexes --sync-constraints

这条命令可以精准指定要同步的源库和目标库，还能通过通配符灵活筛选需要同步的表（比如只同步 user、order 开头的表），排除临时表、日志表这类无需迁移的表，同时同步索引和约束，一步到位完成核心结构迁移。

另外，考虑到很多 DBA 习惯了 MySQL 的参数配置逻辑，KFS 也做了贴心的参数映射适配，避免大家重新学习新参数体系，核心参数的对应关系如下：

3.3 数据一致性验证

多维度进行验证，有一个专门的数据一致性验证工具 KVS。

全量数据校验

kvs-full-verify --source mysql://user:pass@source-host:3306/source_db \
--target kingbasees://user:pass@target-host:54321/target_db \
--tables 'users,orders,products' --algorithm checksum --parallel 8

增量数据校验

kvs-incremental-verify --since '2023-01-01 00:00:00' \
--tables 'orders,order_items' --real-time

第四章：全流程实测

4.1 环境准备

它提供了'傻瓜式'安装包，支持主流操作系统，一键初始化脚本。

kingbasees-init --mode mysql-compatible --port 54321

迁移前评估脚本

kb-migration-assessment --source mysql://root:pass@localhost:3306/testdb --generate-report

4.2 迁移执行

为了简化 MySQL 到 KingbaseES 的迁移流程，我们提供了可直接复用的一键迁移脚本，把全量迁移、增量同步、一致性验证三个核心步骤整合到一起，无需手动分步执行，极大提升迁移效率。

以下是完整的迁移脚本示例（命名为 mysql2kingbasees.sh）：

#!/bin/bash
# mysql2kingbasees.sh：MySQL 到 KingbaseES 一键迁移脚本
# 1. 全量数据迁移（开启 8 线程并行，迁移后校验数据校验和）
echo "开始全量迁移..."
kdts-full-migration \
--source mysql://root:pass@localhost:3306/sourcedb \
--target kingbasees://system:pass@localhost:54321/targetdb \
--parallel 8 --verify checksum

# 2. 增量数据实时同步（全量迁移完成后，同步新增/变更数据）
echo "启动增量同步..."
kdts-incremental-sync \
--source mysql://root:pass@localhost:3306/sourcedb \
--target kingbasees://system:pass@localhost:54321/targetdb \
--sync-mode real-time

# 3. 全量数据一致性验证（4 线程并行校验，确保源端和目标端数据一致）
echo "验证数据一致性..."
kvs-full-verify \
--source mysql://root:pass@localhost:3306/sourcedb \
--target kingbasees://system:pass@localhost:54321/targetdb \
--parallel 4
echo "迁移完成！"

这个脚本把迁移全流程标准化，执行时只需要替换源库、目标库的连接信息，就能自动完成全量迁移、实时增量同步和数据一致性校验，既避免了手动操作的疏漏，也让迁移过程可追溯、可复现。

4.3 验证

数据库迁移操作完成后，无需人工手动核对各项迁移指标，系统会自动生成一份详细的迁移验证报告，清晰呈现迁移全过程的核心信息和验证结果，方便技术人员快速确认迁移成效、判断是否可进行业务切换。

以下是一份实际迁移场景中的验证报告示例，内容直观易懂，关键信息一目了然：

迁移验证报告
=============
迁移时间：25 分钟
数据量：800GB
表数量：150 张
索引数量：300 个
存储过程：25 个
一致性检查：✓
行数校验：100% 通过
校验和校验：100% 通过
业务验证：100% 通过
结论：迁移成功，可以切换！

这份自动生成的报告，把迁移耗时、数据规模（数据量、表、索引、存储过程数量）都清晰列明，同时从行数、校验和、业务三个核心维度，完成了全量一致性检查，所有项目均 100% 通过，最终明确给出'迁移成功，可以切换'的结论，既省去了人工统计核对的繁琐，也为业务切换提供了明确、可靠的依据，避免了迁移后因数据不一致引发的业务风险。

第五章：效率对比数据

时间效率提升是基于 100 个真实迁移项目的数据统计。

迁移效率对比图

人力成本节省 = (传统人月 - 自动化人月) × 人月成本

停机时间对比 图

查询性能图，下面的话是基于 TPC-H 基准测试

写入性能图，这个是基于 sysbench 测试，oltp_write_only 场景

第六章：工具链使用

6.1 环境

安装

./install.sh --mode quick-install --port 54321

以下是迁移的全流程：

# 1. 创建迁移任务
kb-migration-create --name my-first-migration \
--source mysql://root:pass@localhost:3306/testdb \
--target kingbasees://system:pass@localhost:54321/targetdb

# 2. 执行迁移前评估
kb-migration-assess --name my-first-migration

# 3. 执行迁移
kb-migration-run --name my-first-migration

# 4. 验证结果
kb-migration-verify --name my-first-migration

6.2 更灵活的自定义迁移配置

实际做数据库迁移时，不同项目的需求差异很大——有的只需要迁移特定表，有的要自定义函数转换规则，还有的要优先保证性能。针对这些个性化需求，我们可以通过编写 YAML 配置文件来实现自定义迁移，不用再依赖固定的默认流程。

分享一个实用的配置示例（命名为 migration-config.yaml），里面能清晰定义迁移名称、源库/目标库信息，还能按表、函数、冲突处理、性能优化等维度设置规则：

# migration-config.yaml：自定义迁移规则配置
migration:
  name: "custom-migration" # 给本次迁移起个标识名，方便后续管理
  source:
    type: "mysql"
    connection: "mysql://user:pass@host:3306/db" # 源 MySQL 库连接信息
  target:
    type: "kingbasees"
    connection: "kingbasees://user:pass@host:54321/db" # 目标 KingbaseES 库连接信息
  rules:
    # 表筛选规则：只迁 user/order 开头的表，排除临时表、日志表
    - type: "table"
      include: ["user*", "order*"]
      exclude: ["temp*", "log*"]
    # 函数转换规则：用预设的 mysql_to_kb_function 规则转换函数
    - type: "function"
      convert: "mysql_to_kb_function"
    # 冲突处理：遇到数据冲突时，优先以源库数据为准
    - type: "conflict"
      resolution: "source_priority"
    # 性能优化：开启激进模式，优先保证迁移速度
    - type: "performance"
      optimization: "aggressive"

6.3 迁移过程中常见问题的解决办法

迁移时最头疼的就是各种小问题，比如连不上库、网络不通、数据不一致，我们也准备了对应的工具命令，不用手动排查，一键就能搞定：

1. 先测连通性（最基础也最关键）

迁移前先确认源库和目标库能正常连接，避免迁移到一半卡壳，执行这条命令就行：

kb-test-connection --source mysql://user:pass@host:3306/db --target kingbasees://user:pass@host:54321/db

2. 网络不通？一键诊断

如果连接测试失败，大概率是网络问题，用这个命令诊断源/目标主机的网络和端口，能快速定位问题：

kb-network-diagnose --source-host source-host --target-host target-host --port 54321

3. 数据不一致？分析 + 自动修复

迁移后发现数据对不上不用慌，先执行分析命令，按行级维度找出差异点：

kb-difference-analyze --migration-name my-migration --analyze-level row

找到差异后，直接用自动修复命令，按'源库优先'的策略修复，不用手动改数据：

kb-auto-fix --migration-name my-migration --fix-strategy source_priority

自定义迁移可通过 YAML 配置文件，灵活设置表筛选、函数转换、冲突处理等规则，适配不同项目需求 迁移前用 kb-test-connection 测连通性、kb-network-diagnose 查网络，提前规避基础问题 数据不一致时，可通过 kb-difference-analyze 分析差异、kb-auto-fix 自动修复，降低人工排查成本

总结

数据库迁移从来都不是简单的技术替换，而是企业数字化转型的关键一步。KingbaseES 的 MySQL 兼容性和迁移工具链，之所以能在众多方案中脱颖而出，正是因为它真正理解了企业的痛点：不是不想换，而是怕换不好；不是在乎授权费，而是担心隐性成本；不是技术不够，而是风险太大。从 TCO 到工具链的体验，从测试案例的'零差错'验证，到效率数据的'硬核'证明，KingbaseES 用实际行动证明：国产数据库不仅能'用'，更能'好用'；不仅能'替'，更能'优替'。

本文基于 KingbaseES V9 版本及 KDTS/KFS 工具链测试数据编写。