国产数据库选型POC最佳实践：7步验证框架与打分表

大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

去年我参与过一次数据库选型。三家厂商，各测两周，最后选了功能清单最长的那家。上线三个月，核心报表跑不出来。回头翻 POC 记录我才发现，当时压根没按真实业务的量去测。这个坑让我重新想明白，POC 到底该怎么测。

一、先说那次翻车的 POC

那次选型，流程走得挺齐。每家厂商给两周，装环境、跑用例、出报告。最后打分，比的是谁的功能清单勾得多。当选那家功能项确实最全，评委一致点头。可上线三个月就出了事，核心报表查询从毫秒级掉到几十秒，直接跑不出来。业务天天投诉，运维扛不住。我把当初的 POC 报告翻出来逐项对照，问题很直接。

POC 用的测试库只有几万条数据，生产表是几亿行。几万行的时候，什么写法都飞快；几亿行的时候，没有对的索引和计划，直接趴下。POC 跑的性能项，还是基准工具里那几条固定 SQL，跟我们报表的 SQL 半点关系没有。那次教训很贵。我后来常跟人说，POC 测的不是"这套库能不能跑"，是"它扛不扛得住你自己那摊活"。这两件事，差了十万八千里。

二、为什么多数 POC 测不出真相

翻车不是个例。我后来观察了十几个 POC 项目，毛病高度一致，大多出在"测什么"上。数据量不对最普遍，为了省事拿几百条、几万条数据应付，数据量一小，索引、分区、执行计划的差异全被掩盖，测出来的性能跟生产没有可比性。用例也常不对，不少 POC 直接跑 TPCC、Sysbench 这类标准基准，可基准测得出硬件吞吐，测不出你业务里的慢查询。真正会踩的坑，藏在那些带复杂 JOIN、带子查询、带范围扫描的报表 SQL 里，标准基准一条都不覆盖。

剩下的毛病出在"测多全"上。维度不全很常见，功能测了，性能测了，迁移没测，高可用也没测，上线才发现改造成本超预算，或者故障切换要好几分钟。这些本该在 POC 阶段暴露的风险，全被推到了生产。最后一条是厂商应试，大家心里都清楚，只是不太好摆到台面上说。厂商知道你要测，会提前针对你的用例调参数，甚至临时改配置应付，测的时候看着漂亮，一上生产参数一还原，原形毕露。

三、POC 验证的 7 步

想避开这些坑，我把 POC 拆成 7 步。顺序别乱，每一步都有它要防的东西。

第一条是先定验收标准。别等测完再开会吵"算不算过"。动手前就把打分表定下来：测哪些维度、每项权重多少、合格线画在哪。标准是评委说了算，主动权才在自己手里。

第二条是选出真实业务 SQL 集。从生产的慢查询日志、AWR 报告、监控平台里捞。把最慢的、最频繁的、最核心的查询挑出来，组成一套用例。这套 SQL 才代表你的业务长什么样，标准基准替代不了。

第三条是用同量级的数据。生产数据脱敏后直接用最好。拿不到，就按真实分布和规模放大。几亿行的表，POC 里至少得有千万行，趋势才看得准。

第四条是功能兼容性验证。重点测存储过程、函数、触发器、自定义语法的改写量。别只看语法过没过，要看行为对不对。空字符串、日期格式、排序规则、NULL 处理，这些细节最容易在上线后炸雷。

第五条是性能压测。用第二条选的真实 SQL，配上真实的并发模型。特别提醒一句，看 P99 和 P95，别只盯着平均响应时间。平均值好看、长尾趴下，是最常见的假象。

第六条是高可用与故障切换演练。这一项没法预习，最见真章。造一次主库故障，掐表看切了多久，数据丢没丢。RTO 和 RPO 是实测出来的，不是厂商嘴上说的。

第七条是迁移工具链验证。评估、迁移、增量同步、回滚，一条链都要走通。这一步的成熟度，直接决定项目工期和成本，也最能看出厂商的工具顺不顺手。拿金仓的 KDMS 来说，它连上源库扫一遍，自动生成兼容性报告，把对象分成直接兼容、需要改写、需要重构三类，整个过程不改源库。工作量估得准，排期才敢往下走。工具再拿真实数据走一遍，割接窗口能压多短，心里才有底。

四、怎么防厂商"应试"

出题方式最关键。SQL 集和数据集测试前封存，现场才给，别让厂商提前拿到卷子回去调优，那样测的是调参能力，不是产品能力。打分表权重也提前定死，评委对着勾，主观空间就小了；金额大的项目，请第三方或上级技术部门一起盯着。

再专门留一项没法预习的。故障切换、迁移工具链这种，现场跑、当场看。产品真行假行，这类场景最容易露底。

五、打分表长什么样

别把 POC 搞成一堆感觉。一张表固定下来，谁都别拍脑袋。

权重按自己业务调。写入密集，就把性能权重加高。迁移历史包袱重，就把迁移权重加高。表定下来，测完的分就是事实，不是印象。

避坑清单

POC 该怎么测，前面讲完了。最后留几条坑，都是我自己踩过、或者眼看着别人踩进去的，希望能帮你避开。

性能这关，数据量必须跟生产一个量级。几万行跑得飞快，不代表几亿行也快，执行计划是会随数据量变的。这一项省了，等于没测。

用例也别拿标准基准凑数。TPCC 排第一，说明不了你的报表跑得动。真正该测的是从自己慢查询里捞出来的那些 SQL，那才是会上生产的负载。

故障切换演练别拖到最后。它一旦超标，方案就得推倒重来，前面测完的功能和性能全白费。越早测，余地越大。

我的判断

POC 不是走流程，是提前把雷排掉。测得好，选型是选出来的；测不好，选型是赌出来的。我的原则是宁可前面慢一点，真实数据、真实 SQL、真故障切换都实打实测一遍。这两三周花下去，比上线后返工两三个月划算得多。

选型的账也别只算授权费。迁移的人力、生态的隐性成本，往往更贵。POC 阶段把工具链这一环验证透，就是在替后面的工期省钱。

你们团队做过数据库 POC 吗？测了哪些、漏了哪些？评论区聊聊，我猜不少人和我一样，都是翻过车才学会怎么测的。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋