ITPub博客

做索引治理、清理无用索引的时候，大家都会依赖 DBA_INDEX_USAGE 视图，通过索引访问统计，判断索引还有没有业务在访问。

一. ORDER BY LIMIT 优化的核心优势： ORDER BY LIMIT 快不仅仅是因为最终只返回少量结果。真正决定 ORDER BY LIMIT 性能的，往往不是最后返回了几行，而是优化器和执行器能不能借着这个 LIMIT，把大量本来要做的无效工作提前砍掉。几类无效工作包括：扫描了大量最终不会进入结果集的数据；对大量候选行做了完整排序；排序数据太多、行太宽，导致内存压力上升，甚至落盘；

一句话导读：本文用 3 组可复现的实验（10 万行级数据），逐行拆解 OceanBase 执行计划中 NESTED-LOOP JOIN、HASH JOIN、MERGE JOIN 三种连接算子的行为，回答三个问题——优化器为什么这么选？索引如何改变连接算法？拿到一份计划如何快速定位瓶颈？

4.4.2版本mysql租户下普通分区表(非动态维护分区)转换为动态分区表的时候，个别老旧分区不会自动删除维护？

1. 环境信息 本手册适用于以 JDBC 作为底层数据库访问通道的数据迁移、同步或 ETL 工具，典型场景包括：DataXOMS（OceanBase Migration Service）Canal / Flink CDC / Debezium 等基于 JDBC 的数据采集工具自研 Java 数据迁移程序涉及目标数据库类型：OceanBase（MySQL/Oracle 模式）、Oracle、MySQ

一、创建基表、MLOG 与增量刷新物化视图 1.1 创建基表创建两张业务表 orders（订单表）和 items（商品维度表），构成经典的订单-商品关联模型：-- 订单表（50000+ 行）CREATE TABLE orders (    order_id   BIGINT&nb

在 OceanBase 数据库中，自 4.1.0 版本起将主备管理方式下放到租户级别，集群级不再有主备角色概念。为了实现租户级主备的自动路由，OceanBase 引入了服务（Service） 的概念——一个服务下可以有多个同集群或跨集群的租户，用户通过 ODP 使用指定服务名连接数据库时，可自动路由到主租户。

触发场景：OMS 4.3.2 全量迁移，源端和目标端均为 OBOracle 租户，对同一张表进行迁移时，切片索引选择在不同链路配置下表现不一致。

物化视图（Materialized View，以下简称 MV）是数据库中一种将查询结果物理持久化的对象。与普通视图仅存储 SQL 定义不同，MV 将查询执行后的结果数据真正写入磁盘——查询时可直接读取这份数据，而不必重新执行复杂的 JOIN 和聚合运算。这种"以空间换时间"的策略带来显著的性能收益，但同时也伴随着存储开销和刷新维护成本。 在实际业务中，技术团队经常面临以下决策问题：

在 OceanBase 早期版本的 Oracle 兼容模式中，对带有全局索引的 Interval 分区表执行 ALTER TABLE ... TRUNCATE/DROP PARTITION 操作时，存在以下问题：

gh-ost 是 GitHub 开源的 MySQL 在线 DDL 工具，通过创建幽灵表（ghost table）并利用 binlog 回放增量变更，实现低锁、低负载的表结构变更。 OceanBase作为分布式数据库，其 MySQL 兼容模式虽支持大部分 gh-ost 功能，但官方原生 gh-ost 无法直接运行，需使用社区适配版本（如 whhe/gh-ost 的 OB 分支）。

分区交换（Exchange Partition）是一种数据库 DDL 操作，允许用户将一个非分区表的数据与分区表中某个分区（或子分区）的数据进行"互换"。其本质并非真正搬运数据，而是通过交换底层元数据中 Tablet（数据分片）与表的映射关系，实现数据的瞬间"置换"。

文档说明：本文档适用于 OceanBase 4.x 全版本集群，覆盖客户端链路 SSL 加密、集群节点 RPC 链路 SSL 加密、证书生成、权限配置、全流程验证、常见报错排错，为生产环境标准化 SSL 加密落地手册，可直接用于等保合规加固、生产安全整改、日常运维自查。

总结说明 OceanBase 列存通过 Column Group 机制将基线数据按列独立存储，结合增量行存 + 基线列存的 LSM-Tree 架构，在保证 DML 写入性能的同时大幅提升分析型查询（扫描、过滤、聚合）效率，支持纯列存、行列混存及列存索引等多种部署形态。详细说明 概念定义OceanBase 列存（Column Store）是一种将基线数据按列独立存储的存储格式。与传统的行存（Row

1. 概述 在 OceanBase 中建表时，可能会遇到如下报错：模式报错信息Oracle 模式ORA-00600: internal error code, arguments: -5188, Too many partitions (including subpartitions) were definedMySQL 模式ErrorCode = 1499, SQLState = HY000,

OceanBase MySQL 模式不支持 Oracle 的间隔分区（Interval Partition），且动态分区调度不稳定的情况，我们可以通过Event Scheduler + 参数化存储过程实现分区的自动添加与删除，保持分区窗口滚动。本方案提供了通用的存储过程，支持按分钟、小时、天分区，参数化设计可复用到任意符合规范的分区表。

阅读前置知识: 了解 OB 多租户架构、Zone/Unit/Tenant 资源模型、LS(Log Stream) 与 Tablet 概念、Compaction 机制（major/minor/mini）、SQL 引擎执行链路（SQE → 优化器 → 执行引擎 → 存储引擎）。

生产环境经常遇到内存类报错，同样是 OOM，-11049 和‑4013 根因、排查路径、处理方案完全不一样。本文结合真实生产案例，帮大家分清两个报错，掌握完整定位与优化手段。

在OceanBase的Mysql租户模式下，使用information_schema.TABLES不能查到自增列下一个起点值，如何去查询自增列的值？

版本要求 OBProxy （建议 ≥ 4.3.2）适用场景 单 OBProxy 入口、事务内强读走 Leader、事务外只读走弱读并路由到 Follower。一、背景与原理 1.1 读写分离机制OB 通过弱一致性读将只读请求路由到 Follower 副本，写请求始终走 Leader 强一致性。ODP 提供两种自动读写分离模式：模式参数行为推荐度基础读写分离enable_read_write_spl