看了oceanbase很多优点，请问有哪些缺点呢？
4 个赞
首先，帮助文档不够完善，内容较少，出现问题文档的帮助性有限；其次，集群维护的自动化程度不够，甚至集群重启、停止的自动化脚本都没有，需要直接杀进程。
1 个赞
任何数据库在成长过程中都会有缺点，作为国产数据库的第一集团，OceanBase确实有一些缺点，但这才能不断进步。
很大胆的问题
各个组件工具你中有我我中有你，牵一发动全身，都不是什么大问题，但是用起来就不是很顺手。
尽管 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 工具进行兼容性评估，避免线上故障。
三、运维复杂度较高
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）仍在演进中。
1 个赞
第一点 让我们用起来还是比较痛苦的，还有就是合并会卡住，要处理起来也挺费劲