在做数据库运维这些年，我参加过不少技术会议，但这次的经历有点不一样。
ITPUB 联合崖山科技策划了三期《论道国产数据库规模化替代时代》系列直播，话题从选型、迁移到运维，讨论的都是国产数据库规模化替代过程中最现实的问题。
我主持的是这组直播的最后一场——“崖山答疑茶话会”。
这一场没有长篇产品宣讲，基本就是围绕 前几期直播观众留下的近 60 条问题，做了一次集中答疑。很多问题都很直接：
• 选型时“看着好、用着坑”，怎么避免？
• 集中式 vs 分布式，金融用户到底该怎么选？
• Oracle 存储过程一大堆，迁崖山要不要大改代码？
• “零改造迁移”是不是真的可能？
• Oracle DBA 转崖山，得花多久？
• 国产数据库的 AI 运维，是概念还是真有用？
作为主持人，我一边提问、一边做笔记。结合这次直播的内容和我日常在客户一线的观察，我把自己的思考整理成三点判断。
一、选型：企业不再迷信“参数好看”，开始回到业务本身
我开场抛出的第一个问题是：“如何避免选型时看着好、用着坑？”
韩锋老师的回答，其实把现在很多企业的问题点穿了：
很多选型压根就没有真实反映企业自身诉求，往往是“人云亦云 + 模型测试”。
在这场直播里，“科学选型”被拆成了四个很具体的维度：
1. 功能：不是“支持列表”，而是能不能真正覆盖业务特性
数据库的功能很多，不同企业用到的点完全不一样。
选型时，真正要看的是：
• 你关键系统现在依赖哪些特性？
• 这些特性在目标数据库上是否语法/语义等价？
• 极端场景下（错单、补单、批量处理）行为是否一致？
没有这个评估，后面遇到的很多“兼容性坑”，本质上都是选型阶段欠的账。
2. 性能：不能只看“简化模型”，要模拟真实数据与负载
很多 POC 跑的是一个非常理想化的模型，数据干净、结构简单、负载单一。
上线后，数据规模一放大，数据质量一掺水，性能立刻“打回原形”。
这场直播里提到：
选型阶段就应该把“接近真实生产环境”的性能测试纳入标准——包括数据量级、索引分布、冷热数据比例以及混合负载，而不是只看一组 TPS 指标。
3. 业务：把真实交易场景拉进测试，而不是只跑工具脚本
韩锋老师特别强调：
“你要知道测完之后，能跑多少笔交易，这才是客观标准。”
也就是说，选型阶段就应该设计一些业务级用例，例如：
• 日常交易高峰能不能扛住？
• 月末/年终结算对性能的冲击？
• 关键报表、风控查询、跑批与在线交易并发时的表现？
这些场景如果一开始不测清楚，真正上生产时迟早要还账。
4. 生态与高可用：别忽略周边环境的适配能力
第四个维度，其实是这几年逐渐被重视起来的部分——
• 高可用架构是否完善？
• 与上下游系统的衔接是否顺畅？
• 是否有配套的运维平台、监控、告警、诊断工具？
总结下来，我在这场直播里感受到的是：
企业的数据库选型逻辑，正在从“比参数”变成“看场景”。
真正能进入候选名单的产品，必须先过这四关：功能、性能、业务、生态。
二、迁移：从“能不能迁”转向“怎么稳迁、迁多少、可不可控”
在这次直播的第二个环节，我们围绕“如何让迁移更安心”展开了连续提问，包括：
• Oracle 与崖山并行运行、最终平滑迁移的步骤？
• 存储过程很多时，迁移到底要不要改代码？
• 异构迁移怎么保证数据一致性？
• 先从边缘系统开始，还是直接从核心系统突破？
• “零改造迁移”到底现不现实？
可以看出，现在企业关注的不再是“技术上能不能搞定”，而是：
迁移路径是否清晰？
风险是否可控？
工作量是否可预估？
回退机制是否可行？
1. 步骤层面：迁移是一个完整工程，而不是“装个库、跑个工具”
廖传军老师把迁移拆成了非常工程化的过程，大致包括：
1. 现状评估：
• 现有数据库类型、架构、关联系统
• 数据增量特征、关键表分布、依赖关系等
2. 目标架构设计：
• 未来架构是简单平移，还是顺带做一次梳理与整合？
• 有哪些业务会新增？哪些可以合并或下线？
3. 迁移方案设计：
• 全量 + 增量迁移策略
• 双轨并跑、灰度发布、回退与应急方案
• 长稳压测、安全测试、渗透测试等
4. 试点项目：
• 先选一个具代表性的系统试点：SQL 复杂度、数据量、业务重要性都要有一定代表性
• 试点结束后必须复盘，才能评估是否扩大范围
5. 分批推广与最终验收优化
他讲了一句很实在的话：
“自动化和工具化是迁移的核心，但前面这些工程步骤是前提。”
2. 技术路径：应用双写 vs 数据库复制，并没有绝对优劣
在并行与平滑切换方面，这次直播也讲得很实在：
• 应用双写：
• 优点：对数据链路透明，业务感知最直接
• 缺点：对开发团队要求高、责任边界复杂
• 数据库复制（双向）：
• 更适合很多现有团队的实际能力现状
• 常见做法是配合灰度切换，先切部分用户/部分功能，再扩大范围
这里强调的一点是：
架构、工具本身没有绝对优劣，适合现状、风险可控才是关键。
3. 存储过程与“零改造”问题：不要迷信 100%，要关注“可预期”
针对“Oracle 中存储过程多，迁移到崖山是否要改代码”这个老大难问题，韩锋老师给了一个挺“去神话”的回答：
• 通过 Yashan 的 YMP 工具做预评估：
• 哪些对象可以直接运行？
• 哪些存在不兼容点？
• 改造工作量大概在哪个量级？
• 在测试环境做一轮完整验证：
• 功能是否等价？
• 性能是否达标？
• 语法语义是否一致？
他也明确说了：
“完全 100% 零改造”不够严谨，现实中很难存在。
真正重要的是：这套数据库能不能让你看得清、算得明、控得住改造成本和风险。
对“零改造迁移”的回答，他用的是“愿景”这个词——这本身就反映出一种比较理性、工程化的态度。
4. 路线选择：先边缘后核心，还是先核心后边缘？
这一块是很多大机构都在纠结的问题。
韩锋老师结合自己在某国有大行做核心数据库国产化迁移的经历，给了比较客观的分析：
• 先边缘后核心：
• 出问题不影响主业务
• 可以逐步锻炼团队
• 适合技术积累较少、风险承受能力有限的团队
• 先核心后边缘：
• 把资源最集中、成熟度最高的系统作为突破口
• 这一仗打透，后续可以复制经验
• 适合有足够储备、希望尽快形成标杆案例的机构
他给的不是“标准答案”，而是一组原则：
风险可控、积累经验、建立信心、以终为始。
从我自己的视角看，这种“不神化路线选择，只谈原则”的态度，反而是国产替代走向理性的一个标志。
三、运维：决定国产数据库能否“长期用、规模用”的关键变量
最后一个环节是运维，这部分的问题也很集中：
• 单机主备、共享集群能扛多大规模？
• 有没有类似 Oracle AWR / LogMiner 的能力？
• 除了故障和调优，DBA 还有哪些关键工作？
• 崖山在智能运维和实时增量同步上做了什么？
• Oracle DBA 转崖山要多久，难度大不大？
1. 容量与性能：数据量不是唯一指标，“负载特征”才是核心
当被问到“单机主备、共享集群最多能承载多大数据量”时，廖传军老师没有给一个“听起来很吓人的数字”，而是很直接地说：
• TB / 数十 TB 级别，无论单机主备还是共享集群，问题都不大
• 百 TB 级别，必须做严谨的架构与负载验证
• 真正决定架构选型的不是“数据量”本身，而是业务负载特征
他举了很多例子：
• 银行：读写 7:3，晚上可能反过来变成 3:7
• 证券：读多写少，99% 都在查行情
• 保险：承保与理赔的逻辑完全不一样
• 制造业、清算、MRP、夜间跑批等等
结论是：
架构选型（集中式 or 分布式），首先由“性能 + 容量”决定，其次要看业务负载模式，不能被概念带着跑。
2. Oracle DBA 的焦虑与机会：这是“转型”，更是“能力扩展”
“Oracle DBA 转型崖山要多久？”
这个问题在直播间引发了不少共鸣。
韩锋老师的回答，大致可以概括为三层：
1. 先调心态：不是被迫转行，而是能力延伸
• 崖山在架构和使用习惯上与 Oracle 高度相似
• 以前在 Oracle 累积的经验，在崖山上大多可以迁移和复用
2. 再动手：先装起来，先看文档，先玩一圈
• 官方介质、文档、管理平台都已开放
• 很多东西靠“上手”比靠“想象”更快消除不确定感
3. 利用工具与平台降低学习门槛
• 一站式运维平台（YCM）
• 各类管理工具与诊断能力
他提到的一个经验值是：
一般 Oracle DBA 要达到崖山 DBA 的“初中级水平”，一到两周就能上手。
从我个人角度看，“亲切感”三个字很关键——
当一个 DBA 看着一套国产数据库，不感觉“完全陌生”，而是觉得“有点像我熟悉的那套东西”，这就既降低了焦虑，也提升了接受度。
3. 可观测性与“有手段解决问题”，是 DBA 最在意的两件事
有一段对话，我自己也很有感触：
韩锋老师提到，他问过一位金融行业 DBA：
“你考察一个数据库，最看重什么？”
对方给了两个很实在的回答：
1. 可观测性：
• 能不能看清楚数据库正在做什么？
• 出问题时，是不是有路径可循，而不是一个黑盒？
2. 有手段解决问题：
• 遇到性能/故障，有没有成熟的处理机制？
• 能不能通过知识库、一体化平台，把常见操作“点两下就搞定”？
崖山在这方面做了一些对 Oracle DBA 比较友好的设计：
• AWR 类性能报告
• 执行计划管理、Hint、Outline 等能力
• ASH、trace、slog 等诊断手段
• 运维平台 YCM 集中呈现运行状态
作为一个长期在一线做数据库的人，我非常认同这种“从 DBA 视角出发”的产品设计思路：
有观测手段，有处理抓手，比喊再多“高大上指标”更重要。
4. 智能运维：少一点“炫技”，多一点“真解决问题”
在“崖山在智能运维上的进展”这个问题上，廖传军老师的回答也很克制：
• 第一层是：更快地发现问题
• 完整监控与告警能力
• 告警压缩、抑制，避免被“告警风暴”淹没
• 第二层是：更快地定位问题
• 慢 SQL 发现
• 性能瓶颈分析
• 第三层是：更快地找到解决方案
• 借助运维知识库
• 计划使用自研向量数据库做 AI 助手，让 DBAs 能基于自然语言快速检索处理经验
他也点破了一个现实：
很多 AI 运维的概念听上去很美，但在样本不足、负样本稀缺的前提下，很多所谓“自动预测与优化”很难真正落地。
所以，与其追求“全自动”，不如先做好“快速发现 + 快速定位 + 快速给出经验路径”。
这一段对话，某种程度上也体现了：
国产数据库厂商在智能运维上，从“追热点”转向“解决问题”的态度变化。
写在最后：真正的变化，正在从会议室走向机房现场
整场直播下来，我的一个强烈感受是：
• 选型在变：从看参数，走向看场景
• 迁移在变：从问“能不能”，变成问“怎么稳、怎么控”
• 运维在变：从“流程化”走向“可观测 + 有抓手 + 工程化 + AI 助手”
更重要的是，对话的氛围在变：
• 用户的问题，越来越聚焦“真实落地场景”
• 专家的回答，越来越少“概念性包装”，多讲工程细节与经验边界
• 国产数据库本身，也从“能不能替代”的讨论，进入到“如何规模化替代、如何长期可用”的阶段
作为这场“答疑茶话会”的主持人，同时也是长期在一线做数据库的人，我对未来一段时间的行业有几个朴素的期待：
• 国产数据库可以在更多关键业务中，经得起压测、经得起事故、经得起回顾；
• 更多 Oracle DBA 能把自己多年积累，平滑地带到新的国产数据库平台上，减少焦虑，增加选项；
• 厂商与用户之间，能多一些真实的数据和场景交流，少一点只看宣传的“想象落地”。
从这一场直播开始，我更坚定了一个判断：
国产数据库规模化替代的下一步，不在PPT上，而在每一个具体的选型评估、每一条迁移路径、每一次真正的故障演练里。
而这，恰恰是我们每一个数据库从业者，正在参与并推动的事。
