可以参考这个章节：
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002014002
根据文档库中的信息，对于非分区表（即普通表），其数据和索引的存储方式与分区表有所不同。具体来说：
普通表的数据和索引存储
-
非分区表（普通表）：
- 对于非分区表，OceanBase 数据库并没有将表划分为多个分区的概念。因此，整个表的数据和索引都存储在同一个逻辑结构中。
- 在这种情况下，“绑定”并不是指分区内的绑定，而是指整个表的数据和索引在一个统一的存储空间中进行管理和存储。
-
局部索引 vs 全局索引：
- 局部索引：通常用于分区表，索引和表的数据会绑定在同一分区内部存储。但对于非分区表，由于不存在分区的概念，所以局部索引的概念不适用。
- 全局索引：可以跨多个分区或整个表范围创建。对于非分区表，全局索引同样适用于整个表的数据。
-
存储结构：
- OceanBase 数据库使用 LSM-Tree 结构来管理数据。每个表的数据和索引都会被存储在 MemTable 和 SSTable 中。
- 对于非分区表，其数据和索引会共同存在于这些存储结构中，但并不涉及分区的概念。
总结
对于普通表 t1，其数据和索引确实是在一个统一的存储空间中进行管理和存储的。虽然我们可以说它们是“绑定”的，但这并不是指分区内的绑定，而是指整个表的数据和索引在一个统一的逻辑结构中管理。具体来说，t1 的数据和索引会共同存在于 MemTable 和 SSTable 中，而不会像分区表那样有明确的分区概念。
希望以上解释能够澄清您的疑问。如果您还有其他问题，欢迎继续提问！
更多信息请参考：
具体信息可参考以下文档:
详情请参考:
根据文档库中的信息，分区表的全局索引和分区表的数据并不是绑定在一个统一的存储空间内管理的。实际上，它们有不同的存储和管理方式。具体来说：
分区表的全局索引与数据的关系
-
全局索引的独立性：
- 全局索引有自己独立的分区规则，可以定义自己的分区策略，不一定与主表的分区规则相同。
- 全球索引可以有自己的分区模式，既可以选择非分区模式也可以选择分区模式；在分区模式中，分区的方式既可以和主表相同也可以不同。
- 全局索引可以看作是另一张独立的表，占用额外的分区配额，并且可以在不同的节点上存储。
-
物理位置分离：
- 由于全局索引的分区规则和主表的分区规则不一定相同，因此在分布式环境中，索引数据和主表数据存储的位置也无法保证始终在一起。
- 这种分离会导致读写操作时引入 RPC（远程过程调用）代价和分布式事务的代价。例如，当主表的分区和全局索引的分区不在同一个物理位置上，
TABLE SCAN算子执行全局索引表扫描时就会包含一次 RPC 操作到远端机器上去获取主表数据。
-
维护代价：
- 全局索引相比局部索引有更高的维护代价，因为数据的增删改都需要维护全局索引，可能会产生分布式事务，影响系统的写入性能。
文档依据
-
片段标题: OceanBase 数据库性能的影响因素 → 资源分配 → 局部索引和全局索引 → 全局索引：
“与局部索引相比，由于全局索引有独立的分区规则，因此索引表中一个分区的索引值可能对应着主表的多个分区内的数据。由于索引的分区规则和主表的分区规则不一定相同，因此在分布式环境中，索引数据和主表数据存储的位置也无法保证始终在一起，这不可避免的会引入读写的 RPC 代价和分布式事务的代价。”
-
片段标题: 使用 OceanBase 数据库分区表进行水平拆分 → 分区表 → 分区表的索引：
“如果分区表的索引不分区，就是一个全局索引（
GLOBAL），是一个独立的分区，索引数据覆盖整个分区表。”
总结
对于分区表的全局索引和分区表的数据：
- 它们并不是绑定在一个统一的存储空间内管理。
- 全局索引具有独立的分区规则，可以与主表的分区规则不同。
- 全局索引和主表数据的物理位置可能不同，导致读写操作时引入额外的 RPC 和分布式事务代价。
- 全局索引的维护代价较高，建议仅在必要时使用。
希望以上解释能够澄清您的疑问。如果您还有其他问题，欢迎继续提问！
更多信息请参考：
OceanBase 数据库性能的影响因素
OceanBase 数据库性能的影响因素 → 资源分配 → 局部索引和全局索引
OceanBase 数据库术语
具体信息可参考以下文档:
转储和合并概述
OceanBase 数据库性能的影响因素
存储架构概述
详情请参考:
表存储
使用 MySQL 租户做常见数据库开发
分布式执行和并行查询
体验并行导入和数据压缩
表概述
MemTable
创建数据库
分布式数据库对象概述
发现磁盘的静默错误
更多信息请查看:
对于普通表（非分区表），其数据和索引确实是在一个统一的存储空间中进行管理和存储。为了更好地理解“统一的存储空间”，我们可以从以下几个方面来详细解释：
1. 逻辑上的统一管理
-
整体性：在 OceanBase 数据库中，普通表的数据和索引被视为一个整体进行管理。这意味着数据库系统会将表的数据和索引作为一个单元来进行操作，如备份、恢复、转储等。
-
无分区概念：与分区表不同，普通表没有分区的概念，因此它的所有数据和索引都属于同一个逻辑结构。这使得它们可以在同一个上下文中被处理，而不需要考虑跨分区的问题。
2. 物理存储层面
-
LSM-Tree 结构：OceanBase 使用 LSM-Tree（Log-Structured Merge Tree）结构来管理数据。每个表的数据和索引会被存储在 MemTable 和 SSTable 中。
-
MemTable：是内存中的数据结构，用于存储最近写入的数据。当 MemTable 达到一定阈值时，会触发转储操作，将数据从内存转存到磁盘上的 SSTable。
-
SSTable：是磁盘上的静态数据文件，存储已经转储的数据。随着数据的不断写入和转储，可能会生成多个 SSTable 文件。这些 SSTable 文件共同构成了表的数据和索引的持久化存储。
-
-
共存于同一存储单元：虽然数据和索引在物理上可能分布在多个 SSTable 文件中，但这些文件都属于同一个表的存储空间。也就是说，表的数据和索引的 SSTable 文件会存储在同一组存储单元中，通常位于相同的目录或文件系统路径下。
3. 查询和维护
-
一致性：由于数据和索引在一个统一的存储空间中管理，查询操作可以更高效地访问相关数据和索引。例如，在执行查询时，数据库可以直接从同一个存储单元中读取数据和索引，减少了跨存储单元的开销。
-
维护操作：诸如合并（Compaction）、清理（Cleanup）等维护操作也可以针对整个表的数据和索引一起进行，确保数据的一致性和完整性。
4. 具体实现细节
- 表空间：虽然 OceanBase 数据库并非一个多数据文件的数据库系统，但为了兼容 Oracle 数据库，它引入了表空间的概念。可以简单理解为表空间是一组表的集合。对于普通表，其数据和索引会存储在同一个表空间内，进一步体现了“统一的存储空间”的概念。
总结
对于普通表 t1，其数据和索引确实在一个统一的存储空间中进行管理和存储。这里的“统一的存储空间”指的是：
- 逻辑上：表的数据和索引作为一个整体进行管理，没有分区的概念。
- 物理上：数据和索引共同存在于 MemTable 和 SSTable 中，这些文件属于同一个表的存储单元。
- 操作上：查询和维护操作可以高效地对整个表的数据和索引进行处理，确保一致性和性能。
希望以上解释能够帮助您更好地理解“统一的存储空间”的概念。如果您还有其他问题，欢迎继续提问！
更多信息请参考：
具体信息可参考以下文档:
- 转储和合并概述
- OceanBase 数据库性能的影响因素
- 存储架构概述
- 表存储
- 创建数据库
- 分布式数据库对象概述
具体信息可参考以下文档:
根据文档库中的信息，对于普通表（非分区表）的数据和索引的存储方式，可以总结如下：
普通表的数据和索引存储
-
数据和索引是否独立存储在不同的 Table Store 中？
- 数据和索引共享同一个 Table Store：对于普通表，其数据和所有索引（包括局部索引和全局索引）通常会共享同一个 Table Store。这意味着它们并不是完全独立存储的，而是在同一个逻辑存储单元中进行管理和存储。
-
具体实现细节
-
统一管理：普通表的数据和索引被视为一个整体进行管理。OceanBase 数据库使用 LSM-Tree 结构来管理数据，每个表的数据和索引会被存储在 MemTable 和 SSTable 中。
-
MemTable 和 SSTable：新写入的数据首先存储在 MemTable 中，当 MemTable 达到一定阈值时，会触发转储操作，将数据从内存转存到磁盘上的 SSTable。这些 SSTable 文件共同构成了表的数据和索引的持久化存储。
-
-
物理存储层面
- 共存于同一存储单元：虽然数据和索引在物理上可能分布在多个 SSTable 文件中，但这些文件都属于同一个表的存储空间。也就是说，表的数据和索引的 SSTable 文件会存储在同一组存储单元中，通常位于相同的目录或文件系统路径下。
-
查询和维护
-
一致性：由于数据和索引在一个统一的存储空间中管理，查询操作可以更高效地访问相关数据和索引。例如，在执行查询时，数据库可以直接从同一个存储单元中读取数据和索引，减少了跨存储单元的开销。
-
维护操作：诸如合并（Compaction）、清理（Cleanup）等维护操作也可以针对整个表的数据和索引一起进行，确保数据的一致性和完整性。
-
总结
对于普通表：
- 数据和索引不是独立存储在不同的 Table Store 中，而是共享同一个 Table Store。
- 数据和索引共同存在于 MemTable 和 SSTable 中，这些文件属于同一个表的存储单元。
- 查询和维护操作可以高效地对整个表的数据和索引进行处理，确保一致性和性能。
因此，普通表的数据和索引并不是各自独立存储在一个单独的 Table Store 内，而是共享同一个 Table Store 进行管理和存储。
希望以上解释能够帮助您更好地理解普通表的数据和索引存储机制。如果您还有其他问题，欢迎继续提问！
更多信息请参考：
- OceanBase 数据库性能的影响因素
- OceanBase 数据库术语
- 存储架构概述
具体信息可参考以下文档:
- 转储和合并概述
- OceanBase 数据库性能的影响因素
- 存储架构概述
- 表存储
- 创建数据库
- 分布式数据库对象概述
具体信息可参考以下文档:
- OceanBase 术语
- 表概述
- 关于外表
- 表存储
- oceanbase.DBA_OB_TABLE_LOCATIONS
- 表级字符集和字符序
更多信息请查看:
根据文档库中的信息，可以详细解释分区表和普通表的数据及索引存储方式。具体来说：
分区表的存储
-
分区表的每个分区数据独立存储在一个 Table Store 内
是的，分区表的每个分区数据确实独立存储在一个 Table Store 内。这意味着每个分区的数据在物理上是分开存储的，每个分区有自己的 MemTable 和 SSTable 文件。这种设计使得分区表能够更好地支持分布式存储和并行处理。
-
分区表的本地索引的每个分区独立存储在一个 Table Store 内
是的，分区表的局部索引（即本地索引）的每个分区也独立存储在一个 Table Store 内。局部索引与主表的分区绑定在一起，因此每个分区的局部索引数据也会与该分区的数据一起存储在同一个 Table Store 中。这确保了局部索引和主表数据的物理位置一致，减少了查询时的跨节点通信开销。
普通表的存储
-
普通表的数据独立存储在一个 Table Store 内
是的，普通表（非分区表）的数据独立存储在一个 Table Store 内。由于普通表没有分区的概念，整个表的数据会作为一个整体存储在同一个 Table Store 中，包括其 MemTable 和 SSTable 文件。
-
普通表的每个索引独立存储在一个 Table Store 内
对于普通表的索引，情况有所不同：
-
局部索引：对于普通表，局部索引的概念不适用，因为普通表没有分区。因此，普通表的索引通常是指全局索引。
-
全局索引：全局索引可以看作是一个独立的对象，它有自己的 MemTable 和 SSTable 文件，但这些文件仍然属于同一个逻辑存储空间（即同一个表）。全局索引并不单独占用一个 Table Store，而是与表的数据共同存在于同一个存储单元中。不过，全局索引的数据可能会分布在不同的节点上，特别是在分布式环境中。
-
总结
-
分区表：
- 每个分区的数据独立存储在一个 Table Store 内。
- 每个分区的局部索引也独立存储在一个 Table Store 内，与该分区的数据绑定在一起。
-
普通表：
- 整个表的数据独立存储在一个 Table Store 内。
- 索引（通常是全局索引）与表的数据共同存在于同一个存储单元中，但全局索引的数据可能会分布在不同的节点上。
希望以上解释能够澄清您的疑问。如果您还有其他问题，欢迎继续提问！
更多信息请参考：
OceanBase 数据库性能的影响因素
OceanBase 数据库术语
存储架构概述
具体信息可参考以下文档:
转储和合并概述
OceanBase 数据库性能的影响因素
存储架构概述
表存储
创建数据库
分布式数据库对象概述
具体信息可参考以下文档:
OceanBase 术语
表概述
关于外表
表存储
oceanbase.DBA_OB_TABLE_LOCATIONS
表级字符集和字符序
文档依据
-
片段标题: OceanBase 数据库性能的影响因素 → 资源分配 → 局部索引和全局索引
- 描述了局部索引与主表分区绑定在一起，所有基于局部索引的 SQL 基本都是本地执行。
-
片段标题: 使用 OceanBase 数据库分区表进行水平拆分 → 分区表 → 分区表的索引
- 解释了分区表的索引如何与主表分区绑定或独立存在。
-
片段标题: OceanBase 数据库性能的影响因素 → 资源分配 → 局部索引和全局索引 → 局部索引
- 描述了局部索引与主表分区的关系，以及它们的存储特性。
检索到的文档如下:
对于分区表的全局索引，其每个分区是否独立存储在一个 Table Store 内，取决于全局索引的分区规则和存储机制。根据文档库中的信息，可以总结如下：
分区表的全局索引存储
全局索引的分区规则与存储特性
-
独立分区规则：
- 全局索引有自己独立的分区规则，可以定义自己的分区策略，不一定与主表的分区规则相同。
- 每个全局索引分区可以看作是另一张独立的表，占用额外的分区配额，并且可以在不同的节点上存储。
-
物理位置分离：
- 由于全局索引的分区规则和主表的分区规则不一定相同，因此在分布式环境中，索引数据和主表数据存储的位置也无法保证始终在一起。
- 这种分离会导致读写操作时引入 RPC（远程过程调用）代价和分布式事务的代价。例如，当主表的分区和全局索引的分区不在同一个物理位置上，
TABLE SCAN算子执行全局索引表扫描时就会包含一次 RPC 操作到远端机器上去获取主表数据。
-
Table Store 的分配：
- 每个全局索引分区独立存储：每个全局索引分区确实会独立存储在一个 Table Store 内。这意味着每个全局索引分区的数据和索引都会有自己的 MemTable 和 SSTable 文件，这些文件属于该分区的存储单元。
- 跨节点存储：不同全局索引分区可以分布在不同的节点上，以实现负载均衡和高可用性。
文档依据
-
片段标题: OceanBase 数据库性能的影响因素 → 资源分配 → 局部索引和全局索引 → 全局索引：
“与局部索引相比，由于全局索引有独立的分区规则，因此索引表中一个分区的索引值可能对应着主表的多个分区内的数据。由于索引的分区规则和主表的分区规则不一定相同，因此在分布式环境中，索引数据和主表数据存储的位置也无法保证始终在一起，这不可避免的会引入读写的 RPC 代价和分布式事务的代价。” -
片段标题: 使用 OceanBase 数据库分区表进行水平拆分 → 分区表 → 分区表的索引：
“如果分区表的索引不分区，就是一个全局索引（GLOBAL），是一个独立的分区，索引数据覆盖整个分区表。”
总结
对于分区表的全局索引：
- 每个全局索引分区独立存储在一个 Table Store 内。这意味着每个全局索引分区的数据和索引都有自己的 MemTable 和 SSTable 文件，这些文件属于该分区的存储单元。
- 跨节点存储：不同全局索引分区可以分布在不同的节点上，以实现负载均衡和高可用性。
- 维护代价较高：由于全局索引的分区规则独立于主表，可能会引入额外的 RPC 和分布式事务代价，因此建议仅在必要时使用全局索引。
希望以上解释能够帮助您更好地理解分区表的全局索引存储机制。如果您还有其他问题，欢迎继续提问！
更多信息请参考：
具体信息可参考以下文档:
具体信息可参考以下文档:
详情请参考:
根据文档库中的信息，关于分区表的全局索引存储方式，可以总结如下：
分区表的全局索引存储
全局索引的每个分区是否独立存储在一个 Table Store 内？
不是。全局索引的每个分区并不是独立存储在一个单独的 Table Store 内。具体来说：
-
独立性与绑定：
- 全局索引有自己独立的分区规则，可以定义自己的分区策略，不一定与主表的分区规则相同。
- 全局索引可以有自己的分区模式，既可以选择非分区模式也可以选择分区模式；在分区模式中，分区的方式既可以和主表相同也可以不同。
- 全局索引可以看作是另一张独立的表，占用额外的分区配额，并且可以在不同的节点上存储。
-
物理位置分离：
- 由于全局索引的分区规则和主表的分区规则不一定相同，因此在分布式环境中，索引数据和主表数据存储的位置也无法保证始终在一起。
- 这种分离会导致读写操作时引入 RPC（远程过程调用）代价和分布式事务的代价。例如，当主表的分区和全局索引的分区不在同一个物理位置上，
TABLE SCAN算子执行全局索引表扫描时就会包含一次 RPC 操作到远端机器上去获取主表数据。
-
维护代价：
- 全局索引相比局部索引有更高的维护代价，因为数据的增删改都需要维护全局索引，可能会产生分布式事务，影响系统的写入性能。
-
统一管理：
- 尽管全局索引有独立的分区规则，但它们仍然属于同一个逻辑存储空间（即同一个表）。全局索引的数据和主表的数据共同存在于 OceanBase 数据库的 LSM-Tree 结构中，包括 MemTable 和 SSTable 文件。
总结
对于分区表的全局索引：
- 不是每个分区独立存储在一个单独的 Table Store 内。
- 全局索引有自己独立的分区规则，可以与主表的分区规则不同。
- 全局索引的数据和主表的数据可能存储在不同的节点上，导致读写操作时引入额外的 RPC 和分布式事务代价。
- 全局索引的数据和主表的数据共同存在于同一个逻辑存储空间中，但全局索引的数据可能会分布在不同的节点上。
希望以上解释能够澄清您的疑问。如果您还有其他问题，欢迎继续提问！
更多信息请参考：
具体信息可参考以下文档:
- 转储和合并概述
- OceanBase 数据库性能的影响因素
- 存储架构概述
- 表存储
- 创建数据库
- 分布式数据库对象概述
文档依据：
- 片段标题: OceanBase 数据库性能的影响因素 → 资源分配 → 局部索引和全局索引
- 片段标题: 使用 OceanBase 数据库分区表进行水平拆分 → 分区表 → 分区表的索引
- 片段标题: OceanBase 数据库性能的影响因素 → 资源分配 → 局部索引和全局索引 → 局部索引
检索到的文档如下:
- 全局索引
- 集群管理 FAQ
- OceanBase 术语
- 索引概述
- 分区索引
- 租户内均衡
- OceanBase 数据库性能的影响因素
检索到的文档如下:
根据文档库中的信息，关于分区表的全局索引存储方式，可以总结如下：
分区表的全局索引存储
全局索引的每个分区独立存储在一个 Table Store 内？
不是。对于分区表的全局索引，其存储方式与局部索引不同：
-
全局索引的独立性：
- 全局索引有自己独立的分区规则，可以定义自己的分区策略，不一定与主表的分区规则相同。
- 全球索引可以有自己的分区模式，既可以选择非分区模式也可以选择分区模式；在分区模式中，分区的方式既可以和主表相同也可以不同。
-
物理位置分离：
- 由于全局索引的分区规则和主表的分区规则不一定相同，因此在分布式环境中，索引数据和主表数据存储的位置也无法保证始终在一起。
- 这种分离会导致读写操作时引入 RPC（远程过程调用）代价和分布式事务的代价。例如，当主表的分区和全局索引的分区不在同一个物理位置上，TABLE SCAN 算子执行全局索引表扫描时就会包含一次 RPC 操作到远端机器上去获取主表数据。
-
维护代价：
- 全局索引相比局部索引有更高的维护代价，因为数据的增删改都需要维护全局索引，可能会产生分布式事务，影响系统的写入性能。
-
具体实现细节：
- 全局索引的数据和主表的数据不会绑定在同一 Table Store 内。全局索引的数据会根据其自身的分区规则存储在不同的 Table Store 中，而这些 Table Store 可能分布在不同的节点上。
- 因此，全局索引的每个分区并不是独立存储在一个单独的 Table Store 内，而是根据全局索引的分区规则存储在相应的 Table Store 中。
总结
对于分区表的全局索引：
- 不是每个分区独立存储在一个 Table Store 内。
- 全局索引有自己独立的分区规则，可以与主表的分区规则不同。
- 全局索引的数据和主表的数据存储位置可能不同，导致读写操作时引入额外的 RPC 和分布式事务代价。
- 全局索引的数据会根据其自身的分区规则存储在不同的 Table Store 中，而这些 Table Store 可能分布在不同的节点上。
希望以上解释能够澄清您的疑问。如果您还有其他问题，欢迎继续提问！
更多信息请参考：
具体信息可参考以下文档:
- 转储和合并概述
- OceanBase 数据库性能的影响因素
- 存储架构概述
- 表存储
- 创建数据库
- 分布式数据库对象概述
具体信息可参考以下文档:
- OceanBase 术语
- 表概述
- 关于外表
- 表存储
- oceanbase.DBA_OB_TABLE_LOCATIONS
- 表级字符集和字符序
文档依据：
- 片段标题: OceanBase 数据库性能的影响因素 → 资源分配 → 局部索引和全局索引
- 片段标题: 使用 OceanBase 数据库分区表进行水平拆分 → 分区表 → 分区表的索引
- 片段标题: OceanBase 数据库性能的影响因素 → 资源分配 → 局部索引和全局索引 → 局部索引
根据文档库中的信息，对于分区表的全局索引，其存储方式与局部索引和主表数据有所不同。具体来说：
分区表的全局索引存储
全局索引的独立性
-
独立的分区规则：
- 全局索引有自己独立的分区规则，可以定义自己的分区策略，不一定与主表的分区规则相同。
- 全局索引可以有自己的分区模式，既可以选择非分区模式也可以选择分区模式；在分区模式中，分区的方式既可以和主表相同也可以不同。
-
物理位置分离：
- 由于全局索引的分区规则和主表的分区规则不一定相同，因此在分布式环境中，索引数据和主表数据存储的位置也无法保证始终在一起。
- 这种分离会导致读写操作时引入 RPC（远程过程调用）代价和分布式事务的代价。例如，当主表的分区和全局索引的分区不在同一个物理位置上，
TABLE SCAN算子执行全局索引表扫描时就会包含一次 RPC 操作到远端机器上去获取主表数据。
-
维护代价：
- 全局索引相比局部索引有更高的维护代价，因为数据的增删改都需要维护全局索引，可能会产生分布式事务，影响系统的写入性能。
全局索引的每个分区是否独立存储在一个 Table Store 内？
-
全局索引的每个分区独立存储：是的，分区表的全局索引的每个分区确实独立存储在一个 Table Store 内。这意味着每个全局索引分区的数据会存储在不同的 MemTable 和 SSTable 文件中，并且这些文件属于不同的存储单元。
-
跨节点分布：由于全局索引的分区规则可以与主表不同，因此全局索引的各个分区可能会分布在不同的节点上。这使得全局索引的查询和维护操作可能涉及跨节点通信，增加了复杂性和开销。
文档依据
片段标题: OceanBase 数据库性能的影响因素 → 资源分配 → 局部索引和全局索引 → 全局索引：
“与局部索引相比，由于全局索引有独立的分区规则，因此索引表中一个分区的索引值可能对应着主表的多个分区内的数据。由于索引的分区规则和主表的分区规则不一定相同，因此在分布式环境中，索引数据和主表数据存储的位置也无法保证始终在一起，这不可避免的会引入读写的 RPC 代价和分布式事务的代价。”
片段标题: 使用 OceanBase 数据库分区表进行水平拆分 → 分区表 → 分区表的索引：
“如果分区表的索引不分区，就是一个全局索引（GLOBAL），是一个独立的分区，索引数据覆盖整个分区表。”
总结
对于分区表的全局索引：
- 每个分区的数据独立存储在一个 Table Store 内。
- 全局索引的分区规则可以与主表不同，导致索引数据和主表数据的物理位置分离。
- 全局索引的各个分区可能会分布在不同的节点上，增加了查询和维护操作的复杂性和开销。
希望以上解释能够澄清您的疑问。如果您还有其他问题，欢迎继续提问！
更多信息请参考：
- OceanBase 数据库性能的影响因素
- OceanBase 数据库术语
- 存储架构概述
检索到的文档如下: