Oracle
银行核心系统的老牌商业库，稳，但贵
Oracle 是商业数据库里的标杆：RAC 让多台机器共享同一个库、PL/SQL 把逻辑写在库里、AWR 能直接告诉你哪条 SQL 在拖后腿。它的能力上限很高，代价是授权费和运维门槛——一套核心库的年费常常比整个技术团队的工资还高。
它解决什么问题
银行、运营商的核心账务要求 7×24 不中断、单库几个 TB、还要满足审计和容灾合规。开源库在十年前扛不住这种要求，只能上商业库。
真实场景：典型场景：银行核心系统两节点 RAC，一个节点挂了业务无感；日终批量用 PL/SQL 存储过程跑，归档日志保留 30 天供审计回溯。
核心概念
每个概念一句话 + 一个类比。点击卡片看更详细的解释。
实例与数据库
实例是内存 + 进程，数据库是磁盘上的文件，两者分离
类比：图书馆（数据库）和馆长团队（实例），团队换了书还在
看概念详情表空间
表的逻辑容器，底下对应若干个数据文件，可以单独扩容和备份
类比：仓库里的分区，A 区放原料，B 区放成品
看概念详情SGA / PGA
SGA 是实例共享的内存（缓存、共享池），PGA 是每个会话私有的
类比：SGA 是公共阅览室，PGA 是每个人的书桌
看概念详情RAC
多台机器共享同一份存储，同时读写一个库，坏一台不停机
类比：多个收银台对着同一个仓库，坏一个不影响营业
看概念详情UNDO
记录数据修改前的样子，用于回滚和一致性读
类比：撤销键，随时能退回上一步
看概念详情数据流转动画
跟着步骤看一条数据从进入系统到被处理完的完整路径，可以暂停、重播和调速。
一条 UPDATE 在 Oracle 里是怎么走的
← 左右滑动查看完整流程图 →
应用连到 SCAN 地址，监听器挑一个负载低的实例，把连接交给它的服务进程。
提示：注意 UNDO 和 Redo 的分工：UNDO 保证能回滚和一致性读，Redo 保证崩溃能恢复。 悬停图中的节点可以看概念解释。
优劣势
短句说清适合什么、不适合什么，选型时先看这一栏。
- RAC 真正做到了多活，单节点故障业务几乎无感
- 优化器与执行计划极其成熟，复杂 SQL 表现稳定
- PL/SQL、物化视图、分区表、AWR 等企业级能力齐全
- 商业支持兜底，出问题有人负责
- 授权费 + 服务费昂贵，扩容成本高
- 运维门槛高，参数、表空间、RAC 都有专门的坑
- 云原生与容器化支持较弱，弹性差
- 人才和生态集中在金融、运营商，互联网公司用得少
常见使用场景
每个场景都配一句「为什么用它」。
银行核心账务
账户、流水、总账，要求零数据丢失和 7×24 可用。
为什么用它：RAC + Data Guard + 归档日志，容灾链路是现成的。
运营商计费与结算
海量话单入库，日终批量跑存储过程结算。
为什么用它：分区表 + PL/SQL 批处理 + 并行执行，跑批能力经过验证。
历史系统与合规审计
需要保留多年、可回溯、有审计要求的数据。
为什么用它：闪回查询、归档日志、审计视图都是内建能力。
同类对比
和同赛道的组件并排看，差异一目了然。
选型顺序应该是：先看是不是单机嵌入式（是就 SQLite），再看预算和合规（要商业兜底就 Oracle），最后在 MySQL 和 PostgreSQL 之间按“功能复杂度 vs 生态成熟度”取舍。三者都能存好数据，差别在边界。
常见问题
上手第一个月最容易卡住的地方。
Q1Oracle 和 MySQL 最大的区别是什么？
架构上：Oracle 是实例与数据库分离、共享存储多活（RAC），MySQL 是单机主从。能力上：Oracle 的优化器、分区、物化视图、PL/SQL 更完整，适合复杂批处理和核心系统；MySQL 更轻、更便宜、生态更互联网化。选型本质是预算和场景，不是技术优劣。
Q2RAC 是不是就高枕无忧了？
不是。RAC 解决的是实例级故障，但共享存储仍然是单点，必须配 Data Guard 或存储双活。另外 RAC 的 Cache Fusion 对网络延迟敏感，跨机房部署基本不可行，同城双活要靠 Data Guard 而不是 RAC。
Q3为什么提交后数据文件里还没有？
因为提交只保证 Redo 落盘，数据块还是内存里的脏页。这时断电也不会丢——重启时 Oracle 会用 Redo 重放。理解这一点，才能明白“Redo 是持久化的真正边界”。
Q4现在还有必要学 Oracle 吗？
看你所在的行业。金融、运营商、大型 ERP 里 Oracle 仍然是主力，相关岗位薪资不低；纯互联网业务基本是 MySQL / PostgreSQL。学它的价值在于理解关系库的完整形态——执行计划、锁、一致性读这些概念在别的库里同样适用。