MySQL 迁移中的隐形深坑：JSON、事务与 Group By 兼容性陷阱

但有些数据库，同样的 SQL 会直接抛异常，说路径不存在。这导致应用里那些用来判断"某个属性是否存在"的逻辑全部失效。

还有 JSON 函数的行为差异，比如聚合函数：

SELECT JSON_ARRAYAGG(attributes->>'$.color')
FROM products;

MySQL 里，如果没有数据，JSON_ARRAYAGG 返回的是空数组 []。但有的数据库返回的是 NULL。这导致很多用"是否为空数组"来判断是否有数据的逻辑全部出错。

事务隔离级别：并发场景下的隐形杀手

MySQL 的默认隔离级别是 Repeatable Read（RR），但它的实现机制和其他数据库完全不同。MySQL 的 RR 是靠 MVCC（多版本并发控制）加上 Next-Key Lock（临键锁）来实现的，特别擅长防止幻读。

我见过一个高并发场景的坑，某电商的秒杀活动，库存扣减的代码是这样的：

-- 会话 A：用户 A 下单
BEGIN;
SELECT stock FROM goods WHERE id = 1001 FOR UPDATE;
UPDATE goods SET stock = stock - 1 WHERE id = 1001;
COMMIT;

在 MySQL 里，如果有两个用户同时下单，第二个用户的 SELECT FOR UPDATE 会被阻塞，等第一个用户提交后才能执行，这样库存肯定不会超卖。

但迁移到某些数据库后，同样的高并发场景，第二个用户的 SELECT 根本不阻塞，两个用户同时读到了 stock=100，然后都执行减 1 操作，结果变成了 98，超卖了 2 单。

这问题的根源就在于，不同数据库的锁机制实现差异太大。MySQL 在 RR 级别下，范围查询会加间隙锁，防止在范围内插入新记录（这就是防幻读的核心）。但有些数据库在 RR 级别下根本没有间隙锁，或者锁的粒度不一样，高并发场景下行为完全不同。

还有一个更隐蔽的问题，就是 MVCC 的快照读机制不同。MySQL 的 RR 级别下，一个事务里的多次 SELECT，看到的是同一个快照。但有些数据库的 RR 级别，实际上更接近 Snapshot Isolation（快照隔离），在某些特定场景下会出现"写偏斜"（Write Skew）异常，导致数据不一致。

我见过一个金融系统的案例，账户转账的逻辑是这样的：

-- 事务 A：从账户 1 转 100 到账户 2
BEGIN;
SELECT balance FROM accounts WHERE id = 1; -- 读到 1000
-- 中间有其他操作，耗时较长
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

在 MySQL 的 RR 级别下，即使中间有其他事务修改了账户 2 的余额，事务 A 看到的永远是它开始时的快照。但迁移到某些数据库后，事务 A 中间可能看到账户 2 的最新余额，导致转账逻辑出错。

Group By 严格模式：看似简单的语法陷阱

MySQL 有个很出名的参数叫 sql_mode，其中有个 ONLY_FULL_GROUP_BY 模式特别让人头疼。

在 MySQL 5.7 之前，默认是不开启这个模式的，允许写出这样的 SQL：

SELECT order_id, customer_name, SUM(amount)
FROM orders GROUP BY order_id;

虽然 customer_name 既不在 GROUP BY 里，也没有用聚合函数，但 MySQL 会偷偷返回该分组里某一行的 customer_name。这种行为不符合 SQL 标准，但很多历史系统都是这么写的。

但升级到 MySQL 8.0 后，ONLY_FULL_GROUP_BY 默认开启，这种 SQL 直接报错：

ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'customer_name' which is not functionally dependent on columns in GROUP BY clause 

这还不是最坑的，最坑的是迁移的时候。如果目标数据库严格遵循 SQL 标准，那些在 MySQL 宽松模式下跑得好好的 SQL，到了新库直接全部报错。

我见过一个真实的项目，某企业的报表系统有上千个 SQL，都是这种不规范写法。迁移的时候一测试，90% 以上的报表都跑不了，开发团队花了两个月时间，逐个 SQL 去改，要么把非分组列加到 GROUP BY 里，要么用聚合函数包裹。

更麻烦的是，有些 SQL 的逻辑本身就依赖于"返回分组内某一行"的行为，你把它改成标准 SQL，业务逻辑都变了。比如有个 SQL 是"查询每个客户的最新订单"，原来的写法是：

SELECT customer_id, order_id, order_date FROM orders GROUP BY customer_id;

MySQL 会返回每个 customer_id 对应的某一行 order 记录（通常是物理存储的第一行）。虽然不符合标准，但业务逻辑确实是依赖这个行为的。你把它改成标准 SQL，要么用子查询，要么用窗口函数，结果就可能不一样。

其他隐性坑：细节中的魔鬼

除了上面三个大坑，还有很多细节上的差异，单看都不是问题，但积累起来就是灾难。

比如字符串比较的大小写敏感问题。MySQL 默认的字符集 utf8mb4_general_ci 是大小写不敏感的，所以 WHERE name = 'abc' 能匹配到'ABC'。但有些数据库默认是大小写敏感的，同样的 SQL 就匹配不到。

还有日期时间函数的行为差异。MySQL 的 NOW() 函数返回的是当前会话的开始时间，在整个事务里保持不变。但有些数据库的 NOW() 每次调用都可能返回不同的值，导致事务内的逻辑出错。

还有 NULL 的处理差异。MySQL 里，NULL = NULL 的结果是 NULL（不是 TRUE 也不是 FALSE），所以 WHERE col = NULL 永远匹配不到任何记录。但有些数据库的行为可能不同，导致查询结果异常。

更可怕的是，这些差异都不是语法错误，SQL 能正常执行，但结果就是不对。这种问题最难排查，因为你不会怀疑是数据库的问题，只会怀疑是业务逻辑的问题，然后在代码里翻来覆去找 Bug，最后才发现是数据库行为差异导致的。

数据库的破解之道：内核级深度兼容

聊了这么多坑，那到底怎么解决呢？传统的做法无非就是改代码——改 JSON 查询的逻辑，改事务隔离级别的设置，改 Group By 的 SQL 写法。但这样做成本高、风险大，而且改来改去可能还会引入新的 Bug。

一种可行的方案是走不一样的路——不是让应用去适配数据库，而是让数据库去适配应用。从内核层面实现 MySQL 的深度兼容，让应用感觉像还在用 MySQL 一样。

深度兼容内核：不是翻译，而是复刻

核心思想是，在数据库内核里实现一个 MySQL 兼容层，这个兼容层不是简单地做语法翻译，而是从 SQL 解析、执行计划生成、锁机制、MVCC 等各个层面，完全复刻 MySQL 的行为。

具体来说，在内核里做了这几件事：

第一，内置了 MySQL 的 SQL 解析器。当检测到客户端使用的是 MySQL 协议，或者 SQL 语法符合 MySQL 风格时，内核会调用 MySQL 解析器来解析 SQL，生成的语法树和 MySQL 完全一致。

第二，实现了 MySQL 的执行计划生成逻辑。MySQL 的优化器在处理某些 SQL 时，会生成特定的执行计划，兼容层的优化器会复刻这些逻辑，确保执行计划和 MySQL 一样。

第三，模拟了 MySQL 的锁机制。特别是在 RR 隔离级别下，实现了 Next-Key Lock（临键锁）机制，包括记录锁、间隙锁，锁的粒度和时机都和 MySQL 保持一致。

第四，对齐了 MySQL 的 MVCC 快照读机制。确保事务内的多次 SELECT 看到的是同一个快照，避免出现写偏斜等异常。

这样的内核级兼容，好处是显而易见的——应用不需要改任何代码，所有的 SQL 都能按照 MySQL 的逻辑执行，结果也和 MySQL 完全一致。

JSON 专项优化：行为级 1:1 对齐

针对 JSON 数据类型的兼容问题，做了专项优化，从存储格式、函数行为、索引机制等各个方面，确保和 MySQL 完全一致。

首先是存储格式。支持 MySQL 的 JSON 类型，并且在内部存储上做了优化，采用二进制格式存储，解析效率更高，但对外暴露的行为和 MySQL 的 JSON 完全一致。

其次是 JSON 函数的兼容。支持 MySQL 的所有 JSON 函数，包括 JSON_EXTRACT、JSON_SET、JSON_REPLACE、JSON_CONTAINS 等等，参数规则、返回值行为都和 MySQL 保持一致。

特别是 -> 和 ->> 这两个操作符，实现和 MySQL 完全一样：

• -> 返回 JSON 类型（带引号）
• ->> 返回字符串类型（去引号）

-- 执行，结果和 MySQL 完全一致
SELECT attributes->'$.color'
FROM products WHERE id = 1;
-- 结果："black"（带引号，JSON 类型）
SELECT attributes->>'$.color'
FROM products WHERE id = 1;
-- 结果：black（不带引号，字符串类型）

还有 JSON 路径不存在的处理，也和 MySQL 保持一致——返回 NULL，而不是抛异常。这确保了那些用"判断是否为 NULL"来检测 JSON 路径是否存在的逻辑，能正常工作。

更重要的是，支持 MySQL 的 JSON 索引语法。MySQL 允许为 JSON 字段的特定路径创建索引，也完全支持：

-- 为 JSON 字段创建索引，语法和 MySQL 完全一致
CREATE INDEX idx_product_color ON products ((attributes->>'$.color'));

有了这个索引，那些基于 JSON 字段的查询，性能就不会下降。

还做了一些额外的优化，比如 JSON 路径缓存、批量处理优化等，确保在大量使用 JSON 的场景下，性能不低于 MySQL。

参数自适应：智能调整，无需手动干预

最厉害的地方在于它的参数自适应能力。应用连接到数据库后，会自动识别应用的使用习惯，然后智能调整相关参数，确保行为和 MySQL 一致。

比如事务隔离级别的自适应。当应用通过 JDBC 连接串设置事务隔离级别时：

// Java 代码设置事务隔离级别为 REPEATABLE_READ
conn.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);

会自动识别这个设置，然后在内核层面启用 RR 隔离级别的 MySQL 兼容模式——包括启用间隙锁、调整 MVCC 快照读机制等。应用完全感知不到，但行为已经和 MySQL 完全一致。

还有 sql_mode 参数的自适应。MySQL 的 sql_mode 里有 ONLY_FULL_GROUP_BY 等选项，控制着 SQL 的严格程度。会自动识别应用对 sql_mode 的设置，然后调整内核的 SQL 解析逻辑，确保行为和 MySQL 一致。

比如应用关闭了 ONLY_FULL_GROUP_BY：

SET sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';

会自动启用 MySQL 宽松模式的 Group By 处理逻辑，那些非标准的 Group By SQL 也能正常执行。

更贴心的是，提供了一个"智能学习"功能。它会记录应用的 SQL 使用习惯，然后自动优化相关参数。比如发现某个应用大量使用 JSON 查询，会自动调整 JSON 相关的缓存参数；发现某个应用有大量高并发事务，会自动调整锁相关参数。

这种参数自适应能力，最大的好处就是——DBA 不需要手动调参，应用也不需要改代码，数据库自己就能适配得很好。

完整的工具链：从评估到上线的全流程支持

除了内核级的兼容，还提供了一套完整的迁移工具链，从评估、迁移、同步到上线，全流程都有工具支持。

第一个工具是迁移评估工具。这个工具会扫描 MySQL 源库的所有对象和 SQL，自动识别不兼容点，并生成详细的评估报告。比如哪些 SQL 需要改，哪些数据类型需要映射，哪些存储过程需要调整，都会列得清清楚楚。

第二个工具是数据迁移工具。这个工具负责把 MySQL 的数据迁移到目标库，支持全量迁移和增量同步，能处理各种复杂数据类型，包括 JSON、BLOB、CLOB 等。迁移过程中会自动做数据校验，确保数据不丢失、不错乱。

第三个工具是实时同步工具。这个工具基于 MySQL 的 binlog 实现增量数据同步，能把 MySQL 的实时变更同步到目标库，延迟控制在秒级。支持双向同步，能实现灰度割接。

第四个工具是测试校验工具。这个工具能自动对比 MySQL 和目标库的查询结果，确保功能一致。还能做性能对比，确保迁移后性能不下降。

有了这一套工具链，迁移的效率能提升好几倍，风险也能大幅降低。

实战案例：从 MySQL 的真实迁移

说了这么多理论，咱们来看个真实的案例。

某大型金融机构的核心交易系统，原本基于 MySQL 5.7，有几千张表，上亿条数据，还有几百个存储过程和函数。最头疼的是，系统里大量使用 JSON 字段存储交易附加信息，而且有严格的事务一致性要求。

迁移前他们做了详细评估，发现如果用传统方案，需要修改 30% 以上的 SQL，还要重写大量 JSON 相关的逻辑，预计工期要 6 个月。而且因为涉及核心交易系统，风险极大，领导都不敢批。

后来他们选择了深度兼容的方案，开启了 MySQL 兼容模式，结果出乎意料的好：

首先，SQL 几乎不需要改。除了极个别特别复杂的 SQL 需要微调外，99% 的 SQL 都能直接在目标库上跑，结果和 MySQL 完全一致。

其次，JSON 相关的逻辑完全不需要改。所有的 JSON 查询、JSON 更新、JSON 索引，都能正常工作，而且性能还有所提升。

再次，事务逻辑完全不需要改。高并发场景下的库存扣减、账户转账，行为和 MySQL 完全一致，没有出现过锁超时、死锁等问题。

最后，迁移周期从预计的 6 个月缩短到了 2 个月。因为有完整的工具链支持，评估、迁移、测试、上线，每个环节都有工具辅助，效率高了很多。

上线后他们也做了对比测试，功能上完全一致，性能上还有 10%~20% 的提升（主要得益于内核优化）。最重要的是，整个迁移过程非常平稳，没有出现过任何大的问题，业务完全无感。

写在最后：迁移不是技术问题，是信任问题

做数据库迁移这么多年，越来越觉得，迁移的核心难题从来不是技术，而是信任。

业务方最担心的是什么？是"改一行代码，崩整个系统"。这种担心完全合理，因为很多核心系统都是十几年沉淀下来的，里面的逻辑错综复杂，改一处可能牵一发而动全身。

所以真正的迁移方案，应该是让业务方感到"安全"的。什么叫安全？就是不用改代码，不用改逻辑，原来的东西怎么跑，迁移后还是怎么跑，结果一模一样，甚至更好。

"零改造"迁移，核心价值就在这里。它不是简单地做语法兼容，而是从内核层面深度复刻 MySQL 的行为，让应用感觉像还在用 MySQL 一样。这种级别的兼容，才能让业务方真正放心。

其实数据库迁移，本质上是一场信任的传递。应用信任原来的数据库，是因为它稳定、可靠、行为确定。新的数据库要赢得信任，也必须做到稳定、可靠、行为确定。

通过深度兼容内核、JSON 专项优化、参数自适应这些技术，赢得了这份信任。应用不需要改任何代码，就能平滑迁移到目标库上，而且功能完全一致，性能甚至更好。

这就是我理解的"零改造"迁移——不是简单地"能跑"，而是"放心地跑"。

随着信创的推进，越来越多的企业面临数据库迁移的问题。选择一个好的迁移方案，不仅是技术问题，更是战略问题。选对了，迁移就是一次平滑升级；选错了，迁移可能就是一场灾难。

希望这篇文章能给大家一些参考，在 MySQL 迁移的路上少走弯路，少踩坑。毕竟，技术人员的价值，就是帮业务方解决问题，而不是制造新问题。