大对象（LOB，Large Object）是指数据库中存储的超大文本或二进制数据，如文本文档、图片、音频等。在数据库应用中，大对象常用于存储非结构化数据，为应用提供完整的数据存储解决方案。
OceanBase 数据库支持两种大对象存储方式：
👉 行内存储：数据直接存储在数据行中
优势：读取性能好，无需额外 I/O。
劣势：占用主表空间，影响其他列的访问效率。
👉 行外存储：数据存储在独立的对象存储中
优势：节省主表空间，适合存储超大对象。
劣势：需要额外 I/O，读取性能相对较差。
在实际应用中，行外存储的大对象（如 JSON）面临以下主要性能挑战：
👉 读取性能：对于行外存储的大对象，每次访问都需要额外的 I/O 操作。
👉 JSON 类型特殊性：需要解析结构信息，开销更大。频繁读写场景下性能表现不优。
注意：处理 LOB 字段开销较大的问题已在 4.2.2、4.3.1 及之后的版本中进行了优化。
一、性能诊断和优化方案
（一）识别行外存储性能问题
行外储存的性能不优时，主要特征有两个：
🚩 查询延迟明显增加
🚩 I/O 等待时间占比高
在性能诊断时，可以使用 EXPLAIN 分析执行计划，或者监控 I/O 相关性能指标。
（二）性能优化方案
1、采取智能存储策略
在处理大字段数据时，性能下降的主要原因是数据存储在行外，导致访问时的额外开销。可通过配置行内存储阈值，平衡存储空间和访问性能。具体可用方法如下：
通过 ob_default_lob_inrow_threshold 系统变量调大行内存储阈值，以避免行外存储。并重新建表进行测试。
示例如下：
-- 设置行内存储阈值为8192字节SET ob_default_lob_inrow_threshold = 8192;
🧡注意：
修改 ob_default_lob_inrow_threshold 变量的值，不会影响已经创建表的行内存储阈值，只会影响新创建且没有指定行内阈值的表。
2、选择更合适的数据类型建表
在实践中，我们发现一些业务场景在使用 LONGTEXT 和 JSON 类型存储数据时，会出现存储效率低下和访问速度慢的问题，尤其是在不需要复杂查询的情况下。实际上，对于不需要进行 JSON 计算的纯 JSON 数据存储，可以考虑使用 VARCHAR 或 TEXT 类型。在数据量较大时，使用更小的存储类型可以减少内存占用和提高访问速度。
3、升级到合适的 OceanBase 版本
旧版本的 OceanBase 可能会出现无法充分利用新特性的情况。在高并发读写场景下，可以通过升级 OceanBase 版本进行性能调优。具体建议升级到 4.2.2、4.3.1 以及之后的版本，这些版本优化了行外储存场景，可以提高大对象和 JSON 的读写性能并降低延迟。
二、大对象存储性能示例
（一）测试场景
假设测试场景如下：
CPU架构：x86_64
CPU：4 核
OBServer版本号：4.2.1.7
（二）问题描述
假设这是一个带有 JSON 字段的主键查询场景，存在慢查询。具体 SQL 和表 DDL 如下：
SELECT*FROM`t2_act`WHERE`id` = 1AND `del_at` IS NULLLIMIT1;CREATE TABLE `t2_act` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`title` varchar(128) COLLATE utf8mb4_unicode_ci NOT NULL,`page_setting` JSON DEFAULT NULL,`rule_setting` JSON DEFAULT NULL,`extend` JSON DEFAULT NULL,`del_at` timestamp NULL DEFAULT NULL,PRIMARY KEY (`id`));
通过如下语句可以查询 JSON 字段的数据长度信息：
SELECT /*+parallel(12)*/ max(lengh(page_setting)), min(length(rule_setting)), avg(length(extend)) FROM t2_act;+--------------------------+--------------------------+--------------------+| max(lengh(page_setting)) | min(lengh(rule_setting)) | avg(lengh(extend)) || 17736 | 928 | 113084 |+--------------------------+--------------------------+--------------------+1 row in set(0.196 sec)
可见，性能不佳的原因为该查询是涉及 JSON 列的查询，同时 JSON 列数据本身的长度超过了 LOB 行内存储的阈值，导致扫描 JSON 列数据需要额外的 I/O，进而导致 RT（响应时间）明显增加。
（三）优化方案
1️⃣ 升级到 OceanBase 4.2.2 及以上版本，以优化开销。
2️⃣ 调大行内阈值避免行外存储，调阈值后重建表格，使得数据按照新的存储机制存储。
3️⃣ 由于此场景不需要对 JSON 数据进行计算，只是纯粹地存储 JSON 数据，判断可以直接使用 Varchar 或 Text 类型进行存储。
在实际应用中，通过合理配置行内存储阈值、选择合适的数据类型以及升级到最新版本，可以有效提升大对象和 JSON 数据的存储与查询效率。通过这些优化策略，OceanBase 能够更好地满足高并发、大数据量的应用场景需求，为用户提供更高效的数据存储解决方案。
