都在说优点，和国外数据库对比缺点在哪
4 个赞
主要体现在稳定性和性能上的差异吧
1 个赞
OceanBase 核心不足与实战痛点（基于 4.x 版本一线落地总结）
一、底层 LSM-Tree 存储引擎天生缺陷（架构硬伤，无法彻底规避）
读放大，冷查询性能弱
数据分层存储在多层 SSTable，无缓存的冷查询需要扫描多层文件 IO；单节点、单表少量数据场景，简单点查性能不如单机 MySQL，小体量业务纯读负载会明显吃亏OceanBase。
Write Stall 写入阻塞风险
MemTable 写满后触发 Compaction 合并磁盘文件，磁盘 IO 跟不上写入速度时，直接限流、阻塞新写入；批量导入、ETL、高峰突写场景极易出现卡顿，需要大量参数调优缓解，无法完全根除。
Compaction 抢占资源
后台合并任务会抢占 CPU、磁盘 IO，业务高峰期容易和线上读写争抢资源，低配机器 / 小租户影响极大。
二、分布式架构带来的性能与延迟短板
跨分区 / 跨节点查询延迟高
数据按 Tablet 打散在多台服务器，关联查询、范围扫描一旦跨节点，网络开销会大幅拉高 RT；分布式 Join 优化器偏保守，复杂多表关联极易产生低效执行计划，必须手动加 Hint 干预。
多副本 Paxos 带来提交延迟
强一致事务需要多数副本确认，同城三副本会增加 2~5ms 提交延迟；三地五中心跨城部署时，事务延迟增加 6~10ms，高频低延迟业务（毫秒级实时交易）体验下降明显OceanBase。
热点分片瓶颈无解
极端热点（如单一用户、活动大订单）全部落在单个 Tablet，无法自动拆分热点分片，只能业务侧做哈希分表改造，数据库层无自动打散能力。
小规格租户资源利用率差
2C4G、4C8G 低配租户在高并发下极易内存 / CPU 打满，内存隔离、Compaction、日志占用大量资源，同等配置承载能力远弱于 MySQL 单机。
三、MySQL/Oracle 兼容性不完整，迁移改造成本高
MySQL 模式兼容短板
不支持 MyISAM、Memory 引擎，无内存临时表；空间数据类型、部分动态 SQL、复杂 CTE 窗口函数支持残缺OceanBase。
存储过程、触发器、函数调试工具薄弱，大量复杂 PL 代码需要重写；INFORMATION_SCHEMA系统视图字段、表结构和 MySQL 不一致，中间件、监控工具适配工作量大。
分区能力缺失：不支持间隔分区、子分区，分区维护语法和 MySQL 差异巨大；主键不支持 INT 自动扩 BIGINT，字段类型转换限制多OceanBase。
细节行为不一致：datetime 默认微秒精度（MySQL 是秒）、字符集默认 utf8mb4、锁机制、隔离级细节差异，迁移后大量 SQL 隐性报错，必须全量 SQL 兼容性扫描。
Oracle 模式兼容短板
大量老式 Oracle 特性缺失：不支持公元前时间、间隔分区、复杂存储过程语法、老旧分析函数；批量迁移 Oracle 核心系统改造量极大。
没有完整 Oracle 生态配套，PLSQL 调试、闪回查询、高级审计等企业级特性阉割。
四、部署运维门槛极高，人力与硬件成本高
基础部署复杂，无法轻量化使用
生产高可用最低 3 台物理机集群，必须搭配 OBProxy 代理层，架构多两层组件（OBServer+OBProxy+OCP 管控）；单机 Docker 仅适合学习，不能用于业务验证OceanBase。
对服务器硬件、OS 参数硬性要求：大页内存、ulimit、网络带宽、磁盘 IOPS 严格限制，普通云服务器低配机型极易出现稳定性问题。
故障排查难度陡增
日志分散在数十个节点、OBProxy、OCP 多组件；分布式事务、Paxos 选主、副本迁移、分片均衡问题，必须深入底层分布式原理才能定位，普通 MySQL DBA 无学习无法独立运维。
自动化运维工具依赖商业版
社区版无完善可视化 OCP 管控平台，集群重启、扩容、备份、告警缺少自动化脚本；自建监控需要对接数十类指标，Prometheus 集成成本高。企业版 OCP 付费，中小企业额外增加软件采购成本。
人力成本高
必须专职分布式 DBA 维护，普通开发兼职无法搞定调优、故障处理；对比 MySQL，同等业务规模需要 1~2 名专职维护人员，长期人力开销大。
集群扩容有隐性成本
水平扩容虽然业务无感知，但新增机器需要预留内存、磁盘做副本冗余，3 副本架构硬件资源冗余率 200%，小规模业务硬件浪费严重。
五、生态工具链成熟度远低于 MySQL/PostgreSQL/Oracle
中间件、ORM、数据同步工具适配不完善
MyBatis、Sharding-JDBC、Canal、Debezium 等主流组件适配补丁多，部分 CDC 同步功能不稳定；开源社区适配方案少，踩坑只能翻官方小众文档。
开源社区体量小，问题解决方案少
MySQL 几十年社区积累，几乎所有报错都有现成方案；OceanBase 社区案例集中在金融、互联网大厂，中小企业小众场景问题很难搜到答案，大部分问题依赖官方工单支持。
数据分析配套薄弱
虽然支持 HTAP 列存，但复杂 OLAP 多维分析性能不如 ClickHouse、Spark；报表、数仓场景仍需要单独搭建分析引擎，无法完全替代专业数仓。
六、商业与场景局限性
小规模业务不划算
单体小型 Web、中小企业管理系统、低并发内部系统，用 OceanBase 属于 “杀鸡用牛刀”：部署复杂、资源浪费、运维成本远超单机 MySQL，完全没有收益。
多租户商业许可限制
社区版多租户能力有限，企业级资源隔离、权限管控需要购买商业授权；如果需要隔离多个客户业务，软件授权成本显著提升。
离线批处理场景劣势
大批量离线 ETL、全表统计任务，LSM 树合并会严重干扰在线业务，很难做到离线任务与在线业务资源完全隔离。
跨城容灾取舍矛盾
追求城市级零数据丢失（RPO=0）就要接受事务延迟上涨；想要低延迟只能同城部署，无法满足异地灾备硬性合规要求，二者无法兼得。
4 个赞
支持一下
我觉得用户场景经验积累不足是个长期要补的课
1 个赞
深刻体会啊
从23年开始，数据库、操作系统等开始陆续搞国产化，对这个说法深有体会啊。要相信，不足只是暂时的，目前国产库使用占比越来越多了
1 个赞
缺点都有， 一个运行了几十年，一个才几年；一个是国外的， 一个是国内的；一个成熟，一个幼稚。不过一个是别人家的孩子，一个是自家的。 多忍忍。
更稳定吧