尽管 OceanBase 是一款高度成熟的企业级原生分布式数据库，具备金融级高可用、强一致性、云原生扩展等优势，但在实际使用中也存在一些架构性限制、运维复杂性和兼容性挑战。以下是基于官方文档和行业实践总结的主要缺点：
一、LSM-Tree 存储引擎的固有局限
OceanBase 采用 LSM-Tree 架构以优化写入吞吐和顺序 I/O 性能，但也带来以下问题：
1. 写入阻塞风险（Write Stall）
在小规格租户或高并发写入场景（如批量导入、ETL 作业）中，内存中的 MemTable 可能迅速达到上限，触发冻结并等待转储（Compaction）。若磁盘转储速度跟不上写入速率，可能导致暂时无法接收新写请求。
缓解措施：
启用写入限速（write_throttling）
扩大租户内存配额
调整 MemTable 占比和转储阈值
参考文档：关于内存
2. 读放大（Read Amplification）
LSM-Tree 的多层结构可能导致一次查询需扫描多个 SSTable 文件，尤其是在数据未命中缓存时，造成较高的 I/O 开销，影响冷查询性能。
尽管从 V4.3.0 版本起引入了列存支持以提升 AP 查询性能，但对于复杂分析型负载仍需谨慎评估 列存。
二、与 MySQL/Oracle 的兼容性差距
虽然 OceanBase 声称“高度兼容”MySQL 5.7/8.0 和 Oracle 模式，但由于底层架构差异，并非所有功能都被完整支持。
不兼容的功能类别包括：
类别
典型缺失或限制
存储引擎
不支持 MyISAM、Memory 引擎；无临时表空间管理
SQL 语法
部分窗口函数、CTE 特性受限；动态 SQL 支持有限
过程性语言
存储过程、触发器支持不完整，调试工具薄弱
系统视图
INFORMATION_SCHEMA 中部分表不可用或字段不同
分区支持
分区类型和维护命令与 MySQL 存在差异
备份恢复
物理备份仅支持归档日志 + 快照，不支持 .ibd 文件级恢复
建议迁移前使用 OBDUMPER/OBLOADER 工具进行兼容性评估，避免线上故障。
参考文档：与 MySQL 兼容性对比
三、运维复杂度较高
1. 部署门槛高
生产环境必须部署至少三节点集群才能实现高可用；
需要配置 OBProxy 实现路由转发，增加架构层级；
对 OS 参数（如 ulimit、hugepage）、网络延迟有严格要求。
单机学习环境虽可运行，但无法体现真实分布式特性。
参考文档：软硬件要求
2. 故障排查难度大
日志分散在多个 OBServer 和 OBProxy 节点；
分布式事务追踪需借助 ob_trx_timeout, sql_audit 等工具联合分析；
Paxos 选主、副本迁移等问题需要深入理解内部机制。
四、性能与延迟问题
1. 跨节点访问延迟
由于数据按 Tablet 分布，热点查询可能涉及跨机访问，导致 RT 上升。特别是在多地域部署中，Zone 间延迟、OBProxy 到 OBServer 延迟会显著影响响应时间。
可通过 SHOW PROXYROUTE 查看 SQL 路由路径，优化亲和性设置。
参考文档：延迟
2. 小规格实例性能受限
对于低配租户（如 2C4G），在高并发场景下容易出现 CPU 或内存瓶颈，难以承载密集事务负载。
五、生态与工具链尚不完善
相比于 MySQL 或 PostgreSQL，OceanBase 的第三方生态仍处于发展阶段：
监控工具主要依赖 OCP 或自研方案；
缺乏成熟的 GUI 开发工具（如 Navicat 完整支持）；
自动化运维平台（如 Ansible 模块、Kubernetes Operator）仍在演进中。