前面十二章，我们一直在给甲骨文挑刺：借了上千亿的债、押注押在一个客户身上、循环融资像 2000 年电信泡沫。现在把镜头掉个头，做一次正面体检——甲骨文最老、最赚钱的那块地基：数据库锁定，今天到底还硬不硬？
先说清楚"锁定"是什么。数据库锁定不是法律条款，是一种物理事实：你的公司把核心数据放进了 Oracle 数据库，用了它的 SQL 方言、它的存储过程、它的高可用机制，写了几十万行紧贴着它的代码。想换成别家，等于给一栋住了人的大楼换地基——技术上能做，但要停业、要重写、要冒数据丢失的风险。于是绝大多数人选择每年乖乖续费。租金就是这么收上来的。
这块地基这几年被甲骨文加了三样新东西：自治数据库、Exadata、多云互联。前两样是把锁往硬里焊，第三样最微妙——它到底是加固还是开逃生门，是本章要吵清楚的那个点。
第一样：自治数据库，把 DBA 焊进服务里
自治数据库（Autonomous Database）说白了是一个"自己照顾自己"的数据库。传统上，一个数据库背后得养一群 DBA（数据库管理员，专门给数据库打补丁、调性能、做备份、半夜出事爬起来救火的人）。自治数据库把这些活儿大部分自动化了：补丁自己打、索引和内存自己调、备份自己做、出故障自己切换。卖点很实在——省人、少出错。
就像从"雇一个专职司机天天伺候的老爷车"换成"一辆自动驾驶车"。车还是那辆车，但你不用再养司机了。听起来是帮你省钱，可省下来的那份工资，其实一部分变成了甲骨文的订阅费——而且这辆车只有甲骨文能修。
从锁定的角度看，这一步很聪明。它把锁定从"数据和代码"这一层，往下再钉了一层："运维"。原来你还养着一队 DBA，这队人理论上哪天也能帮你把数据库迁走；现在这队人裁了，运维知识连同人一起交给了甲骨文的自动化。真要搬家，你连一个懂怎么搬的人都不剩了。它卖的是省心，买回来的是更深的依赖。
第二样：Exadata，把锁定焊进硬件
Exadata是甲骨文的数据库一体机：把数据库软件，和一整套专门为这个软件调过的硬件（服务器、闪存、内部高速网络、智能存储），打包成一个箱子卖给你。核心卖点是快——Oracle 数据库跑在 Exadata 上，比跑在普通服务器上快很多。
它凭什么快？关键在一个叫智能扫描（Smart Scan）的招。普通数据库查数据，是存储把一大块原始数据整个搬到 CPU，CPU 再从里面挑出你要的那几行——搬得多，算得少，网络和内存全堵在路上。Exadata 反过来：让存储层自己先过滤，只把命中的那几行送上去。相当于你去仓库取货，普通做法是把整个货架推到你面前你自己翻，Exadata 是仓库管理员先按清单挑好、只把你要的那箱递出来。
这个"存储自己会挑货"的本事，是甲骨文把软件和硬件揉在一起才做出来的——普通硬件上跑普通 Oracle，享受不到。于是性能成了锁定的一部分：你一旦习惯了 Exadata 的快，换到别处不光要重写代码，还要接受"变慢一大截"。慢，也是一种迁移成本。
更狠的是，Exadata 现在不只是摆在你自己机房里的箱子，它进了云——甲骨文云里有 Exadata Cloud，你按用量租，不用买整台。这让锁定从"资本开支"（买一台几百万的机器）变成了"细水长流的订阅"，门槛更低，反而更多人踩进来。把锁定焊进硬件的好处是：软件可以被模仿，一整套软硬协同的性能优势，别人抄起来慢得多。
第三样：多云互联——这一章真正的问号
多云互联指的是 Oracle Database@Azure / @AWS / @Google 这一系列产品：甲骨文把自己的数据库硬件（就是上面说的 Exadata 那套），直接搬进微软、亚马逊、谷歌三大云的机房里，摆在人家的数据中心内部。于是一个客户主力用 AWS，也能在 AWS 里贴着用原生的 Oracle 数据库，数据库和它的应用之间是机房内部的低延迟连接，不用跨着公网来回跑。
为什么要这么做？因为过去十年发生了一件对甲骨文不利的事——客户上云，上的多半是 AWS、Azure、Google 这三家，不是甲骨文自己的 OCI。客户跟应用一起跑到了别人家。甲骨文面前只有两条路：要么眼睁睁看着客户在别人的云里慢慢把 Oracle 换成那家云自带的数据库；要么，跟着客户过去。
它选了跟过去。这就是本章的核心张力。同一件事，有两种完全相反的读法：
读法 A：这是加固——"你跑到 AWS 上也甩不掉我"
过去客户搬去 AWS，是甩掉 Oracle 的天赐良机：既然整个技术栈都在重搭，顺手把数据库也换成 AWS 自家的（比如 Aurora），一劳永逸。多云互联堵死了这条路——现在你搬去 AWS，Oracle 数据库原封不动跟着进来，性能一样、体验一样，你连"重搭时顺手换掉"的借口都没了。锁定不但没松，还跨越了云的边界，变成"你去哪家云我跟到哪家"。从这个角度，甲骨文赢了：它把一个流失场景，改造成了留存场景。
读法 B：这是逃生门——"我留不住你，只好跟着你去别人家"
但换个角度，这动作本身就是一种认输。健康的收租之王，是让客户离不开自己的云；一旦你得把数据库拆下来，装进竞争对手的机房、按人家的规矩摆放、还要给人家分一杯羹，你其实已经承认：留住客户的是那三家云，不是你。你从"地主"退成了"租户的租户"。
更要命的是它给客户开的那扇门。数据库进了 AWS 机房、和 AWS 的服务贴在一起用之后，客户的技术重心是在 Oracle 这边，还是在 AWS 那边？长期看，客户越来越熟悉 AWS 的工具、AWS 的生态，Oracle 数据库慢慢变成 AWS 大盘子里的一道菜。哪天 AWS 把自家数据库的迁移工具做得足够顺滑，客户已经站在 AWS 家门口了，跨出最后一步只会更容易。多云互联可能不是关门，而是把客户送到了别人家门口。
那到底哪种读法对？一个诚实的判断
我的判断是：短期是加固，长期是风险，具体偏哪边，取决于一个可观测的信号——谁在控制那段关系。
看两件事就够了。第一，甲骨文在这套里是被集成方还是集成方。如果客户是"以 Oracle 为核心，顺便用点云资源"，那是加固；如果是"以某家云为核心，顺便挂个 Oracle 数据库"，那 Oracle 就是那道随时可能被换掉的配菜。第二，看定价权在谁手里。进了别人机房，甲骨文的续费涨价还硬不硬气？如果客户一句"再涨我就用 AWS 自家的",甲骨文就得让步，那锁定的成色已经在稀释了。
一句话收束这一章：自治数据库和 Exadata，是把老锁定往更深、更硬里做——省人、焊硬件，抄不动。这两块地基还很硬。真正拿不准的是多云互联。它同时是加固和逃生门，是同一个动作的两面。它救了甲骨文"客户上云就流失"的近渴，代价是把自己从"你必须住我这栋楼"，降级成了"我把家具搬进你选的楼里"。家具再好，房子是别人的。
所以回到本章的标题问题——数据库锁定还硬不硬？地基那两层，硬。往外扩的那层，甲骨文正在用"跟着客户走"换"别被甩掉",这笔交易划不划算，还要几年才见分晓。护城河没塌，但它的形状变了：从一圈围着自家城堡的水，变成了一条跟着客户到处流的河。河还在，只是不再由它决定往哪流。这条线索，我们留到第十五章那张护城河体检表里再一起结账。