最新

ORDER BY LIMIT 为什么这么快?关键不在少返回几行,而在优化器砍掉了什么
ORDER BY LIMIT 快不仅仅是因为最终只返回少量结果。真正决定 ORDER BY LIMIT 性能的,往往不是最后返回了几行,而是优化器和执行器能不能借着这个 LIMIT,把大量本来要做的无效工作提前砍掉。
看懂 OceanBase 执行计划:三种连接算法的原理、实验与选型
一句话导读:本文用 3 组可复现的实验(10 万行级数据),逐行拆解 OceanBase 执行计划中 NESTED-LOOP JOIN、HASH JOIN、MERGE JOIN 三种连接算子的行为,回答三个问题——优化器为什么这么选?索引如何改变连接算法?拿到一份计划如何快速定位瓶颈?
OceanBase 非动态分区表转动态分区,过期的分区不会自动删除?
4.4.2版本mysql租户下普通分区表(非动态维护分区)转换为动态分区表的时候,个别老旧分区不会自动删除维护?
JDBC 报错 No more data to read from socket 排查手册
本手册适用于以 JDBC 作为底层数据库访问通道的数据迁移、同步或 ETL 工具,典型场景包括:
OceanBase 物化视图实践:增量刷新、并行调优、MLOG 机制拆解
创建两张业务表 orders(订单表)和 items(商品维度表),构成经典的订单-商品关联模型:
OceanBase ODP 主备租户读写分离配置指南
在 OceanBase 数据库中,自 4.1.0 版本起将主备管理方式下放到租户级别,集群级不再有主备角色概念。为了实现租户级主备的自动路由,OceanBase 引入了服务(Service) 的概念——一个服务下可以有多个同集群或跨集群的租户,用户通过 ODP 使用指定服务名连接数据库时,可自动路由到主租户。
OMS 4.3.2 迁移坑:OBOracle 同名 PK/UK 引发全量迁移错误
触发场景:OMS 4.3.2 全量迁移,源端和目标端均为 OBOracle 租户,对同一张表进行迁移时,切片索引选择在不同链路配置下表现不一致。
使用OceanBase物化视图时,你可能会遇到需要考虑的场景决策
物化视图(Materialized View,以下简称 MV)是数据库中一种将查询结果物理持久化的对象。与普通视图仅存储 SQL 定义不同,MV 将查询执行后的结果数据真正写入磁盘——查询时可直接读取这份数据,而不必重新执行复杂的 JOIN 和聚合运算。这种"以空间换时间"的策略带来显著的性能收益,但同时也伴随着存储开销和刷新维护成本。 在实际业务中,技术团队经常面临以下决策问题:
性能暴涨2000倍!OceanBase 4.4.2.1 解决分区DDL业务雪崩难题
在 OceanBase 早期版本的 Oracle 兼容模式中,对带有全局索引的 Interval 分区表执行 ALTER TABLE ... TRUNCATE/DROP PARTITION 操作时,存在以下问题:
OceanBase 4.3 适配 gh-ost 在线无锁 DDL 指南
gh-ost 是 GitHub 开源的 MySQL 在线 DDL 工具,通过创建幽灵表(ghost table)并利用 binlog 回放增量变更,实现低锁、低负载的表结构变更。 OceanBase作为分布式数据库,其 MySQL 兼容模式虽支持大部分 gh-ost 功能,但官方原生 gh-ost 无法直接运行,需使用社区适配版本(如 whhe/gh-ost 的 OB 分支)。