先说个具体的事。
前几天翻 KES V9R4C019 的发布资料，翻到一张图，整张图上就一句话。
10分钟 VS 1分钟。
讲的是 SQLServer数据迁移 完成之后的复杂查询。我盯着这行字看了一会儿，第一反应不是兴奋，是这话说得也太满了。
因为在数据库这个圈子里，性能数字是最不值钱的东西。谁都能挑一个对自己有利的场景跑出个漂亮倍数，单表点查，缓存全热，一个会话独占整台机器，跑出来的数好看得像样板间。
但我还是把这版的材料从头到尾看了一遍。看完之后改了看法，而且改得挺彻底。
不是因为那个 60%，是因为他们把痛点写在了自己的发布物料上。
一、换库的人真正怕的，从来不是迁不过去
你去问任何一个正在评估换库的技术负责人，他真正怕的其实不是迁不过去。表结构、存储过程、T-SQL 语法，评估工具跑一天就能给你一份报告，哪些能自动转，哪些要人工补，早就不是悬念。
他怕的是另一件事。
迁完之后，业务口那几张最重的报表，还能不能像以前那么快。
我特别理解这种恐惧。因为这个决定是有名字的。评估会上签字的是你，切换那天晚上守在机房的是你，第二天早上八点业务总监打电话过来问这个报表怎么比以前慢了半分钟的时候，接电话的还是你。业务决策做砸了可以说市场变了，技术选型做砸了，就是你的问题。
你可以回想一下上一次系统切换的那个晚上。
凌晨两点切完，回归用例一条条过，天蒙蒙亮的时候松一口气，觉得这事儿成了。
然后早上九点，业务群里弹出一句，那个月度分析怎么一直在转圈。
你打开一看，那条 SQL 在测试环境跑 2 秒，在生产跑了 40 秒。测试库里的数据是半年前脱敏抽出来的一百来万行，生产库里那张表两个亿。
难受的地方从来不在于修不好，在于所有人都在等你，而你连从哪儿下手都还没想清楚。
很多换库项目最后不了了之，不是因为评估报告上写着不行，是因为拍板的人脑子里一直挂着这个画面。
站在这个位置上，任何一个人保守一点，都是对的。
我也不觉得那种国产库性能不行的印象是空穴来风。前些年确实有一批不太行的版本，兼容做得糙，优化器一言难尽，被坑过一次的团队，这个印象就刻下来了。麻烦在于那大概是五六年前的事，而这几年金仓这条产品线迭代的速度，跟人更新自己判断的速度完全不是一个量级。
二、最要命的那类 SQL，到底长什么样
说回那张图。
它的完整版本其实是这么写的，含标量子查询的多表关联分析，原场景下数据量增加时 SQL 变慢。
我看到这句愣了一下。因为这不像是发布物料该写的话，它更像是一条 issue。敢把自家最难看的场景摆在发布页第一屏的厂商不多，这一点先加分。
不做这行的朋友可能对这句没什么感觉，我翻译一下它在生产环境里长什么样。
就是那种，目标列里嵌着一个相关标量子查询去取维度名称，外面再套三四张业务大表的关联，末尾跟一长串过滤条件的 SQL。经营分析、监管报送、领导驾驶舱，这三类需求里几乎全是这个写法。
它的麻烦在于，这类 SQL 对优化器的依赖高到离谱。执行计划选对了是秒级，选错了就是分钟级，中间几乎没有过渡地带。而且它会随着数据一年年沉淀慢慢劣化，今年 3 秒，明年 8 秒，后年跑不完。
大部分团队怎么应对，我猜你也熟。加机器，加索引，实在不行把报表挪到凌晨两点跑批，第二天早上给业务看一张昨天的数。
这就是那句「数据量增加时 SQL 变慢」背后真正的东西。
三、100 并发，TPS 涨 60%，响应时间只剩十分之一
那这版给的答案是什么呢。
100 并发场景下的复杂查询，TPS 提升 60%，响应时间压缩到原来的十分之一。
我想说的重点不在 60%，在前面那三个字，100 并发。
单会话跑分是最容易注水的。一条 SQL 独占内存，独占 IO，缓存全命中，跑出来的数字更多是在测硬件。并发压上去之后，考的东西完全变了，执行计划稳不稳，内存怎么争，锁等多久，连接怎么调度，任何一环松了吞吐都上不去。
TPS 涨 60% 和响应时间降到十分之一同时出现，说明快的不是某一条，是整体的调度效率。这个组合是做不了假的。
十分之一这个量级也得多说一句。如果只是提升 20%，那是运维指标好看一点，业务侧根本没感觉。降到十分之一，业务流程是可以重写的。报表不用再挪到凌晨，分析师可以在会上当场钻取，驾驶舱可以做近实时刷新。官方对这件事的概括我觉得挺准，BI 报表从等它跑完变成秒出结果。
体感上的差别，就是那张图上的 10分钟和 1分钟。
四、这 60% 是从哪儿来的
总不能是变魔术。
金仓同期版本里公布的优化方向，正好是冲着这类 SQL 去的。一个是 QueryMapping 升级，支持任意 SQL 解析、对象名模糊处理、映射数据驻留内存。一个是把窗口函数的过滤条件下推到了 WindowAgg 节点，减少无效计算。还有一条更对症，针对目标列中包含相关标量子查询、以及包含等价性谓词和传递谓词条件的场景做专项优化，官方给的实测是百万行数据查询提升 30%。
谓词下推这个事，我用买菜打个比方。
你要买两斤没打农药的青菜。一种做法是把整个菜市场的青菜都搬回家，回家一棵一棵挑，挑完剩两斤。另一种做法是在摊位上就问清楚，直接称走两斤。数据库里的谓词下推就是后一种，把过滤条件尽可能往数据源头推，能早一步扔掉的数据绝不多背一米。
窗口函数这块尤其明显。窗口函数天然要在一大堆数据上做排序和分组计算，如果过滤条件卡在最外层，等于先把所有数据都算一遍窗口，再扔掉九成。把条件推到 WindowAgg 节点，那九成从一开始就不参与计算。
这不是调参数能调出来的东西，是要动执行计划生成逻辑的。愿意在这个位置下手，说明团队是真的在啃硬骨头，而不是在做 benchmark 表演。
五、一个反直觉的点，兼容做得好，性能对比才成立
聊到这我得插一句可能有点反直觉的话。
这版在兼容上补的那些东西，MERGE、并行 DML、OUTPUT 子句、窗口函数、PIVOT 和 UNPIVOT、LIKE 通配符，还有跨库访问系统视图，Oracle、MySQL、KingbaseES 之间互通不用再走一遍 ETL。这些看起来是省事的功能，跟性能好像没什么关系。
其实关系大得很。
你想想看，兼容如果不到位会发生什么。那些跑不通的 T-SQL 得有人改写。改写的人往往不是当年写这段 SQL 的人，他不知道这个子查询为什么这么写，也不知道这张表的数据分布长什么样，他只能保证改完结果是对的。
而一段结果对但写法退化的 SQL，是性能事故最经典的来源。集合运算被改成了循环，索引失效，执行计划全变。
所以存量 T-SQL 不改代码直接连上去跑这一条，价值不在省了几个人天。它的价值在于，迁移前后跑的是同一份 SQL，那组性能对比才是可比的。
改了 SQL 再去比性能，比的是两个人的水平，不是两个数据库的水平。
六、比 60% 更值钱的，是出了问题能查得清
不过这版里我最看重的东西，其实不是那 60%。
是迁完之后出了问题能不能查得清。
真正让 DBA 睡不着的从来不是慢，是慢了但说不清为什么慢。同样一段业务逻辑，昨天好好的今天忽然多跑了 8 秒，日志翻三个小时，最后写在故障报告上的是疑似执行计划变化。
这版在这个位置放了几样东西。QueryMapping 支持模糊匹配，能自动发现写法相近的 SQL 之间的执行差异，同一个业务逻辑的两种写法为什么一个快一个慢，工具直接把差异摆给你看。再往上是智能 SQL 调优建议，会给出改写方案，不动应用也能优化。官方管这套叫系统级的眼睛，说是用来发现被忽视的性能杀手。
名字起得有点中二，但这功能我是真觉得有用。
因为它把性能问题从玄学变成了工单。
运维那块也是同一个思路，内置了故障收集分析工具，自动抓日志生成诊断报告，官方的说法是根因分析从人工拼图变成工具出结论，出了问题 5 分钟找到根因。备份改成块级增量为默认归档模式，全量、增量、归档日志三件套，备份窗口从小时级压到分钟级。PITR 会自己算最优恢复路径，不用你临场判断该从哪个点往回滚。
这些东西平时都用不上。用上的那天，你会庆幸它在。
七、11 个核心系统整体换库，只遇到两处适配
光看发布物料还是有点悬浮，说个落地的。
东部有家省级环保集团，把环保一体化、OA、投资管理、人力资源、统一门户、数据中台、采购管理、科创管理、供应链金融这一整排系统，11 个核心业务系统整体换到了金仓数据库。这种规模的全栈换库，我原本预期的是一地鸡毛。
结果官方复盘里写的是，全程只遇到两处适配。
坦率的讲，做过项目的人都知道，只遇到两个问题这种话，通常意思是只有两个问题值得写进结案报告。但难得的是这次两处都写了出来，而且写得足够具体。
第一处，业务表 sys_user 跟系统视图重名了。处理方式是改 JDBC 参数配置，没改代码，也没动表结构。
第二处，针对环保监测的汇总业务 SQL 做性能调优，做法是合理建索引加上精简关联逻辑，把原本 15 秒的查询压到了 1.8 秒，提升 88%。
这是一个非常朴素的动作，朴素到没什么宣传价值。但恰恰是这种朴素的东西最能说明问题，说明迁完之后遇到慢查询，是可以按老办法一步步排查解决的，而不是撞进一个黑盒。
这类坑的共性是，它们都不出现在评估报告里。
评估工具扫的是语法能不能转，能扫出来的是存储过程里哪个函数没有对应实现，扫不出来的是名字撞车、排序规则不一致、隐式类型转换在新库里走了另一条执行路径这种事。它们大多不会让程序报错，只会让某一条结果悄悄变了，或者某个本来走得好好的索引悄悄不走了。
所以迁移项目里最不该省的时间，从来不是转换那几天，是转换完之后拿真实数据做比对的那几天。
集团那边给的评价是，迁移过程非常简单，干预极少，兼容性超出预期。目前所有系统已经稳定运行超周期，查询效率、并发能力、运维成本都优于原有架构。
八、代码 0 改造，迁移 0 停机，上线有保障
金仓把 SQL Server 的迁移路径拆成了三段，我觉得这个拆法很实在。
第一段是代码 0 改造。MERGE、并行 DML、OUTPUT 子句原生支持，存量 T-SQL 直接连上去跑。
第二段是迁移 0 停机。KDMS 负责结构迁移，KDTS 负责全量，KFS 负责实时同步，全量加增量加校验，源库不用停机，目标库实时比对校验保证数据一致，支持双轨运行和一键回退。
第三段是上线有保障。PITR 最优路径恢复，故障后 5 分钟内可定位数据，HA 组件独立运维，企业自己就能管切换逻辑。
这三段里，我认为含金量最高的是 KReplay。
它能采集生产环境真实的处理过程，然后在新库上做 100% 全负载的拟真回放。官方拿这个背书上线成功率 99.9999%。
那串 9 你信不信随意，但这个功能的意义不在那串 9。
它的意义是，你不需要相信任何人给的跑分。包括这篇文章里的 60%，包括那张 10分钟 VS 1分钟的图，也包括环保集团那个 88%。
你可以把自己生产环境里最要命的那段负载录下来，在新库上原样重放一遍，然后自己看表。
这件事让我想到一个更大的东西。
科学之所以是科学，从来不是因为结论正确，而是因为可复现。任何人拿到同样的条件，都能把这个实验重跑一遍，得到同样的结果。一个不能被别人重跑的结论，在科学里只能叫轶事，不叫证据。
数据库选型这事其实也该按这个标准来。厂商给的数字是轶事，你自己的负载跑出来的数字才是证据。金仓愿意把回放工具直接交到你手上，等于是主动把自己的结论放到可证伪的位置上，这个姿态比那串 9 值钱得多。
九、迁移这件事本身，也在被工具重写
顺着这个再说迁移工程。
KDMS 是金仓那套迁移工具链里做结构迁移和评估的部分，支持把 DB2、Oracle、SQL Server、MySQL 这些主流库迁到 Kingbase。
它的原理不复杂，读取并解析源库的 SQL 语义，形成结构化的逻辑对象，再按目标库的语法格式和对等函数生成能跑的 SQL。说到底是在做编程语言的翻译，好处是不用为了兼容去动数据库内核，稳定性不会被牵连。
采集完之后会自动生成一份评估报告，每类对象有多少、成功多少、自动转换率多少，一目了然。
官方公布过三组案例的人天数据，源库都是 Oracle 体系，SQL Server 的量级可以参照着看。
第一个是某 OA 系统，48320 行 SQL 代码，51 个存储过程，705 个视图，437 个索引，541 个触发器，还有 1283 个主外键和约束，自动转化率 98%。传统做法是高级工程师 62 人天，实际用了 1 名初级工程师 13 人天。单看数据库结构迁移这一环，44 人天压到了 3 人天。
到这我觉得还行，属于工具应该有的水平。
第二个是某复杂文件交换系统，310 个存储过程，131 个函数，自动转化率 96.4%，51 人天压到 9 人天，费用降了 91%。
嗯，比上一个还狠一点。
第三个是某 HIS 系统。这个量级就有点吓人了，98027 行 SQL，5009 张表，105 个存储过程，191 个触发器，自动转换率 97.69%。原本的方案是 2 名高级工程师干 1 个月，最后是 1 名初级工程师干了 1 周，费用降低 94%。
2 个高级工程师 1 个月，对 1 个初级工程师 1 周。
医院的 HIS 是什么样的系统不用我多说，全院的命都挂在上面，谁敢在这种系统上做实验。这组数字如果是真的，它证明的不是工具多强，是这条路已经被人走通到了敢让初级工程师上手的程度。
KDMS 官方给的处理速度是每分钟 20 万行以上的 SQL 和 PL/SQL 代码。人一天能读多少行代码，你自己算。
十、真要验证，照着这三步做
写到这我得说句公道话。
上面所有的数字，都是厂商自己公布的。没有独立第三方的测试报告，也没有谁在你的环境里把这些场景重跑过一遍。这篇文章能做的，只是把材料摊开，告诉你哪几个数字值得追问，哪几个功能是真正解决问题的位置。
所以与其争论这些数字准不准，不如说说真要验证的话该怎么验。
第一件事是选样本。别拿标准跑分工具，也别随手挑几条 SQL，去翻生产库的慢日志，按累计耗时排序取前十条。这十条通常吃掉了整个系统七八成的资源，它们跑得好不好，基本就等于系统跑得好不好。
第二件事是并发要压到位。前面说过 100 并发那三个字才是关键，你自己测的时候也一样，并发数得贴着业务高峰的真实值来。用 KReplay 把生产流量原样重放，比自己写压测脚本靠谱得多，因为人造的压测脚本永远比真实业务干净，而真实业务的脏，才是压垮执行计划的那部分。
第三件事是别只看时间。同一条 SQL 快了慢了，得把执行计划一起拉出来对，快是因为选对了索引，还是因为缓存刚好是热的，这两件事的含义完全不一样。
这三步做完，你手里就有了一份别人拿不走的结论。它可能比官方给的 60% 更好，也可能更差，但它是你自己的。
十一、写在最后
至于最开始那个问题，SQL Server 迁过去之后到底会不会变慢。
从这一版给出的东西看，我的判断是不会，而且大概率是反过来的。含标量子查询的多表关联被专门优化过，100 并发下的复杂查询 TPS 涨了 60%，存量 T-SQL 不用改代码，出了问题有工具帮你定位根因，上线之前还能拿真实流量先跑一遍。这已经不只是能用，是奔着好用去的。
用五年前的印象去回答今天这个问题，大概率会答错。刻板印象最麻烦的地方不在于它错，在于它一旦形成，人就不再去验证了。
所以那张图上的 10分钟 VS 1分钟，你可以不信。
你只需要把手上最慢的那条 SQL 拉出来，找台机器，跑一遍。
跑完之后，数字自己会说话。