今天早上让 AI 帮我搜罗了一下最近一周数据库和 AI 方向比较火的新闻或者官方事件，大概搂了两眼，发现 AWS 最近连着发了两篇用 AI 迁移数据库的文章。快速扫了一遍文章内容，发现还挺有意思的。
文章里说：用 AI 迁移一个 SQL 对象只需要花费几美分，100 个对象算下来也就是几美元，代码转换率更是高达 90%。
看完之后，我的第一反应是：以后迁移项目里最磨人的代码改造，是不是很快就不值钱了？
实际呢，我看了 SQL Server 那篇文章里的 21 个对象。AWS 拿 AdventureWorks2022 跑完，13 个没有留下 Action Item，8 个还要继续处理。
其中，比较简单的 10 个标量函数和 1 个表值函数都过去了，3 张表也只剩两个日期默认值的问题。但是到了存储过程，画风就变了：7 个过程，只有 1 个直接通过。
看完我一点也不意外，毕竟存储过程一直是迁移中最难攻克的。
存储过程这玩意儿说实话很复杂，事务、临时表、权限、异常处理，什么都可能往里塞。有些写得跟 TM 长篇小说似的，前面挖一个坑，过了几百章才填，还有索性忘记填直接烂尾的。代码年头再久一点，开发早都换了不知道多少拨了，迁移的时候让你来解释这个分支为什么这么写，我估计没人敢搭话，谁也不想背锅。
虽然可以用 AI 转换，但是这个问题还是绕不开，这些说不清的旧账又得重新翻出来。AWS 这次碰到的 hierarchyid、全文检索、CLR、XACT_STATE()，都是迁移时不太招人待见的东西。
hierarchyid 在 PostgreSQL 里没法原样使用，到底是换成路径、数组，还是干脆重新建模，要看业务拿它干了什么。全文检索也不是换个函数名就结束了，分词和索引都得重新看。至于 CLR，如果只是做点字符串处理还好，万一里面读文件、调接口，那就不是改 SQL 了，而是要重新决定这段逻辑该放在哪儿。
这事其实挺烦。报告里只有一行 Action Item，真改起来却可能要把开发、测试、业务都叫过来，有时候还得找那个已经转岗的人问一句："当年为什么这么写？坑爹啊！"
说实话，找不着开发的人也是常有的事，最后大家只能对着代码猜。
话说回来，AWS 这套做法我还是赞成的：它没有把一整个 Schema 全扔给模型自由发挥，而是先让 DMS Schema Conversion 解析语法和依赖，固定规则能处理的照旧处理，实在处理不了的部分再交给生成式 AI，生成后的 PL/pgSQL 再过一遍 PostgreSQL 解析器。
能确定的就别让模型猜，这个思路没毛病。
过了解析器，至少语法这一关算是走完了。至于这段代码还在不在干原来那件事，后面还得测。
拿 XACT_STATE() 来说，SQL Server 会用它判断事务当前还能不能提交。换到 PostgreSQL，异常块和事务的处理方式都变了。正常流程也许跑十遍都没事，但是真到哪天中间突然报错，才发现该回滚的数据没回干净，或者日志没留下来，就完犊子了。
语法错误虽然烦人，但这种坑更讨厌。语法错了当场报，当场修好就是了。要是行为变了，可能要过很久才有人发现。（而且通常挑半夜的批处理先出问题，很会选时候。）
再换个用户跑，可能又是另一回事。SQL Server 里的 EXECUTE AS 到了 PostgreSQL，过程最后以谁的身份执行、能访问哪些对象，不实际验证心里没底。性能也躲不过去，结果集完全一致，执行时间从几十毫秒变成几秒，迁移照样算失败。
真到了要验收的时候，还是那些体力活。相同的正常值、空值、边界值，两边都跑；故意把事务搞挂一次，看回滚、日志和重试；换不同权限的用户执行；核心 SQL 再看看执行计划和 I/O。
没什么高科技，但少一步都不放心。
再说回那篇 Oracle 迁移文章，AWS 的说法是，生成式 AI 可以多转换 15% 到 20% 原本处理不了的代码，整体代码转换率最高约 90%。这个结果来自特定的测试场景，公开展示的受控测试也只有 6 个对象，不能直接拿来当生产项目的预期转换率。
但是"对象"这个计量单位，有时候挺糊弄人的。
100 个普通函数是 100 个对象，100 个带事务和外部调用的存储过程也是 100 个对象。前者可能很快就看完了，后者光梳理原来的逻辑就够喝一壶。用对象数量去估人工成本，跟按文件个数估开发工作量差不多。
说到这个，我还想顺手吐槽一下国产数据库迁移工具。
这几年看国产数据库的方案，迁移完成率、对象兼容率、预检查通过率这些数字也越来越漂亮。控制台一片绿，进度跑到 100%，放在汇报里当然好看。可真做过迁移就知道，100% 到底代表什么，得先把统计口径翻出来。
我翻了下某国产数据库迁移工具的文档，人家写得其实挺诚实：迁移进度是根据迁移对象数量计算的，显示 100% 只代表对应阶段完成。全量和增量完成了，也不一定代表整个任务结束，触发器和事件还可能排在后面。迁完以后，照样要继续做对象、数据、用户权限对比，必要时还要跑性能测试。
另一款国产数据库迁移工具的文档里也有类似的细节。账号迁移只支持数据库级和全局级权限，表级、存储过程级、列级权限并不能原样迁过去。进度条不会替你把这些边角料收拾干净。
所以我现在看到"迁移成功率 100%"这类字眼，基本都会下意识问一句：哪种对象，按什么口径，有没有算权限、行为和性能？这不是故意挑刺。迁移工具把能自动做的部分做掉当然值得夸，可别把进度条的 100%，直接当成项目的 100%。
现在不少国产数据库迁移，实际做下来还是费时费力。问题不一定都在搬数据上，兼容改造、对象补齐、权限核对、SQL 调优、割接演练，一样都跑不了。工具报告完成了，项目组可能才刚进入最磨人的阶段。
按 AWS 这组估算，模型费几乎可以忽略。一个对象 0.03 到 0.07 美元，100 个也才 3 到 7 美元。钱不花在模型上，还是会花在后面的验证上。结果、事务、权限、性能，哪一个出问题都得有人接着查。
创建迁移项目、导入元数据、等任务、下报告、整理 Action Item，这些活我倒很想让 AI 全接过去。又碎又烦，Schema 一多，控制台、脚本、Excel 来回切，半天就没了。
这种事交给 Agent，我没意见，最好连表格都替我填了。代码转换也可以先让 AI 干，至少不用从空白文件开始，一个函数一个函数查目标库语法。只是它交出来的应该叫第一版，不要急着在项目周报里写"迁移完成"。
现在大家都爱晒转换率。我倒更想看看另一个数字：那 10% 最后是谁改的，改了多久。
估计这种数，一般不会有人专门统计。
我还是希望国内这些数据库厂商多在这块下点功夫。哪怕先把存储过程、权限、异常语义和性能验证往前推一点，也比再做一张 100% 的宣传图有用。
DBA 已经够忙了，真别只帮我们把进度条跑满。